On 05/11, Kelsey Skunberg wrote:
> The following files are generated when /selftests/bpf/ is compiled and
> should be added to .gitignore:
>
> - libbpf.pc
> - libbpf.so.0
> - libbpf.so.0.0.3
>
> Signed-off-by: Kelsey Skunberg
> ---
> tools/testing/selftests/bpf/.gitignore | 3
On Fri, May 10, 2019 at 7:27 PM Neil Horman wrote:
>
> On Thu, May 09, 2019 at 09:39:13AM -0700, David Miller wrote:
> > From: Neil Horman
> > Date: Thu, 9 May 2019 07:32:35 -0400
> >
> > > This is definately a valid cleanup, but I wonder if it wouldn't be better
> > > to,
> > > instead of remov
The following files are generated when /selftests/bpf/ is compiled and
should be added to .gitignore:
- libbpf.pc
- libbpf.so.0
- libbpf.so.0.0.3
Signed-off-by: Kelsey Skunberg
---
tools/testing/selftests/bpf/.gitignore | 3 +++
1 file changed, 3 insertions(+)
diff --gi
This patch adds an optional device property "firmware-name" to allow the
driver to load customized nvm firmware file based on this property.
Signed-off-by: Rocky Liao
---
Changes in v4:
* rebased the code base and merge with latest code
---
Documentation/devicetree/bindings/net/qualcomm-blueto
QCA BTSOC NVM is a customized firmware file and different vendors may
want to have different BTSOC configuration (e.g. Configure SCO over PCM
or I2S, Setting Tx power, etc.) via this file. This patch will allow
vendors to download different NVM firmware file by reading a device
property "firmware-n
On 5/11/2019 10:37 PM, Andrew Lunn wrote:
On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
Good Evening,
Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
rtl8211e rx/tx delays config" breaks networking completely on the
rk3328-roc-cc.
Reverting the offending co
On Sat, May 11, 2019 at 11:14:47PM +0300, Vladimir Oltean wrote:
> It's best to not expose this, due to the performance hit it may cause
> when calling it.
>
> Fixes: b68b0dd0fb2d ("net: dsa: Keep private info in the skb->cb")
> Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Andre
On Sat, May 11, 2019 at 11:14:46PM +0300, Vladimir Oltean wrote:
> This does not cause any bug now because it has no users, but its body
> contains two pointer definitions within a code block:
>
> struct sk_buff *clone = _clone; \
> struct sk_buff *skb = _skb; \
>
On Sat, May 11, 2019 at 07:17:08PM -0400, Peter Geis wrote:
> Good Evening,
>
> Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
> rtl8211e rx/tx delays config" breaks networking completely on the
> rk3328-roc-cc.
> Reverting the offending commit solves the problem.
Hi Pete
On 05/11, Andrii Nakryiko wrote:
> On Fri, May 10, 2019 at 3:00 PM Stanislav Fomichev wrote:
> >
> > On 05/10, Andrii Nakryiko wrote:
> > > On Fri, May 10, 2019 at 2:36 PM Stanislav Fomichev
> > > wrote:
> > > >
> > > > On 05/10, Andrii Nakryiko wrote:
> > > > > Depending on used versions of lib
Good Evening,
Commit f81dadbcf7fd067baf184b63c179fc392bdb226e "net: phy: realtek: Add
rtl8211e rx/tx delays config" breaks networking completely on the
rk3328-roc-cc.
Reverting the offending commit solves the problem.
The following error occurs:
[ 49.442425] Unable to handle kernel executi
On Sat, 11 May 2019 at 23:16, Vladimir Oltean wrote:
>
> Making DSA use the sk_buff control block was my idea during the
> 'Traffic-support-for-SJA1105-DSA-driver' patchset, and I had also
> introduced a series of macro helpers that turned out to not be so
> helpful:
>
> 1. DSA_SKB_ZERO() zeroizes
It's best to not expose this, due to the performance hit it may cause
when calling it.
Fixes: b68b0dd0fb2d ("net: dsa: Keep private info in the skb->cb")
Signed-off-by: Vladimir Oltean
---
include/net/dsa.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa
Making DSA use the sk_buff control block was my idea during the
'Traffic-support-for-SJA1105-DSA-driver' patchset, and I had also
introduced a series of macro helpers that turned out to not be so
helpful:
1. DSA_SKB_ZERO() zeroizes the 48-byte skb->cb area, but due to the high
performance impac
The sk_buff control block can have any contents on xmit put there by the
stack, so initialization is mandatory, since we are checking its value
after the actual DSA xmit (the tagger may have changed it).
The DSA_SKB_ZERO() macro could have been used for this purpose, but:
- Zeroizing a 48-byte mem
This does not cause any bug now because it has no users, but its body
contains two pointer definitions within a code block:
struct sk_buff *clone = _clone; \
struct sk_buff *skb = _skb; \
When calling the macro as DSA_SKB_CLONE(clone, skb), these variables
woul
On (05/11/19 12:52), Linus Torvalds wrote:
>
> So David, arguably the kernel "struct sockaddr" is simply wrong, if it
> can't contain a "struct sockaddr_in6". No? Is extending it a huge
> problem for other users that don't need it (mainly stack, I assume..)?
The ipv6 working group came up with so
From: Nicholas Mc Guire
Date: Sat, 11 May 2019 02:56:33 +0200
> sparse was unable to verify endiannes correctness due to reassignment
> from le32_to_cpu to the same variable - fix this warning up by providing
> a proper __le32 type and initializing it. This is not actually fixing
> any bug - rath
From: Heiner Kallweit
Date: Sat, 11 May 2019 07:44:48 +0200
> When adding missing callbacks I missed that one had them set already.
> Interesting that the compiler didn't complain.
>
> Fixes: daf3ddbe11a2 ("net: phy: realtek: add missing page operations")
> Signed-off-by: Heiner Kallweit
Appli
Jason and Davem,
with gcc-9, I'm now seeing a number of annoying warnings from the
rdma layer. I think it depends on the exact gcc version, because I'm
seeing them on my laptop but didn't see them on my desktop, probably
due to updating at different times.
The warning is because gcc now looks at
On Fri, May 10, 2019 at 3:00 PM Stanislav Fomichev wrote:
>
> On 05/10, Andrii Nakryiko wrote:
> > On Fri, May 10, 2019 at 2:36 PM Stanislav Fomichev wrote:
> > >
> > > On 05/10, Andrii Nakryiko wrote:
> > > > Depending on used versions of libbpf, Clang, and kernel, it's possible
> > > > to
> >
> Hi Andrew,
> it is configured as in the vanilla kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi#n191
> ,that is,
> phy-mode = "rgmii";
> There are also these configuration items:
> tx_delay = <0x28>;
> rx_delay =
On Saturday, May 11, 2019 5:08:19 PM CEST, Andrew Lunn wrote:
On Sat, May 11, 2019 at 04:46:40PM +0200, Vicente Bergas wrote:
On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
On 10.05.2019 17:05, Vicente Bergas wrote:
Hello,
there is a regression on linux v5.1-9573-gb970afcfcab
On Sat, May 11, 2019 at 04:46:40PM +0200, Vicente Bergas wrote:
> On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
> >On 10.05.2019 17:05, Vicente Bergas wrote:
> >>Hello,
> >>there is a regression on linux v5.1-9573-gb970afcfcabd with a kernel null
> >>pointer dereference.
> >>The
On Saturday, May 11, 2019 4:56:56 PM CEST, Heiner Kallweit wrote:
On 11.05.2019 16:46, Vicente Bergas wrote:
On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
On 10.05.2019 17:05, Vicente Bergas wrote: ...
Hello Heiner,
just tried your patch and indeed the NPE is gone. But stil
Hi guys,
on 5.1+ the story keeps being the same.
950 Mbits in each direction, but when in duplex RX is starving to ~70
MBits..
ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt
recognize before.
Do we have new ideas / new direction to dig for ?
regards,
Simon
Am 01.03.2
On 11.05.2019 16:46, Vicente Bergas wrote:
> On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
>> On 10.05.2019 17:05, Vicente Bergas wrote:
>>> Hello,
>>> there is a regression on linux v5.1-9573-gb970afcfcabd with a kernel null
>>> pointer dereference.
>>> The issue is the commit f
Maxime Ripard [2019-05-10 13:31:55]:
Hi,
> > This reverse byte order format/layout is one of a few other storage formats
> > currently used by vendors, some other (creative) vendors are currently
> > providing MAC addresses in NVMEMs as ASCII text in following two formats
> > (hexdump -C /dev/mt
On Friday, May 10, 2019 10:28:06 PM CEST, Heiner Kallweit wrote:
On 10.05.2019 17:05, Vicente Bergas wrote:
Hello,
there is a regression on linux v5.1-9573-gb970afcfcabd with a kernel null
pointer dereference.
The issue is the commit f81dadbcf7fd067baf184b63c179fc392bdb226e
net: phy: realtek: A
On 2019-05-04 12:22, YueHaibing wrote:
> Fix sparse warning:
>
> drivers/net/wireless/mediatek/mt76/mt7615/pci.c:37:13:
> warning: symbol 'mt7615_irq_handler' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing
Applied, thanks.
- Felix
I had wrote some letters but no answer
Can I send you a new link of my translation of your article
http://www.candelatech.com/~greear/vlan.html
Hungarian - not working
May I send a new link?
Thank you
On 09.05.2019 23:07, Andrew Lunn wrote:
> On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
>> On 09.05.2019 22:29, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> I have a board here that has a KSZ8051MLL (datasheet:
>>> http://ww1.microchip.com/downloads/en/DeviceDoc/ksz8051mll.pdf, phy
On 2019-05-05 23:31, Colin King wrote:
> From: Colin Ian King
>
> The signed return from the call to get_omac_idx is being assigned to the
> u8 variable mac_idx and then checked for a negative error condition
> which is always going to be false. Fix this by assigning the return to
> the int varia
On 11.05.2019 12:41, Heiner Kallweit wrote:
> On 10.05.2019 23:46, Trent Piepho wrote:
>> The variables used to store u32 DT properties were signed ints. This
>> doesn't work properly if the value of the property were to overflow.
>> Use unsigned variables so this doesn't happen.
>>
> In patch 3 y
On 10.05.2019 23:46, Trent Piepho wrote:
> The variables used to store u32 DT properties were signed ints. This
> doesn't work properly if the value of the property were to overflow.
> Use unsigned variables so this doesn't happen.
>
In patch 3 you added a check for DT properties being out of ran
On Fri, May 10, 2019 at 03:20:08PM -0700, David Miller wrote:
> From: Stefano Garzarella
> Date: Fri, 10 May 2019 14:58:37 +0200
>
> > @@ -827,12 +827,20 @@ static bool virtio_transport_close(struct vsock_sock
> > *vsk)
> >
> > void virtio_transport_release(struct vsock_sock *vsk)
> > {
> >
36 matches
Mail list logo
