Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

Hello Guenter, On Sun, May 22, 2016 at 06:06:24PM -0700, Guenter Roeck wrote: > On 05/22/2016 11:21 AM, Uwe Kleine-König wrote: > >On Sun, May 22, 2016 at 08:41:23AM -0700, Guenter Roeck wrote: > >>I am not exactly in favor of forcing GPIOLIB to be enabled for every > >>system with Ethernet

[PATCH] ipaddress: fix build with musl libc

MIN() is defined within sys/param.h. Signed-off-by: Kylie McClain --- ip/ipaddress.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ip/ipaddress.c b/ip/ipaddress.c index 0692fba..df363b0 100644 --- a/ip/ipaddress.c +++ b/ip/ipaddress.c @@ -19,6 +19,7 @@ #include

Re: [RESEND PATCH v7 17/21] IB/hns: Add QP operations support

Hi, Doug Ledford In hns_roce_cmd_wait and hns_roce_cmd_poll, there are down seminal operations, So, there are not deadlock and conflict, right? static int hns_roce_cmd_poll(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param, unsigned long in_modifier,

Re: [RFC] NET: PHY: adds driver for Lantiq PHY11G

On Sun, May 22, 2016 at 09:33:51PM +0200, Hauke Mehrtens wrote: > Supports the Lantiq / Intel CHD 11G and 22E PHYs. > These PHYs are also named PEF 7061, PEF 7071, PEF 7072 > > Signed-off-by: John Crispin > Signed-off-by: Hauke Mehrtens > --- > > This is

[PATCH] net/qlge: Avoids recursive EEH error

One timer, whose handler keeps reading on MMIO register for EEH core to detect error in time, is started when the PCI device driver is loaded. MMIO register can't be accessed during PE reset in EEH recovery. Otherwise, the unexpected recursive error is triggered. The timer isn't closed that time

Re: [RESEND PATCH v7 00/21] Add HiSilicon RoCE driver

Hi, Doug Ledford We will modify the license description of the beginning of the code file in patch v8. Thanks Regards Wei Hu On 2016/5/14 5:09, Doug Ledford wrote: On 05/09/2016 11:04 PM, Lijun Ou wrote: The HiSilicon Network Substem is a long term evolution IP which is supposed to be

Re: [PATCH] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

On Sun, May 22, 2016 at 3:53 PM, Haishuang Yan wrote: > For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). > > Signed-off-by: Haishuang Yan > --- > net/ipv4/ip_tunnel.c | 5 - > 1 file changed, 4

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

On 05/22/2016 11:21 AM, Uwe Kleine-König wrote: Hello Guenter, [extending Cc: a bit] On Sun, May 22, 2016 at 08:41:23AM -0700, Guenter Roeck wrote: On 05/22/2016 03:10 AM, Uwe Kleine-König wrote: On Tue, May 17, 2016 at 09:37:11PM -0700, Guenter Roeck wrote: [9.366256] libphy:

[PATCH] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). Signed-off-by: Haishuang Yan --- net/ipv4/ip_tunnel.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

Lino Sanfilippo : [...] > --- a/drivers/net/ethernet/arc/emac_main.c > +++ b/drivers/net/ethernet/arc/emac_main.c > @@ -159,12 +159,22 @@ static void arc_emac_tx_clean(struct net_device *ndev) > unsigned int *txbd_dirty = >txbd_dirty; > struct

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

Lino Sanfilippo : > On 21.05.2016 21:47, Francois Romieu wrote: > > Shuyu Wei : > > [...] > >> diff --git a/drivers/net/ethernet/arc/emac_main.c > >> b/drivers/net/ethernet/arc/emac_main.c > >> index a3a9392..c2447b0 100644 > >> ---

Re: [PATCH] net/ethoc: fix null dereference on error exit path

On 22/05/16 20:42, Max Filippov wrote: > Hi Colin, > > On Sun, May 22, 2016 at 08:08:18PM +0100, Colin King wrote: >> From: Colin Ian King >> >> priv is assigned to NULL however all the error exit paths to label 'free' >> dereference priv, causing a null pointer

[PATCH net] bpf, inode: disallow userns mounts

Follow-up to commit e27f4a942a0e ("bpf: Use mount_nodev not mount_ns to mount the bpf filesystem"), which removes the FS_USERNS_MOUNT flag. The original idea was to have a per mountns instance instead of a single global fs instance, but that didn't work out and we had to switch to mount_nodev()

Re: [RFC] NET: PHY: adds driver for Lantiq PHY11G

On 05/22/2016 10:30 PM, Mathias Kresin wrote: > Hi Hauke, > > find my comments in-line. > > Am 22.05.2016 um 21:33 schrieb Hauke Mehrtens: >> Supports the Lantiq / Intel CHD 11G and 22E PHYs. >> These PHYs are also named PEF 7061, PEF 7071, PEF 7072 >> >> Signed-off-by: John Crispin

Re: [RFC] NET: PHY: adds driver for Lantiq PHY11G

Hi Hauke, find my comments in-line. Am 22.05.2016 um 21:33 schrieb Hauke Mehrtens: Supports the Lantiq / Intel CHD 11G and 22E PHYs. These PHYs are also named PEF 7061, PEF 7071, PEF 7072 Signed-off-by: John Crispin Signed-off-by: Hauke Mehrtens --- This

Re: [PATCH] net/ethoc: fix null dereference on error exit path

Hi Colin, On Sun, May 22, 2016 at 08:08:18PM +0100, Colin King wrote: > From: Colin Ian King > > priv is assigned to NULL however all the error exit paths to label 'free' > dereference priv, causing a null pointer dereference. > > Examination of the code shows that

[RFC] NET: PHY: adds driver for Lantiq PHY11G

Supports the Lantiq / Intel CHD 11G and 22E PHYs. These PHYs are also named PEF 7061, PEF 7071, PEF 7072 Signed-off-by: John Crispin Signed-off-by: Hauke Mehrtens --- This is based on a driver from OpenWrt / LEDE. This is send as a RFC because the merge

[PATCH] net/ethoc: fix null dereference on error exit path

From: Colin Ian King priv is assigned to NULL however all the error exit paths to label 'free' dereference priv, causing a null pointer dereference. Examination of the code shows that all error exits via the 'free' label path occur before priv is assigned to

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

Hello Guenter, [extending Cc: a bit] On Sun, May 22, 2016 at 08:41:23AM -0700, Guenter Roeck wrote: > On 05/22/2016 03:10 AM, Uwe Kleine-König wrote: > >On Tue, May 17, 2016 at 09:37:11PM -0700, Guenter Roeck wrote: > >>[9.366256] libphy: ethoc-mdio: probed > >>[9.367389] (null): could

[iproute2 PATCH 1/1] tc fix ife late binding

From: Jamal Hadi Salim following late binding didn't work sudo tc actions add action ife encode \ type 0xDEAD allow mark dst 02:15:15:15:15:15 index 1 Signed-off-by: Jamal Hadi Salim --- tc/m_ife.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [iproute2 1/1] man: tc-ife.8: man page for ife action

On 16-05-02 07:40 PM, Jamal Hadi Salim wrote: On 16-05-02 06:10 PM, Stephen Hemminger wrote: On Sat, 30 Apr 2016 06:58:04 -0400 Jamal Hadi Salim wrote: From: Lucas Bates Signed-off-by: Lucas Bates Signed-off-by: Jamal Hadi Salim

Re: [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump

On 16-05-20 01:50 AM, Eric Dumazet wrote: It wont be inaccurate (no drift), as the writers hold the qdisc spinlock. It it the same with say IP/TCP SNMP counters : When an incoming frame is handled, it might change many SNMP counters, but an SNMP agent might fetch the whole set of SNMP values

[net PATCH 1/1] net sched actions: policer missing timestamp processing

From: Jamal Hadi Salim Policer was not dumping or updating timestamps Signed-off-by: Jamal Hadi Salim --- include/uapi/linux/pkt_cls.h | 4 +++- net/sched/act_police.c | 10 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git

Re: [net-next PATCH 0/2] net sched small OCD cleanups

On 16-05-19 02:28 PM, David Miller wrote: From: Jamal Hadi Salim Date: Tue, 17 May 2016 17:19:13 -0400 I have been staring at these small OCD cleanups for a while. Got cycles to do them as prep for another patch i am working on. Indentation/stylistic and consistency updates

Re: [net-next RFC 1/1] net sched actions: introduce timestamp for first time used

On 16-05-20 01:16 AM, Cong Wang wrote: One nit: It is better if you can swap 'stm' with 'dtm', it looks odd to put destination on the right side. Will make the change for when net-next opens up. cheers, jamal

Re: [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump

On 16-05-19 08:35 AM, Eric Dumazet wrote: From: Eric Dumazet Large tc dumps (tc -s {qdisc|class} sh dev ethX) done by Google BwE host agent [1] are problematic at scale : For each qdisc/class found in the dump, we currently lock the root qdisc spinlock in order to get

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

Hi Uwe, On 05/22/2016 03:10 AM, Uwe Kleine-König wrote: Hello, On Tue, May 17, 2016 at 09:37:11PM -0700, Guenter Roeck wrote: [9.366256] libphy: ethoc-mdio: probed [9.367389] (null): could not attach to PHY [9.368555] (null): failed to probe MDIO bus [9.371540] Unable to

Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

On 22.05.2016 09:44, Michael S. Tsirkin wrote: > On Sat, May 21, 2016 at 03:02:30AM +0200, Hannes Frederic Sowa wrote: >> Hello, >> >> On 18.05.2016 18:06, Tom Herbert wrote: >>> In several gso_segment functions there are checks of gso_type against >>> a seemingly arbitrary list of SKB_GSO_*

Re: IPv6 extension header privileges

On 22.05.2016 13:56, Sowmini Varadhan wrote: > >>> Tom Herbert wrote: >>> If you don't mind I'll change this to make specific options are >>> privileged and not all hbh and destopt. There is talk in IETF about >>> reinventing IP extensibility within UDP since the kernel APIs don't

Re: IPv6 extension header privileges

> > Tom Herbert wrote: > > If you don't mind I'll change this to make specific options are > > privileged and not all hbh and destopt. There is talk in IETF about > > reinventing IP extensibility within UDP since the kernel APIs don't > > allow setting EH. I would like to avoid

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

On 22.05.2016 11:17, Shuyu Wei wrote: > Hi Lino, > > I tested this patch, it still got panic under stress. > Just wget 2 large files simultaneously and it failed. > > Looks like the problem comes from the if statement in tx_clean(). > I changed your patch to use > > - if (info &

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

Hello, On Tue, May 17, 2016 at 09:37:11PM -0700, Guenter Roeck wrote: > [9.366256] libphy: ethoc-mdio: probed > [9.367389] (null): could not attach to PHY > [9.368555] (null): failed to probe MDIO bus > [9.371540] Unable to handle kernel paging request at virtual address >

Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

On Sat, 21 May 2016 17:47:05 +0200 Bert Lindner wrote: > Hi, > > On 2016-05-20 12:36, Marc Zyngier wrote: > > On 20/05/16 11:30, Andre Heider wrote: > >> Hi, > >> > >> On Fri, May 20, 2016 at 10:14 AM, Giuseppe CAVALLARO > >> wrote: > >>> On 5/20/2016 9:56

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

On Sun, May 22, 2016 at 12:58:55AM +0200, Lino Sanfilippo wrote: > --- a/drivers/net/ethernet/arc/emac_main.c > +++ b/drivers/net/ethernet/arc/emac_main.c > @@ -162,7 +162,13 @@ static void arc_emac_tx_clean(struct net_device *ndev) > struct sk_buff *skb = tx_buff->skb; >

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Sedat Dilek wrote: > On 5/16/16, Peter Zijlstra wrote: >> On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: >> >>> Unfortunately, I could not reproduce this again with none of my >>> 183-kernels. >>> When I first hit a

[PATCH 32/54] MAINTAINERS: Add file patterns for net device tree bindings

Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven Cc: David S. Miller Cc: netdev@vger.kernel.org --- Please apply this patch directly if you want to be

Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

On Wed, May 18, 2016 at 09:06:09AM -0700, Tom Herbert wrote: > In several gso_segment functions there are checks of gso_type against > a seemingly arbitrary list of SKB_GSO_* flags. This seems like an > attempt to identify unsupported GSO types, but since the stack is > the one that set these GSO

Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

On Sat, May 21, 2016 at 03:02:30AM +0200, Hannes Frederic Sowa wrote: > Hello, > > On 18.05.2016 18:06, Tom Herbert wrote: > > In several gso_segment functions there are checks of gso_type against > > a seemingly arbitrary list of SKB_GSO_* flags. This seems like an > > attempt to identify