Re: [PATCH net] net: phy: marvell: Only configure RGMII delays when using RGMII

[Aaro Koskinen]

Hi,

On Tue, Oct 31, 2017 at 08:31:28PM +0100, Andrew Lunn wrote:
> The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
> uncovered another bug in the Marvell PHY driver, which broke the
> Marvell OpenRD platform. It relies on the bootloader configuring the
> RGMII delays and does not specify a phy-mode in its device tree.  The
> PHY driver should only configure RGMII delays if the phy mode
> indicates it is using RGMII. Without anything in device tree, the
> mv643xx Ethernet driver defaults to GMII.
> 
> Fixes: 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo")
> Signed-off-by: Andrew Lunn <and...@lunn.ch>

Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>

> Aaro
> 
> Please can you test this and see if it fixes your OpenRD. This should
> cause it to leave the bootloader configuration alone. That will fix
> the regression for older DT blobs. Adding correct phy-mode properties
> can also be done. That would increase the robustness to bootloader
> changes.

Thanks, and yes, I guess also the DT should be updated...

A.

> drivers/net/phy/marvell.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 15cbcdba618a..4d02b27df044 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -681,9 +681,11 @@ static int m88e1116r_config_init(struct phy_device 
> *phydev)
>   if (err < 0)
>   return err;
>  
> - err = m88e1121_config_aneg_rgmii_delays(phydev);
> - if (err < 0)
> - return err;
> + if (phy_interface_is_rgmii(phydev)) {
> + err = m88e1121_config_aneg_rgmii_delays(phydev);
> + if (err < 0)
> + return err;
> + }
>  
>   err = genphy_soft_reset(phydev);
>   if (err < 0)
> -- 
> 2.14.1
> 

Re: [REGRESSION, BISECTED] Broken networking with net/phy/marvell

[Aaro Koskinen]

Hi,

On Sat, Oct 28, 2017 at 09:01:39PM +0200, Andrew Lunn wrote:
> On Thu, Oct 26, 2017 at 03:28:36PM +0300, Aaro Koskinen wrote:
> > When upgrading from v4.13 to v4.14-rc6 on OpenRD Client, the box loses
> > network connectivity.
> 
> What exactly is the PHY in the OpenRD?

88E1116R.

> Please can you print the value of mscr before it is changed.

[3.377836] MSCR BEFORE: 1070
[3.381176]  MSCR AFTER: 1040

> One possibility, is that the bootloader is setting the PHY to
> rgmii-id. This is now getting cleared, where earlier it was
> preserved. If this is true, it should be solved by adding
> 
> phy-mode = "rgmii-id" to the ethernet node in the device tree.

Ok, that seems to help:

[3.377852] MSCR BEFORE: 1070
[3.381189]  MSCR AFTER: 1070

diff --git a/arch/arm/boot/dts/kirkwood-openrd-client.dts 
b/arch/arm/boot/dts/kirkwood-openrd-client.dts
index 96ff59d..2bf3cb3 100644
--- a/arch/arm/boot/dts/kirkwood-openrd-client.dts
+++ b/arch/arm/boot/dts/kirkwood-openrd-client.dts
@@ -65,6 +65,7 @@
status = "okay";
ethernet0-port@0 {
phy-handle = <>;
+   phy-mode = "rgmii-id";
};
 };
 
@@ -72,6 +73,7 @@
status = "okay";
ethernet1-port@0 {
phy-handle = <>;
+   phy-mode = "rgmii-id";
};
 };

A.

[REGRESSION, BISECTED] Broken networking with net/phy/marvell

[Aaro Koskinen]

Hi,

When upgrading from v4.13 to v4.14-rc6 on OpenRD Client, the box loses
network connectivity.

Bisection points to:

commit 5987feb38aa55e035ce5376c02aba88a604cc881
Author: Dan Carpenter 
Date:   Fri Aug 4 11:17:21 2017 +0300

net: phy: marvell: logical vs bitwise OR typo

However, it seems this commit just unhides another issue in the original
commit 864dc729d528 ("net: phy: marvell: Refactor m88e1121 RGMII delay
configuration"): when we are configuring the MSCR delay bits, we are
probably clearing the bits with a wrong mask (i.e. we might be disabling
something else not intended)...

I have tested the below change and it seems to fix the networking. Any
comments?

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 15cbcdb..500d7c1 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -474,7 +474,7 @@ static int m88e1121_config_aneg_rgmii_delays(struct 
phy_device *phydev)
goto out;
}
 
-   mscr &= MII_88E1121_PHY_MSCR_DELAY_MASK;
+   mscr &= ~MII_88E1121_PHY_MSCR_DELAY_MASK;
 
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
mscr |= (MII_88E1121_PHY_MSCR_RX_DELAY |

A.

Re: [BISECTED] v4.9: OCTEON ethernet crash

[Aaro Koskinen]

Hi,

On Wed, Dec 14, 2016 at 05:00:59PM -0800, Florian Fainelli wrote:
> On 12/14/2016 04:57 PM, Aaro Koskinen wrote:
> > On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote:
> >> On 12/14/2016 04:32 PM, Aaro Koskinen wrote:
> >>> Git bisect points to:
> >>>
> >>> commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461
> >>> Author: Florian Fainelli <f.faine...@gmail.com>
> >>> Date:   Tue Dec 6 20:54:43 2016 -0800
> >>>
> >>> phy: Don't increment MDIO bus refcount unless it's a different owner
> >>>
> >>> Reverting this patch from v4.9 fixes the issue...
> >>
> >> This should help:
> >>
> >> diff --git a/drivers/staging/octeon/ethernet.c
> >> b/drivers/staging/octeon/ethernet.c
> >> index 8130dfe89745..12ebc4d800c3 100644
> >> --- a/drivers/staging/octeon/ethernet.c
> >> +++ b/drivers/staging/octeon/ethernet.c
> >> @@ -770,6 +770,7 @@ static int cvm_oct_probe(struct platform_device *pdev)
> >> /* Initialize the device private structure. */
> >> struct octeon_ethernet *priv = netdev_priv(dev);
> >>
> >> +   SET_NETDEV_DEV(dev, >dev);
> >> dev->netdev_ops = _oct_pow_netdev_ops;
> >> priv->imode = CVMX_HELPER_INTERFACE_MODE_DISABLED;
> >> priv->port = CVMX_PIP_NUM_INPUT_PORTS;
> > 
> > No, it's still crashing.
> 
> How about this:
> 
> diff --git a/drivers/staging/octeon/ethernet.c
> b/drivers/staging/octeon/ethernet.c
> index 12ebc4d800c3..4971aa54756a 100644
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -817,6 +817,7 @@ static int cvm_oct_probe(struct platform_device *pdev)
> }
> 
> /* Initialize the device private structure. */
> +   SET_NETDEV_DEV(dev, >dev);
> priv = netdev_priv(dev);
> priv->netdev = dev;
> priv->of_node = cvm_oct_node_for_port(pip,
> interface,

Yeah, that seems to work - thanks! Could you send this to
de...@driverdev.osuosl.org as a formal patch?

A.

Re: [BISECTED] v4.9: OCTEON ethernet crash

[Aaro Koskinen]

Hi,

On Wed, Dec 14, 2016 at 04:41:13PM -0800, Florian Fainelli wrote:
> On 12/14/2016 04:32 PM, Aaro Koskinen wrote:
> > Git bisect points to:
> > 
> > commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461
> > Author: Florian Fainelli <f.faine...@gmail.com>
> > Date:   Tue Dec 6 20:54:43 2016 -0800
> > 
> > phy: Don't increment MDIO bus refcount unless it's a different owner
> > 
> > Reverting this patch from v4.9 fixes the issue...
> 
> This should help:
> 
> diff --git a/drivers/staging/octeon/ethernet.c
> b/drivers/staging/octeon/ethernet.c
> index 8130dfe89745..12ebc4d800c3 100644
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -770,6 +770,7 @@ static int cvm_oct_probe(struct platform_device *pdev)
> /* Initialize the device private structure. */
> struct octeon_ethernet *priv = netdev_priv(dev);
> 
> +   SET_NETDEV_DEV(dev, >dev);
> dev->netdev_ops = _oct_pow_netdev_ops;
> priv->imode = CVMX_HELPER_INTERFACE_MODE_DISABLED;
> priv->port = CVMX_PIP_NUM_INPUT_PORTS;

No, it's still crashing.

A.

[BISECTED] v4.9: OCTEON ethernet crash

[Aaro Koskinen]

Hi,

I'm getting the following crash on every boot on OCTEON (EdgeRouter Lite)
with v4.9 (right after setting up ethernet bridging):

[   16.814902] CPU 0 Unable to handle kernel paging request at virtual address 
0080, epc == 81458570, ra == 81458804
[   16.827805] Oops[#1]:
[   16.830100] CPU: 0 PID: 706 Comm: ifconfig Not tainted 
4.9.0-octeon-los_be07e6-2-g29a0b7e #1
[   16.838884] task: 80041f9dec00 task.stack: 80041f0d8000
[   16.844801] $ 0   :  10108ce1  
0001
[   16.852867] $ 4   : 80041f98a000 80041fb67800  
0002
[   16.860932] $ 8   : 80041fb67810 80041f0dbb40 10434794771be290 
771bf1680001
[   16.868997] $12   :  81383edc 81296950 

[   16.877060] $16   : 80041fb67800 80041f98a000 81508c48 
80041f817800
[   16.885125] $20   :  0002  
80041f98a000
[   16.893190] $24   :  
  
[   16.901256] $28   : 80041f0d8000 80041f0dbb10 80041e109410 
81458804
[   16.909321] Hi: 02c9
[   16.912896] Lo: 1c1d
[   16.916484] epc   : 81458570 phy_attach_direct+0x38/0x1b0
[   16.922580] ra: 81458804 phy_connect_direct+0x24/0x88
[   16.928671] Status: 10108ce3 KX SX UX KERNEL EXL IE 
[   16.933723] Cause : 0088 (ExcCode 02)
[   16.937730] BadVA : 0080
[   16.941306] PrId  : 000d0601 (Cavium Octeon+)
[   16.945660] Modules linked in: at803x
[   16.949353] Process ifconfig (pid: 706, threadinfo=80041f0d8000, 
task=80041f9dec00, tls=771c3490)
[   16.959605] Stack : 80041fb67800 80041f98a000 81508c48 
0002
[   16.967671]   80041e109400 
81458804
[   16.975734] 80041fb67800 80041f98a000 81508c48 
81504cd4
[   16.983799] 80041f98a000 80041f98a000 81509830 

[   16.991864]  81508f58  
815087e0
[   16.28] 80041f98a000 80041f98a048 816fcc88 
1302
[   17.007993] 8914 8150993c 816fcc88 
1302
[   17.016057] 80041f98a000 8153bc6c 80041f98a000 
0008
[   17.024122] 83c500d8  80041f98a000 
0341
[   17.032187] 1043 8153bf94 00fe 
80041f98a000
[   17.040251] ...
[   17.042722] Call Trace:
[   17.045175] [] phy_attach_direct+0x38/0x1b0
[   17.050927] [] phy_connect_direct+0x24/0x88
[   17.056682] [] of_phy_connect+0x54/0xb0
[   17.062089] [] cvm_oct_phy_setup_device+0x48/0xc0
[   17.068361] [] cvm_oct_common_open+0x58/0x2a8
[   17.074285] [] cvm_oct_rgmii_open+0x1c/0x90
[   17.080040] [] __dev_open+0x104/0x198
[   17.085270] [] __dev_change_flags+0x94/0x180
[   17.091107] [] dev_change_flags+0x24/0x68
[   17.096687] [] devinet_ioctl+0x6a8/0x8b0
[   17.102181] [] sock_do_ioctl.constprop.14+0x24/0x68
[   17.108626] [] compat_sock_ioctl+0xd18/0xfc8
[   17.114471] [] compat_SyS_ioctl+0xc0/0x1980
[   17.120222] [] syscall_common+0x18/0x3c
[   17.125621] Code: ffb20010  dc8204b8  dcb30298  de64  dc520010 
 12440005  00a08025  0c46e4a6 
[   17.135490] 
[   17.137147] ---[ end trace f1d7b064cedee4e4 ]---
[   17.141882] Kernel panic - not syncing: Fatal exception
[   17.147140] ---[ end Kernel panic - not syncing: Fatal exception

Git bisect points to:

commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461
Author: Florian Fainelli 
Date:   Tue Dec 6 20:54:43 2016 -0800

phy: Don't increment MDIO bus refcount unless it's a different owner

Reverting this patch from v4.9 fixes the issue...

A.

Re: wl1251 & mac address & calibration data

[Aaro Koskinen]

Hi,

On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
> 
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.

You could use kexec to pass the fixed DT.

A.

Re: Improving OCTEON II 10G Ethernet performance

[Aaro Koskinen]

Hi,

On Thu, Aug 25, 2016 at 01:11:45PM -0700, David Daney wrote:
> On 08/25/2016 11:22 AM, Aaro Koskinen wrote:
> >On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote:
> >>Ideally we would configure the packet classifiers on the RX side to create
> >>multiple RX queues based on a hash of the TCP 5-tuple, and handle each queue
> >>with a single NAPI instance.  That should result in better performance while
> >>maintaining packet ordering.
> >
> >Would this need anything else than reprogramming CVMX_PIP_PRT_TAGX, and
> >eliminating the global pow_receive_group and creating multiple NAPI instances
> >and registering IRQ handlers?
> 
> That is essentially how it works.  Set the tag generation parameters, and
> use the low order bits of the tag to select which POW/SSO group is assigned.
> The SSO group corresponds to an "rx queue"

OK, I will try to experiment with this. Even though my home routers are
2-core only I could still create more queues and verify that the traffic
gets distributed by checking the counters...

> >In the Yocto tree, the CVMX_PIP_PRT_TAGX register values are actually
> >documented:
> >
> >http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/tree/arch/mips/include/asm/octeon/cvmx-pip-defs.h?h=apaliwal/octeon#n3737
> 
> Wow, I didn't realize that documentation was made public.

Also D-Link and Qbiquity GPL source offerings for their products usually
include documentation for register fields. Only in mainline kernel they
are missing.

A.

Re: Improving OCTEON II 10G Ethernet performance

[Aaro Koskinen]

Hi,

On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote:
> Ideally we would configure the packet classifiers on the RX side to create
> multiple RX queues based on a hash of the TCP 5-tuple, and handle each queue
> with a single NAPI instance.  That should result in better performance while
> maintaining packet ordering.

Would this need anything else than reprogramming CVMX_PIP_PRT_TAGX, and
eliminating the global pow_receive_group and creating multiple NAPI instances
and registering IRQ handlers?

In the Yocto tree, the CVMX_PIP_PRT_TAGX register values are actually
documented:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/tree/arch/mips/include/asm/octeon/cvmx-pip-defs.h?h=apaliwal/octeon#n3737

A.

Re: Improving OCTEON II 10G Ethernet performance

[Aaro Koskinen]

Hi,

On Wed, Aug 24, 2016 at 06:29:49PM -0700, Ed Swierk wrote:
> I'm trying to migrate from the Octeon SDK to a vanilla Linux 4.4
> kernel for a Cavium OCTEON II (CN6880) board running in 64-bit
> little-endian mode. So far I've gotten most of the hardware features I
> need working, including XAUI/RXAUI, USB, boot bus and I2C, with a
> fairly small set of patches.
> https://github.com/skyportsystems/linux/compare/master...octeon2

Interesting, have you considered sending some of this stuff into mainline?

> The biggest remaining hurdle is improving 10G Ethernet performance:
> iperf -P 10 on the SDK kernel gets close to 10 Gbit/sec throughput,
> while on my 4.4 kernel, it tops out around 1 Gbit/sec.

Did you compare throughput and packets per second performance of both
kernels using just a single core?

> Comparing the octeon-ethernet driver in the SDK
> (http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/tree/drivers/net/ethernet/octeon?h=apaliwal/octeon)
> against the one in 4.4, the latter appears to utilize only a single
> CPU core for the rx path. It's not clear to me if there is a similar
> issue on the tx side, or other bottlenecks.

Did you try CONFIG_RPS and moving softirqs into other core(s)?

> I started trying to port multi-CPU rx from the SDK octeon-ethernet
> driver, but had trouble teasing out just the necessary bits without
> following a maze of dependencies on unrelated functions. (Dragging
> major parts of the SDK wholesale into 4.4 defeats the purpose of
> switching to a vanilla kernel, and doesn't bring us closer to getting
> octeon-ethernet out of staging.)
> 
> Has there been any work on the octeon-ethernet driver since this patch
> set? https://www.linux-mips.org/archives/linux-mips/2015-08/msg00338.html
> 
> Any hints on what to pick out of the SDK code to improve 10G
> performance would be appreciated.

One thing that is missing from staging driver for CN68XX is the proper
SSO initialization. But I see that you have already implemented that.

Unfortunately I don't have a proper CN68XX test system at the moment, so
CN68XX support has not progressed much since that patch set from my side.

A.

Re: __napi_alloc_skb failures locking up the box

[Aaro Koskinen]

Hi,

On Sat, Apr 30, 2016 at 12:54:12PM -0700, Eric Dumazet wrote:
> On Sat, 2016-04-30 at 22:24 +0300, Aaro Koskinen wrote:
> > Hi,
> > 
> > I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS ->
> > disk reliably results in temporary out-of-memory conditions.
> > 
> > When this happens the dmesg gets flooded with below logs. If the serial
> > console logging is enabled, this will lock up the box completely and
> > the backup is not making any progress.
> > 
> > Shouldn't these allocation failures be ratelimited somehow (or even made
> > silent)? It doesn't sound right if I can lock up the system simply by
> > copying files...
> 
> Agreed.
> 
> All napi_alloc_skb() callers handle failure just fine.
> 
> If they did not, a NULL deref would produce a proper stack dump.
> 
> When memory gets this tight, other traces will be dumped anyway.
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 15d0df943466..0652709fe81a 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2423,7 +2423,7 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct 
> *napi,
>  static inline struct sk_buff *napi_alloc_skb(struct napi_struct *napi,
>unsigned int length)
>  {
> - return __napi_alloc_skb(napi, length, GFP_ATOMIC);
> + return __napi_alloc_skb(napi, length, GFP_ATOMIC | __GFP_NOWARN);
>  }
>  void napi_consume_skb(struct sk_buff *skb, int budget);

Care to send this as a formal patch, so I can reply with my Tested-by?

A.

__napi_alloc_skb failures locking up the box

[Aaro Koskinen]

Hi,

I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS ->
disk reliably results in temporary out-of-memory conditions.

When this happens the dmesg gets flooded with below logs. If the serial
console logging is enabled, this will lock up the box completely and
the backup is not making any progress.

Shouldn't these allocation failures be ratelimited somehow (or even made
silent)? It doesn't sound right if I can lock up the system simply by
copying files...

...

[ 1706.105842] kworker/0:1H: page allocation failure: order:0, 
mode:0x2200020(GFP_NOWAIT|__GFP_HIGH|__GFP_NOTRACK)
[ 1706.105904] CPU: 0 PID: 519 Comm: kworker/0:1H Not tainted 
4.6.0-rc5-iop32x-los_a50bb #1
[ 1706.105917] Hardware name: Thecus N2100
[ 1706.105973] Workqueue: rpciod rpc_async_schedule
[ 1706.105993] Backtrace: 
[ 1706.106037] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[ 1706.106068]  r7: r6:0060 r5: r4:
[ 1706.106142] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[ 1706.106185] [] (dump_stack) from [] 
(warn_alloc_failed+0xf0/0x134)
[ 1706.106216] [] (warn_alloc_failed) from [] 
(__alloc_pages_nodemask+0x284/0x8fc)
[ 1706.106233]  r3:02200020 r2:
[ 1706.106269]  r5: r4:c0524c40
[ 1706.106336] [] (__alloc_pages_nodemask) from [] 
(new_slab+0x3c4/0x430)
[ 1706.106352]  r10: r9:c0321fdc r8: r7:df401d00 r6:0015 
r5:0220
[ 1706.106422]  r4:df401d00
[ 1706.106460] [] (new_slab) from [] 
(___slab_alloc.constprop.8+0x238/0x298)
[ 1706.106477]  r10: r9:c0321fdc r8:02080020 r7:df401d00 r6:dfbef060 
r5:
[ 1706.106547]  r4:
[ 1706.106581] [] (___slab_alloc.constprop.8) from [] 
(kmem_cache_alloc+0xbc/0xf8)
[ 1706.106597]  r10:00167e93 r9:340285ee r8:e11e1920 r7:6013 r6:02080020 
r5:df401d00
[ 1706.106668]  r4:
[ 1706.106707] [] (kmem_cache_alloc) from [] 
(__build_skb+0x2c/0x98)
[ 1706.106723]  r7:cc592240 r6:06e0 r5:de3523f0 r4:06e0
[ 1706.106784] [] (__build_skb) from [] 
(__napi_alloc_skb+0xb0/0xfc)
[ 1706.106801]  r9:340285ee r8:e11e1920 r7:cc592240 r6:c0520ab8 r5:de3523f0 
r4:06e0
[ 1706.106903] [] (__napi_alloc_skb) from [] 
(rtl8169_poll+0x3a0/0x588)
[ 1706.106920]  r7:de364000 r6:c000fd08 r5:05ea r4:de3523f0
[ 1706.106986] [] (rtl8169_poll) from [] 
(net_rx_action+0x1cc/0x2ec)
[ 1706.107002]  r10:00022548 r9:df471ba8 r8:c05257e0 r7:012c r6:0040 
r5:0001
[ 1706.107073]  r4:de3523f0
[ 1706.107131] [] (net_rx_action) from [] 
(__do_softirq+0xf4/0x254)
[ 1706.107147]  r10:0101 r9:c052618c r8:4001 r7:c0526188 r6:df47 
r5:0003
[ 1706.107218]  r4:
[ 1706.107255] [] (__do_softirq) from [] 
(do_softirq.part.2+0x34/0x40)
[ 1706.107271]  r10:0001 r9:c0525a26 r8:c0c0 r7: r6:deae8a80 
r5:
[ 1706.107341]  r4:2013
[ 1706.107380] [] (do_softirq.part.2) from [] 
(__local_bh_enable_ip+0xac/0xcc)
[ 1706.107396]  r5: r4:0200
[ 1706.107459] [] (__local_bh_enable_ip) from [] 
(release_sock+0x12c/0x158)
[ 1706.107477]  r5: r4:
[ 1706.107538] [] (release_sock) from [] 
(tcp_sendmsg+0xf8/0xa90)
[ 1706.107557]  r10:4040 r9:deae8a80 r8:df471d74 r7:88cd7146 r6:059c 
r5:de8ccb00
[ 1706.107629]  r4:007c r3:0001
[ 1706.107678] [] (tcp_sendmsg) from [] 
(inet_sendmsg+0x3c/0x74)
[ 1706.107695]  r10:df471e2c r9: r8:df7eb604 r7: r6: 
r5:df02c780
[ 1706.107766]  r4:deae8a80
[ 1706.107800] [] (inet_sendmsg) from [] 
(sock_sendmsg+0x1c/0x30)
[ 1706.107816]  r4:df471d74
[ 1706.107849] [] (sock_sendmsg) from [] 
(kernel_sendmsg+0x38/0x40)
[ 1706.107873] [] (kernel_sendmsg) from [] 
(xs_send_kvec+0x94/0x9c)
[ 1706.107891]  r5: r4:df02c780
[ 1706.107934] [] (xs_send_kvec) from [] 
(xs_sendpages+0x6c/0x244)
[ 1706.107950]  r9: r8:df02c780 r7:007c r6:df7eb604 r5:0001 
r4:
[ 1706.108026] [] (xs_sendpages) from [] 
(xs_tcp_send_request+0x80/0x134)
[ 1706.108043]  r10: r9: r8:de8e8000 r7:de0d7258 r6:df7eb604 
r5:0001
[ 1706.108114]  r4:df7eb600
[ 1706.108172] [] (xs_tcp_send_request) from [] 
(xprt_transmit+0x58/0x214)
[ 1706.108192]  r10:de92cc60 r9: r8:d3697fdd r7:df7eb674 r6:de0d7258 
r5:df7eb600
[ 1706.108265]  r4:de8e8000
[ 1706.108303] [] (xprt_transmit) from [] 
(call_transmit+0x18c/0x230)
[ 1706.108321]  r7:df7eb600 r6:0001 r5:df7eb600 r4:de0d7258
[ 1706.108388] [] (call_transmit) from [] 
(__rpc_execute+0x54/0x2c4)
[ 1706.108404]  r8:c0508940 r7: r6:c03b1f08 r5:0001 r4:de0d7258
[ 1706.108475] [] (__rpc_execute) from [] 
(rpc_async_schedule+0x14/0x18)
[ 1706.108493]  r7: r6:dfbf0800 r5:de92cc60 r4:de0d727c
[ 1706.108564] [] (rpc_async_schedule) from [] 
(process_one_work+0x130/0x3ec)
[ 1706.108587] [] (process_one_work) from [] 
(worker_thread+0x50/0x5ac)
[ 1706.108604]  r10:de92cc60 r9:c0508940 r8:0008 r7:c050b220 r6:c0508954 
r5:de92cc78
[ 1706.108675]  r4:c0508940
[ 1706.108718] [] (worker_thread) from 

Re: [PATCH] of: of_mdio: Add marvell,88e1145 to whitelist of PHY compatibilities.

[Aaro Koskinen]

Hi,

On Wed, Feb 03, 2016 at 09:08:57PM +0100, Andrew Lunn wrote:
> On Wed, Feb 03, 2016 at 09:35:29PM +0200, Aaro Koskinen wrote:
> > Commit ae461131960b ("of: of_mdio: Add a whitelist of PHY
> > compatibilities.") missed one compatible string used in in-tree DTBs:
> > in OCTEON, for selected boards, the kernel DTB pruning code will overwrite
> > the DTB compatible string with "marvell,88e1145", which is missing
> > from the whitelist. Add it.
> 
> Does this overwriting means this compatibility is not visible in the
> current DTS files? Or did i miss it?

Yeah, it happens in arch/mips/cavium-octeon/octeon-platform.c:

if (octeon_has_88e1145()) {
fdt_nop_property(initial_boot_params, phy, "marvell,reg-init");
memset(new_name, 0, sizeof(new_name));
strcpy(new_name, "marvell,88e1145");

It took a while for me to figure out this as well... Nasty.

> At least for the Marvell SoCs i intend to submit a patch removing
> these compatible strings from the DTS files. Will you do the same for
> the OCTEON boards?

Yes, for in-tree OCTEON DTS files, I can do the update; the above strcpy
needs to be deleted at the same go, and this needs go through MIPS tree.

A.

Re: [PATCH] of: of_mdio: Add marvell,88e1145 to whitelist of PHY compatibilities.

[Aaro Koskinen]

Hi,

On Wed, Feb 03, 2016 at 12:14:05PM -0800, David Daney wrote:
> On 02/03/2016 12:08 PM, Andrew Lunn wrote:
> >On Wed, Feb 03, 2016 at 09:35:29PM +0200, Aaro Koskinen wrote:
> >>Commit ae461131960b ("of: of_mdio: Add a whitelist of PHY
> >>compatibilities.") missed one compatible string used in in-tree DTBs:
> >>in OCTEON, for selected boards, the kernel DTB pruning code will overwrite
> >>the DTB compatible string with "marvell,88e1145", which is missing
> >>from the whitelist. Add it.
> >
> >Does this overwriting means this compatibility is not visible in the
> >current DTS files? Or did i miss it?
> >
> >At least for the Marvell SoCs i intend to submit a patch removing
> >these compatible strings from the DTS files. Will you do the same for
> >the OCTEON boards?
> 
> The compatibility strings may be present in deployed firmware, they cannot
> be removed. For many OCTEON boards, the device tree is a firmware-kernel
> ABI, it is not practical to unilaterally decide to change the bindings on
> the kernel side as you don't control the firmware.

I agree from practical point of view, but OTOH kernel has never accepted
those bindings as an ABI.

Now users may need to put up with warnings like:

[Firmware Warn]: /soc@0/mdio@118001800/ethernet-phy@7: Whitelisted 
compatible string. Please remove
[Firmware Warn]: /soc@0/mdio@118001800/ethernet-phy@6: Whitelisted 
compatible string. Please remove

if the strings are not updated.

If user loses PHY (like now with EdgeRouter Lite), the string need
to be added to the whitelist. Cannot say if this will be an issue for
firmware DTB OCTEON users; the only firmware DTB board (EdgeRouter Pro)
I have seems to provide correct strings:

broadcom,bcm ethernet-phy-ieee802.3-c22

A.

[PATCH] of: of_mdio: Add marvell,88e1145 to whitelist of PHY compatibilities.

[Aaro Koskinen]

Commit ae461131960b ("of: of_mdio: Add a whitelist of PHY
compatibilities.") missed one compatible string used in in-tree DTBs:
in OCTEON, for selected boards, the kernel DTB pruning code will overwrite
the DTB compatible string with "marvell,88e1145", which is missing
from the whitelist. Add it.

The patch fixes broken networking on EdgeRouter Lite.

Fixes: ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.")
Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---
 drivers/of/of_mdio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 5648317..39c4be4 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -154,6 +154,7 @@ static const struct of_device_id whitelist_phys[] = {
{ .compatible = "marvell,88E", },
{ .compatible = "marvell,88e1116", },
{ .compatible = "marvell,88e1118", },
+   { .compatible = "marvell,88e1145", },
{ .compatible = "marvell,88e1149r", },
{ .compatible = "marvell,88e1310", },
{ .compatible = "marvell,88E1510", },
-- 
2.4.0

Re: [PATCH net 1/2] of: of_mdio: Add a whitelist of PHY compatibilities.

[Aaro Koskinen]

Hi,

On Wed, Jan 27, 2016 at 01:11:38AM +0100, Andrew Lunn wrote:
> Some phy nodes list a compatible value indicating the PHY make/model.
> This is never used to match the device to the driver. However it does
> confuse the code to separate a PHY from a generic MDIO device like a
> switch. Generic MDIO devices must have a compatible value, PHYs can
> list clause 22 or 45, but nothing else.
> 
> Issue a warning if we find a compatible value known on the whitelist,
> and say it is a PHY.
> 
> Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
> Reported-by: Aaro Koskinen <aaro.koski...@nokia.com>
> Reported-by: Olof Johansson <o...@lixom.net>
> Signed-off-by: Andrew Lunn <and...@lunn.ch>

Tested-by: Aaro Koskinen <aaro.koski...@nokia.com>

A.

> ---
>  drivers/of/of_mdio.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index b5aa004a24b6..26c245041493 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -143,11 +143,31 @@ int of_mdio_parse_addr(struct device *dev, const struct 
> device_node *np)
>  }
>  EXPORT_SYMBOL(of_mdio_parse_addr);
>  
> +/* The following is a list of PHY compatible strings which appear in
> + * some DTBs. The compatible string is never matched against a PHY
> + * driver, so is pointless. We only expect devices which are not PHYs
> + * to have a compatible string, so they can be matched to an MDIO
> + * driver.  Encourage users to upgrade there DT blobs to remove these.
> + */
> +static const struct of_device_id whitelist_phys[] = {
> + { .compatible = "brcm,40nm-ephy" },
> + { .compatible = "marvell,88E", },
> + { .compatible = "marvell,88e1116", },
> + { .compatible = "marvell,88e1118", },
> + { .compatible = "marvell,88e1149r", },
> + { .compatible = "marvell,88e1310", },
> + { .compatible = "marvell,88E1510", },
> + { .compatible = "marvell,88E1514", },
> + { .compatible = "moxa,moxart-rtl8201cp", },
> + {}
> +};
> +
>  /*
>   * Return true if the child node is for a phy. It must either:
>   * o Compatible string of "ethernet-phy-idX.X"
>   * o Compatible string of "ethernet-phy-ieee802.3-c45"
>   * o Compatible string of "ethernet-phy-ieee802.3-c22"
> + * o In the white list above (and issue a warning)
>   * o No compatibility string
>   *
>   * A device which is not a phy is expected to have a compatible string
> @@ -166,6 +186,13 @@ static bool of_mdiobus_child_is_phy(struct device_node 
> *child)
>   if (of_device_is_compatible(child, "ethernet-phy-ieee802.3-c22"))
>   return true;
>  
> + if (of_match_node(whitelist_phys, child)) {
> + pr_warn(FW_WARN
> + "%s: Whitelisted compatible string. Please remove\n",
> + child->full_name);
> + return true;
> + }
> +
>   if (!of_find_property(child, "compatible", NULL))
>   return true;
>  
> -- 
> 2.7.0
> 

Re: [BISECTED] v4.5-rc1 phylib regression

[Aaro Koskinen]

Hi,

On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
> On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
> > I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
> > always during systemd boot.
> 
> I think i know what is going on now.
> 
> What does your phy look like in DT?

It's using the in-kernel DT:

arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts

The management interface is "mix0: ethernet@10710". The phy entry
might be bogus for this specific board, and I don't have MARVELL_PHY
enabled...

A.

Re: [PATCH net] of: of_mdio: Ensure mdio device is a PHY

[Aaro Koskinen]

Hi,

On Tue, Jan 26, 2016 at 03:12:30PM +0100, Andrew Lunn wrote:
> of_phy_find_device() is used to find the phy device associated with a
> device node. It is expected the node is for a PHY device, but in fact
> it could of been probed as a generic MDIO device. Ensure the device is
> a PHY before returning it.
> 
> Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
> Reported-by: Aaro Koskinen <aaro.koski...@nokia.com>
> Reported-by: Olof Johansson <o...@lixom.net>
> Signed-off-by: Andrew Lunn <and...@lunn.ch>

This fixes the crash for me, so:

Tested-by: Aaro Koskinen <aaro.koski...@nokia.com>

> ---
> 
> This is only 1/2 the fix. It will stop the NULL pointer dereference in
> the mutex code, but the Ethernet device probe is likely to return an
> error when it cannot find its PHY.

Yes, it's still not possible to actually use mgmt0:

$ ifconfig mgmt0 up
[   74.432849] octeon_mgmt 10710.ethernet: Cannot initialize PHY on MIX0

A.

> ---
>  drivers/of/of_mdio.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 86829f8064a6..b5aa004a24b6 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -256,11 +256,19 @@ static int of_phy_match(struct device *dev, void 
> *phy_np)
>  struct phy_device *of_phy_find_device(struct device_node *phy_np)
>  {
>   struct device *d;
> + struct mdio_device *mdiodev;
> +
>   if (!phy_np)
>   return NULL;
>  
>   d = bus_find_device(_bus_type, NULL, phy_np, of_phy_match);
> - return d ? to_phy_device(d) : NULL;
> + if (d) {
> + mdiodev = to_mdio_device(d);
> + if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY)
> + return to_phy_device(d);
> + }
> +
> + return NULL;
>  }
>  EXPORT_SYMBOL(of_phy_find_device);
>  
> -- 
> 2.7.0
> 

[BISECTED] v4.5-rc1 phylib regression

[Aaro Koskinen]

Hi,

I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
always during systemd boot.

Bisected to:

commit a9049e0c513c4521dbfaa302af8ed08b3366b41f
Author: Andrew Lunn 
Date:   Wed Jan 6 20:11:26 2016 +0100

mdio: Add support for mdio drivers.

[  250.179887] CPU 2 Unable to handle kernel paging request at virtual address 
, epc == 81637bac, ra == 81637b7c
[  250.218161] Oops[#1]:
[  250.224970] CPU: 2 PID: 850 Comm: systemd-network Not tainted 
4.5.0-rc1-octeon-distro.git-test #1
[  250.251569] task: 800031188000 ti: 80002f8e8000 task.ti: 
80002f8e8000
[  250.251586] $ 0   :  81639774  

[  250.251595] $ 4   :   8174 
0001
[  250.251604] $ 8   : 0001  81106100 
00010001
[  250.251613] $12   :  813eb81c 8150be18 

[  250.251622] $16   : 800031290fc0  800031290fc4 
800031188000
[  250.251631] $20   : 0002 0001 800031290fc8 
80002f8eba40
[  250.251640] $24   : 0038 81105fb0
  
[  250.251649] $28   : 80002f8e8000 80002f8eb740 00fff7857f88 
81637b7c
[  250.251651] Hi: 431bde82d7b50717
[  250.251653] Lo: c8de2ac3222855ea
[  250.251668] epc   : 81637bac __mutex_lock_slowpath+0x7c/0x190
[  250.251675] ra: 81637b7c __mutex_lock_slowpath+0x4c/0x190
[  250.251684] Status: 10108ce3 KX SX UX KERNEL EXL IE 
[  250.251686] Cause : 008c (ExcCode 03)
[  250.251688] BadVA : 
[  250.251690] PrId  : 000d0409 (Cavium Octeon+)
[  250.251699] Modules linked in: pata_octeon_cf libata autofs4
[  250.251704] Process systemd-network (pid: 850, threadinfo=80002f8e8000, 
task=800031188000, tls=00fff75ba700)
[  250.251782] Stack : 800031290fc8  0001 
83f9bca0
[  250.251782]800031290c00 81856558 800031290fc0 
800031225000
[  250.251782]0001  800031008800 
814b6284
[  250.251782]81639774 81175dc4 800031290c00 
814baf80
[  250.251782]80003121 814b64ac 80002f8eb810 
80002f8eb810
[  250.251782]814f7790 800031290c00 814baf80 
814baf80
[  250.251782]800031225000  80003290ca10 
814b66a4
[  250.251782]800031225000 800031290c00 0001 
814f7b80
[  250.251782]800031225000 800031225788 800031225830 
1002
[  250.251782]80002f8ebb80 814ba81c 800fb7105c32 
8116aab4
[  250.251782]...
[  250.251784] Call Trace:
[  250.251791] [] __mutex_lock_slowpath+0x7c/0x190
[  250.251801] [] phy_probe+0x6c/0x120
[  250.251807] [] phy_attach_direct+0xdc/0x1a8
[  250.251814] [] phy_connect_direct+0x2c/0x98
[  250.251822] [] of_phy_connect+0x60/0xb8
[  250.251830] [] octeon_mgmt_open+0x36c/0xad0
[  250.251838] [] __dev_open+0x11c/0x1b0
[  250.251844] [] __dev_change_flags+0xa0/0x188
[  250.251850] [] dev_change_flags+0x30/0x78
[  250.251856] [] do_setlink+0x374/0xa38
[  250.251862] [] rtnl_setlink+0xdc/0x120
[  250.251868] [] rtnetlink_rcv_msg+0xac/0x2a0
[  250.251875] [] netlink_rcv_skb+0xf0/0x120
[  250.251880] [] rtnetlink_rcv+0x38/0x48
[  250.251886] [] netlink_unicast+0x1c0/0x2d8
[  250.251891] [] netlink_sendmsg+0x424/0x480
[  250.251898] [] sock_sendmsg+0x24/0x40
[  250.251904] [] SyS_sendto+0xc4/0x108
[  250.251914] [] syscall_common+0x34/0x58
[  250.251918] 
[  250.251936] 
[  250.251936] Code: 24150001  ffa20008  24140002  0858def5  ffb30010 
 fe74  0c58e612  0240202d 
[  250.251983] ---[ end trace 1be6b781dce6d4dc ]---

A.

[PATCH] broadcom: fix PHY_ID_BCM5481 entry in the id table

[Aaro Koskinen]

Commit fcb26ec5b18d ("broadcom: move all PHY_ID's to header")
updated broadcom_tbl to use PHY_IDs, but incorrectly replaced 0x0143bca0
with PHY_ID_BCM5482 (making a duplicate entry, and completely omitting
the original). Fix that.

Fixes: fcb26ec5b18d ("broadcom: move all PHY_ID's to header")
Signed-off-by: Aaro Koskinen <aaro.koski...@iki.fi>
---
 drivers/net/phy/broadcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 07a6119..3ce5d95 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -614,7 +614,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] 
= {
{ PHY_ID_BCM5461, 0xfff0 },
{ PHY_ID_BCM54616S, 0xfff0 },
{ PHY_ID_BCM5464, 0xfff0 },
-   { PHY_ID_BCM5482, 0xfff0 },
+   { PHY_ID_BCM5481, 0xfff0 },
{ PHY_ID_BCM5482, 0xfff0 },
{ PHY_ID_BCM50610, 0xfff0 },
{ PHY_ID_BCM50610M, 0xfff0 },
-- 
2.4.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[iproute PATCH] misc/Makefile: use PKG_CONFIG

[Aaro Koskinen]

Use PKG_CONFIG from Config - it works better when cross-compiling.

Signed-off-by: Aaro Koskinen <aaro.koski...@nokia.com>
---
 misc/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/misc/Makefile b/misc/Makefile
index 389c1b0..f50e740 100644
--- a/misc/Makefile
+++ b/misc/Makefile
@@ -10,8 +10,8 @@ ifeq ($(HAVE_BERKELEY_DB),y)
 endif
 
 ifeq ($(HAVE_SELINUX),y)
-   LDLIBS += $(shell pkg-config --libs libselinux)
-   CFLAGS += $(shell pkg-config --cflags libselinux) -DHAVE_SELINUX
+   LDLIBS += $(shell $(PKG_CONFIG) --libs libselinux)
+   CFLAGS += $(shell $(PKG_CONFIG) --cflags libselinux) -DHAVE_SELINUX
 endif
 
 ifeq ($(IP_CONFIG_SETNS),y)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html