[PATCH] NAPI support for Sibyte MAC

routine. Signed off by: Mark Mason ([EMAIL PROTECTED]) Signed off by: Dan Krejsa ([EMAIL PROTECTED]) Signed off by: Steve Yang ([EMAIL PROTECTED]) Index: linux-2.6.14-cgl/drivers/net/Kconfig === --- linux-2.6.14-cgl.orig

Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

On 10/11/2015 17:14, Mans Rullgard wrote: > This adds a driver for the Aurora VLSI NB8800 Ethernet controller. > It is an almost complete rewrite of a driver originally found in > a Sigma Designs 2.6.22 tree. > > Signed-off-by: Mans Rullgard > --- > Changes: > - Refactored mdio

Re: [PATCH] net: phy: at803x: support interrupt on 8030 and 8035

On 12/11/2015 20:14, Florian Fainelli wrote: > On 12/11/15 11:09, Måns Rullgård wrote: >> On 12 November 2015 19:06:23 GMT+00:00, Mason wrote: >>> On 12/11/2015 18:40, Mans Rullgard wrote: >>>> Commit 77a993942 "phy/at8031: enable at8031 to work on interrupt

Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

On 10/11/2015 20:25, Måns Rullgård wrote: > Mason writes: > >> On 10/11/2015 17:14, Mans Rullgard wrote: >> >>> This adds a driver for the Aurora VLSI NB8800 Ethernet controller. >>> It is an almost complete rewrite of a driver originally found in >>>

Re: [PATCH] net: phy: vitesse: add support for VSC8601

On 12/11/2015 19:41, Mans Rullgard wrote: > + .phy_id = PHY_ID_VSC8601, > + .name = "Vitesse VSC8601", > + .phy_id_mask= 0x0000, > + .features = PHY_GBIT_FEATURES, > + .flags = PHY_HAS_INTERRUPT, > + .config_init= _config_init,

Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[ CCing a few knowledgeable people ] Despite the subject, this is about an Atheros 8035 PHY :-) On 12/11/2015 15:04, Måns Rullgård wrote: > Mason wrote: > >> BTW, you're not using the PHY IRQ, right? I think I remember you saying >> it didn't work reliably? > > It doe

Re: [PATCH] net: phy: at803x: support interrupt on 8030 and 8035

On 12/11/2015 18:40, Mans Rullgard wrote: > Commit 77a993942 "phy/at8031: enable at8031 to work on interrupt mode" > added interrupt support for the 8031 PHY but left out the other two > chips supported by this driver. > > This patch sets the .ack_interrupt and .config_intr functions for the >

Re: Small improvements for the at803x PHY driver

[ CCing people who might be interested in this patch series ] On 26/12/2015 01:26, Martin Blumenstingl wrote: > while trying to debug a problem on a board with an AR8030 PHY (which turned > out to be an incorrectly configured MDC clock) I made a few changes to the > at803x driver. > Due to lack

Re: [PATCH 2/4] net: phy: at803x: Allow specifying the RGMII RX clock delay via phy mode

On 27/12/2015 04:28, Florian Fainelli wrote: > Le 25/12/2015 16:27, Martin Blumenstingl wrote: > >> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c >> index f566b6e..0b262a2 100644 >> --- a/drivers/net/phy/at803x.c >> +++ b/drivers/net/phy/at803x.c >> @@ -36,8 +36,10 @@ >>

Re: [PATCH v8] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

On 25/11/2015 17:16, Måns Rullgård wrote: > Alexander Duyck writes: > >> On Wed, Nov 25, 2015 at 5:04 AM, Måns Rullgård wrote: >> >>> Mason writes: >>> >>>> On 25/11/2015 13:45, Måns Rullgård wrote: >>>> >>>

Re: [PATCH v8] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

On 19/11/2015 14:02, Mans Rullgard wrote: > + if (dma_mapping_error(>dev, dma_addr)) { > + skb_free_frag(data); > + return -ENOMEM; > + } I'm back-porting this driver to 4.1 skb_free_frag() was introduced in 4.2 by 181edb2bfa22b IIUC. +static inline void

Re: [PATCH v8] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[ Using different address for Alexander ] On 25/11/2015 13:36, Mason wrote: > On 19/11/2015 14:02, Mans Rullgard wrote: > >> +if (dma_mapping_error(>dev, dma_addr)) { >> +skb_free_frag(data); >> +return -ENOMEM; >> +} > &

Re: [PATCH v8] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

On 25/11/2015 13:45, Måns Rullgård wrote: > Mason wrote: > >> On 19/11/2015 14:02, Mans Rullgard wrote: >> >>> + if (dma_mapping_error(>dev, dma_addr)) { >>> + skb_free_frag(data); >>> + return -ENOMEM; >>> + } >

Re: [PATCH v3] net: ethernet: support "fixed-link" DT node on nb8800 driver

On 08/02/2016 14:37, Måns Rullgård wrote: > Sebastian Frias wrote: > >> By the way, I know some people like the command line, email, etc. but >> there ought to be other tools better suited for patch review... > > Some kernel subsystems use http://patchwork.ozlabs.org/ to track status > of

[PATCH v6] net: ethernet: nb8800: support fixed-link DT node

-less-connection-to-a-dsa-switch This patch adds support for the "fixed-link" node to the nb8800 driver. Signed-off-by: Sebastian Frias <s...@laposte.net> Acked-by: Mans Rullgard <m...@mansr.com> Cc: Mason <slash@free.fr> --- There were spurious spaces in the prev

Re: [PATCH v5] net: ethernet: nb8800: support fixed-link DT node

On 16/02/2016 21:04, David Miller wrote: > This doesn't apply, please respin against my tree. I fixed several formatting issues with Sebastian's patch, and submitted v6. Regards.

Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB

On 18/03/2016 20:12, Uwe Kleine-König wrote: > On Fri, Mar 18, 2016 at 04:56:21PM +0100, Sebastian Frias wrote: > >> What would you think of making at803x_link_change_notify() print a >> message every time it should do a reset but does not has a way to do it? > > Then this question is obsolete

Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB

On 18/03/2016 21:11, Uwe Kleine-König wrote: > Hello, > > On Fri, Mar 18, 2016 at 08:31:20PM +0100, Mason wrote: > >> On 18/03/2016 20:12, Uwe Kleine-König wrote: >> >>> On Fri, Mar 18, 2016 at 04:56:21PM +0100, Sebastian Frias wrote: >&g

Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB

On 22/03/2016 20:42, Uwe Kleine-König wrote: > Preconditions: > - Some of the devices a given driver handles have a reset line and >others don't. > - A non-empty subset (maybe all) of the devices that have a reset line >require that this reset line is used. > > Then the way to handle

Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB

[ CCing a few devs who might be interested ] On 16/03/2016 18:25, Sebastian Frias wrote: > Commit 687908c2b649 ("net: phy: at803x: simplify using > devm_gpiod_get_optional and its 4th argument") introduced a dependency > on GPIOLIB that was not there before. > > This commit removes such

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 05/07/2016 17:28, Florian Fainelli wrote: > Le 05/07/2016 07:50, Mason wrote: > >> On 05/07/2016 15:33, Mason wrote: >> >>> I was testing suspend/resume sequences where the suspend operation >>> fails and returns without having suspended the platform. Pl

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 12/07/2016 11:53, Mason wrote: > However, the 310 seconds time span still seems to be relevant. > > Steps to reproduce: I booted the system, logged in as root, > mounted an NFS file system, then left the system idling at > the prompt. > > (I don't remember seeing

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 12/07/2016 16:25, Eric Dumazet wrote: > Could you try this debug patch ? Note: I've been unable to trigger the warning again. Dunno what has changed... With your patch applied, I get a warning at boot: [4.668309] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 12/07/2016 16:38, Mason wrote: > With Eric's patch applied, I get this warning at boot: > > [4.668309] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [4.688609] Sending DHCP requests ., OK > [4.711935] IP-Config: Got DHCP answer fro

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 05/07/2016 18:20, Florian Fainelli wrote: > On 07/05/2016 08:56 AM, Mason wrote: >> On 05/07/2016 17:28, Florian Fainelli wrote: >> >>> nb8800.c does not currently show suspend/resume hooks implemented, are >>> you positive that when you suspend, you properly te

WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

Hello, I was testing suspend/resume sequences where the suspend operation fails and returns without having suspended the platform. # echo mem > /sys/power/state [ 90.322264] PM: Syncing filesystems ... done. [ 90.328758] Freezing user space processes ... (elapsed 0.001 seconds) done. [

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 05/07/2016 23:22, Florian Fainelli wrote: > On 07/05/2016 01:26 PM, Mason wrote: >> On 05/07/2016 18:20, Florian Fainelli wrote: >>> On 07/05/2016 08:56 AM, Mason wrote: >>>> On 05/07/2016 17:28, Florian Fainelli wrote: >>>> >>>>&

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 05/07/2016 17:28, Florian Fainelli wrote: > nb8800.c does not currently show suspend/resume hooks implemented, are > you positive that when you suspend, you properly tear down all HW, stop > transmit queues, etc. and do the opposite upon resumption? I am currently testing the error path for

Re: WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x1c4/0x1dc

On 05/07/2016 15:33, Mason wrote: > I was testing suspend/resume sequences where the suspend operation > fails and returns without having suspended the platform. > > # echo mem > /sys/power/state > [ 90.322264] PM: Syncing filesystems ... done. > [ 90.328758] Freezing

Re: Initializing MAC address at run-time

Hello Uwe, On 18/01/2017 19:54, Uwe Kleine-König wrote: > On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote: > >> When my system boots up, eth0 is given a seemingly random MAC address. >> >> [0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38

Initializing MAC address at run-time

Hello, When my system boots up, eth0 is given a seemingly random MAC address. [0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38 [0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4 The DT node for eth0 is: eth0: ethernet@26000 {

Re: Setting link down or up in software

On 18/01/2017 11:29, Zefir Kurtisi wrote: > On 01/13/2017 06:35 PM, Mason wrote: >> On 13/01/2017 17:28, Zefir Kurtisi wrote: >> >>> As for your specific problem: since I fought myself with the PHY/ETH >>> subsystems >>> over the past months, I might

Re: Ethernet not working on a different SoC with same eth HW

On 31/10/2016 16:29, Mason wrote: > I'm using these net drivers: > > drivers/net/ethernet/aurora/nb8800.c > drivers/net/phy/at803x.c > > With a smp8758 board, they work great. > I've been trying to use them on a different board: > > same eth PHY (Atheros AR803

Re: Ethernet not working on a different SoC with same eth HW

On 08/11/2016 16:41, Mason wrote: > On 31/10/2016 16:29, Mason wrote: > >> I'm using these net drivers: >> >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> With a smp8758 board, they work great. >> I've been trying to

Re: Debugging Ethernet issues

On 13/11/2016 04:09, Andrew Lunn wrote: > Mason wrote: > >> When connected to a Gigabit switch >> 3.4 negotiates a LAN DHCP setup instantly >> 4.7 requires over 5 seconds to do so > > When you run tcpdump on the DHCP server, are you noticing the first > request

Re: Debugging Ethernet issues

On 14/11/2016 13:13, Mason wrote: > This is a different log which I got earlier, but can no longer reproduce: > > # tcpdump -n -i eth1-boards ether host 00:16:e8:4b:b0:7d > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth1-boards, l

Re: Debugging Ethernet issues

On 13/11/2016 20:55, Florian Fainelli wrote: > Le 13/11/2016 à 11:51, Mason a écrit : >> On 13/11/2016 04:09, Andrew Lunn wrote: >> >>> Mason wrote: >>> >>>> When connected to a Gigabit switch >>>> 3.4 negotiates a LAN DHCP setup instantly &

Re: Debugging Ethernet issues

On 14/11/2016 14:34, Andrew Lunn wrote: > Mason wrote: > >> How exactly does one use the generic PHY driver? > > If there is no specific driver available for the PHY, linux will fall > back to the generic driver. So just don't compile the specific driver. > You can see

Re: Debugging Ethernet issues

On 14/11/2016 15:58, Mason wrote: > nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx > vs > nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off > > I'm not sure whether "flow control" is relevant... Based on phy_print_sta

Re: [PATCH net-next v2 3/4] Documentation: net: phy: Add blurb about RGMII

On 28/11/2016 18:43, Florian Fainelli wrote: > On 11/28/2016 02:34 AM, Sebastian Frias wrote: > >> For what is worth, the Atheros at803x driver comes with RX delay enabled >> as per HW reset. > > Always, or is this a behavior possibly defined via a stra-pin that can > be changed? Here's the

Debugging Ethernet issues

Hello everyone, In a past thread ("Ethernet not working on a different SoC with same eth HW") I was struggling getting Ethernet to work at all on a new board using a recent 4.7 kernel. After much hair-pulling, it turned out that *some* of the breakage was caused by a local patch which should

Re: Debugging Ethernet issues

On 13/11/2016 04:09, Andrew Lunn wrote: > Mason wrote: > >> When connected to a Gigabit switch >> 3.4 negotiates a LAN DHCP setup instantly >> 4.7 requires over 5 seconds to do so > > When you run tcpdump on the DHCP server, are you noticing the first > request

Re: Debugging Ethernet issues

On 14/11/2016 22:00, Florian Fainelli wrote: > No I missed that, way too many emails, really. Sorry, I was trying to be thorough, but I went overboard. I'll start a new thread tomorrow, with a smaller CC list (only those who have participated so far) and I'll try to remain concise. Regards.

Re: Debugging Ethernet issues

On 14/11/2016 19:20, Florian Fainelli wrote: > On 11/14/2016 09:59 AM, Sebastian Frias wrote: > >> Could you confirm that Mason's patch is correct and/or that it does not >> has negative side-effects? > > The patch is not correct nor incorrect per-se, it changes the default > policy of having

Re: Ethernet not working on a different SoC with same eth HW

On 31/10/2016 16:37, Andrew Lunn wrote: >> The regnum=5,4,1,1,a,9 logs keep repeating, endlessly. >> Is that expected? > > Yes, that is expected, if you are not using interrupts. The phylib > state machine polls the state of the PHY once per second to see if > there has been a link up/down.

Ethernet not working on a different SoC with same eth HW

Hello everyone, I'm using these net drivers: drivers/net/ethernet/aurora/nb8800.c drivers/net/phy/at803x.c With a smp8758 board, they work great. I've been trying to use them on a different board: same eth PHY (Atheros AR8035) same eth MAC (Aurora SSN8800) different SoC (same base

Re: Ethernet not working on a different SoC with same eth HW

On 31/10/2016 16:53, Andrew Lunn wrote: >> I'll add a log for the request_irq call. > > And take a look at /proc/interrupts You're right, there does seem to be something wrong with the interrupts. # cat /proc/interrupts CPU0 20: 26285 GIC-0 29 Edge twd IPI0:

Re: Ethernet not working on a different SoC with same eth HW

On 04/11/2016 15:04, Måns Rullgård wrote: > Andrew Lunn writes: > >>> Considering the ethernet DT bindings: >>> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet.txt >>> >>> Specifically, phy-mode values "rgmii", "rgmii-id", "rgmii-rxid", >>>

Re: Ethernet not working on a different SoC with same eth HW

On 04/11/2016 14:40, Måns Rullgård wrote: > Mason <slash@free.fr> writes: > >> On 31/10/2016 17:28, Mason wrote: >> >>> On 31/10/2016 16:53, Andrew Lunn wrote: >>> >>>>> I'll add a log for the request_irq call. >>>> >

Re: Ethernet not working on a different SoC with same eth HW

On 31/10/2016 17:28, Mason wrote: > On 31/10/2016 16:53, Andrew Lunn wrote: > >>> I'll add a log for the request_irq call. >> >> And take a look at /proc/interrupts > > You're right, there does seem to be something wrong with the interrupts. Having fixed tha

Re: Ethernet not working on a different SoC with same eth HW

>>> >>> Those few drivers that do anything differently based on these values >>> enable clock delay in the MAC. That's why I wrote the NB8800 driver the >>> way I did. >>> >> >> I don't really what is wrong with the nb8800 driver at the moment, so

Setting link down hangs the kernel

Hello, I'm using kernel v4.9 on a dev board. I built a small kernel + rootfs with buildroot 2016.11.1 eth0 is driven by drivers/net/ethernet/aurora/nb8800.c After booting, I just run udhcpc (busybox version) Then I set the link down, and the kernel hangs. Here's the console output: [

Re: Setting link down or up in software

On 13/01/2017 17:28, Zefir Kurtisi wrote: > As for your specific problem: since I fought myself with the PHY/ETH > subsystems > over the past months, I might remember something relevant to your issue. > Could you > give some more info on your setup (PHY driver, opmode (SGMII, RGMII, etc.), >

Re: Setting link down or up in software

On 12/01/2017 14:05, Mason wrote: > I'm wondering what are the semantics of calling > > ip link set dev eth0 down > > I was expecting that to somehow instruct the device's ethernet driver > to shut everything down, have the PHY tell the peer that it's going > away, m

Setting link down or up in software

Hello, I'm wondering what are the semantics of calling ip link set dev eth0 down I was expecting that to somehow instruct the device's ethernet driver to shut everything down, have the PHY tell the peer that it's going away, maybe even put the PHY in some low-power mode, etc. But it

Re: Setting link down or up in software

On 12/01/2017 16:28, Andrew Lunn wrote: > Mason wrote: > >> Here's an example of "Link is Down" printed when I set link up: >> >> At [ 62.750220] I run ip link set dev eth0 down >> Then leave the system idle for 10 minutes. >> At [ 646.263041] I r

Re: Setting link down or up in software

On 13/01/2017 10:20, Zefir Kurtisi wrote: > On 01/12/2017 04:16 PM, Mason wrote: >> On 12/01/2017 14:05, Mason wrote: >> >>> I'm wondering what are the semantics of calling >>> >>> ip link set dev eth0 down >>> >>> I was exp

Re: Setting link down hangs the kernel

On 10/01/2017 16:28, Mason wrote: > On 10/01/2017 15:36, Mason wrote: > >> I'm using kernel v4.9 on a [new] dev board. >> I built a small kernel + rootfs with buildroot 2016.11.1 >> eth0 is driven by drivers/net/ethernet/aurora/nb8800.c >> >> After booting

Re: Setting link down hangs the kernel

On 10/01/2017 15:36, Mason wrote: > I'm using kernel v4.9 on a [new] dev board. > I built a small kernel + rootfs with buildroot 2016.11.1 > eth0 is driven by drivers/net/ethernet/aurora/nb8800.c > > After booting, I just run udhcpc (busybox version) > Then I set the link do

Re: [PATCH net 04/16] net: ethernet: aurora: nb8800: fix fixed-link phydev leaks

On 28/11/2016 19:24, Johan Hovold wrote: > Make sure to deregister and free any fixed-link PHY registered using > of_phy_register_fixed_link() on probe errors and on driver unbind. > > Fixes: c7dfe3abf40e ("net: ethernet: nb8800: support fixed-link DT node") > Signed-off-by: Johan Hovold

Legacy features in PCI Express devices

Hello, There are two revisions of our PCI Express controller. Rev 1 did not support the following features: 1) legacy PCI interrupt delivery (INTx signals) 2) I/O address space Internally, someone stated that such missing support would prevent some PCIe cards from working with our

Re: Legacy features in PCI Express devices

On 13/03/2017 18:12, Robin Murphy wrote: > On 13/03/17 16:10, Mason wrote: > >> There are two revisions of our PCI Express controller. >> >> Rev 1 did not support the following features: >> >> 1) legacy PCI interrupt delivery (INTx signals) >> 2) I

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 17:18, Florian Fainelli wrote: > On 07/29/2017 05:02 AM, Mason wrote: > >> I have identified a 100% reproducible flaw. >> I have proposed a work-around that brings this down to 0 >> (tested 1000 cycles of link up / ping / link down). > > Can you als

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 14:05, Måns Rullgård wrote: > Mason writes: > >> I'll take this opportunity to change flow control to >> off by default (it breaks several 100 Mbps switches). > > I was told to have it on by default. This is what most other drivers > do too. If you h

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 13:24, Måns Rullgård wrote: > Until you figure out why it's getting stuck, we can't be sure > it isn't caused by something that could trigger at any time. Would you take a look at it, if I can reproduce on tango4? I have identified a 100% reproducible flaw. I have proposed a

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 31/07/2017 16:08, Mason wrote: > Other things make no sense to me, for example in nb8800_dma_stop() > there is a polling loop: > > do { > mdelay(100); > nb8800_writel(priv, NB8800_TX_DESC_ADDR, txb->dma_desc); > wmb(); &g

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 31/07/2017 13:59, Måns Rullgård wrote: > Mason writes: > >> On 29/07/2017 17:18, Florian Fainelli wrote: >> >>> On 07/29/2017 05:02 AM, Mason wrote: >>> >>>> I have identified a 100% reproducible flaw. >>>> I have proposed a wor

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 22:15, Florian Fainelli wrote: > On 07/29/2017 05:44 AM, Mason wrote: > >> We tested 4 switches, and DHCP failed on 3 of them. >> Disabling pause frames "fixed" that. > > OK, so it is this problem that you reported about before? The "Ethe

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 19:31, Mason wrote: > # iperf3 -c 172.27.64.45 -u -b 950M > Connecting to host 172.27.64.45, port 5201 > [ 4] local 172.27.64.1 port 55533 connected to 172.27.64.45 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 22:02, Mason wrote: > I need to run the test slightly slower, to prevent packet loss > at the sender. # iperf3 -c 172.27.64.45 -u -b 0 -l 1000 Connecting to host 172.27.64.45, port 5201 [ 4] local 172.27.64.1 port 42607 connected to 172.27.64.45 port 5201 [ ID] In

Re: [RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open

On 02/08/2017 13:02, Måns Rullgård wrote: > Mason wrote: > >> Move all HW initializations to nb8800_init. >> This provides the basis for suspend/resume support. >> --- >> drivers/net/ethernet/aurora/nb8800.c | 50 >> +--- >

Quirks of the Atheros 8035 PHY

Hello, I've discussed this subject in the past, but we never reached a conclusion, AFAIR. The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays. https://www.redeszone.net/app/uploads/2014/04/AR8035.pdf 1) RX clock delay Commit 2e5f9f281ee8369f56d403b4a52942f19b6978f8 In fact, RX

Re: Quirks of the Atheros 8035 PHY

On 14/07/2017 23:28, Florian Fainelli wrote: > On 07/14/2017 02:08 PM, Mason wrote: > >> I've discussed this subject in the past, but we never reached >> a conclusion, AFAIR. >> >> The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays. >> >> htt

Re: Quirks of the Atheros 8035 PHY

Mugunthan's address bounces. Removing it. Adding Grygorii's address instead. On 14/07/2017 23:08, Mason wrote: > Hello, > > I've discussed this subject in the past, but we never reached > a conclusion, AFAIR. > > The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 23:34, Florian Fainelli wrote: > How about you start reading the RGMII specification so we can at least, > if nothing else agree on the terminology? It's public: > > http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf Thanks for linking the

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 00:39, Florian Fainelli wrote: > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index d0626bf5c540..652e24b53f3f 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -968,6 +968,8 @@ void phy_stop(struct phy_device *phydev) > * of

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 12:51, Mason wrote: > Moving the call to phy_stop() down after all the MAC tear down > avoids the hang. > > As far as I understand, when we are shutting everything down, > we don't need the phy_state_machine to run asynchronously. > We can run it synchronously o

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 13:07, Mason wrote: > When I set the link down via 'ip link set eth0 down' > (as opposed to pulling the Ethernet cable) things don't happen as expected: > > The driver's adjust_link() callback is never called, and doesn't > get a chance make some required changes.

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 18:49, Florian Fainelli wrote: > On 07/24/2017 08:01 AM, Mason wrote: > >>> When I set the link down via 'ip link set eth0 down' >>> (as opposed to pulling the Ethernet cable) things don't happen as expected: >>> >>> The driver's adjust_li

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 20/07/2017 14:33, Mason wrote: > As [Florian] pointed out, the spec states that the > "Data to Clock input Skew (at Receiver)" > must be within [ 1.0, 2.6 ] ns. > > I understand that 2 ns is 1/4 of a 125 MHz period, > but it's not clear to me why the above i

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 21:53, Florian Fainelli wrote: > Well now that I see the possible interrupts generated, I indeed don't > see how you can get a link down notification unless you somehow force > the link down yourself, which would certainly happen in phy_suspend() > when we set BMCR.pwrdwn, but that

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 24/07/2017 23:49, Florian Fainelli wrote: > On 07/24/2017 02:21 PM, Mason wrote: >> On 20/07/2017 14:33, Mason wrote: >> >>> As [Florian] pointed out, the spec states that the >>> "Data to Clock input Skew (at Receiver)" >>> must be within [

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 00:36, Florian Fainelli wrote: > On 07/24/2017 02:20 PM, Mason wrote: >> On 24/07/2017 21:53, Florian Fainelli wrote: >> >>> Well now that I see the possible interrupts generated, I indeed don't >>> see how you can get a link down notification unle

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 19:17, Måns Rullgård wrote: > Marc Gonzalez writes: > >> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672 >> ("Documentation: devicetree: clarify usage of the RGMII phy-modes") >> there are 4 RGMII phy-modes to handle: >> >> "rgmii" (RX and TX delays are added by the

Re: [PATCH 1/2] net: phy: at803x: Fix RGMII RX and TX clock delays setup

On 19/07/2017 21:30, Florian Fainelli wrote: > On 07/19/2017 12:24 PM, Grygorii Strashko wrote: >> Hi >> >> On 07/19/2017 10:31 AM, Marc Gonzalez wrote: >>> The current code supports enabling RGMII RX and TX clock delays. >>> The unstated assumption is that these settings are disabled by >>>

Problem with PHY state machine when using interrupts

Hello, When I set the link down via 'ip link set eth0 down' (as opposed to pulling the Ethernet cable) things don't happen as expected: The driver's adjust_link() callback is never called, and doesn't get a chance make some required changes. And when I set the link up again, there is no network

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 20:30, Florian Fainelli wrote: > On 07/19/2017 10:36 AM, Mason wrote: >> On 19/07/2017 19:17, Måns Rullgård wrote: >> >>> Marc Gonzalez writes: >>> >>>> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672 >>>> ("D

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 28/07/2017 20:56, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 28/07/2017 18:17, Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> ndo_stop breaks RX in a way that ndo_open is unable to undo. >>> >>> Please elaborate. Why can't it be fixed in a less heavy-handed way? >> >>

[RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open

Move all HW initializations to nb8800_init. This provides the basis for suspend/resume support. --- drivers/net/ethernet/aurora/nb8800.c | 50 +--- drivers/net/ethernet/aurora/nb8800.h | 1 + 2 files changed, 25 insertions(+), 26 deletions(-) diff --git

[RFC PATCH v2 0/2] nb8800 suspend/resume support

Hello, I need suspend/resume support in the nb8800 driver. On tango platforms, suspend loses all context (MMIO registers). To make the task easy, we just close the device on suspend, and open it again on resume. This requires properly resetting the HW on resume. Patch 1 moves all the HW init to

[RFC PATCH v2 2/2] net: ethernet: nb8800: Add suspend/resume support

Wrappers around nb8800_stop and nb8800_open. --- drivers/net/ethernet/aurora/nb8800.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c index aa18ea25d91f..607064a6d7a1 100644

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 01/08/2017 18:32, Mason wrote: > I need suspend/resume support in the nb8800 driver. > On tango platforms, suspend loses all context (MMIO registers). > To make the task easy, we just close the device on suspend, > and open it again on resume. This requires properly resett

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 18:10, Måns Rullgård wrote: > ping -f is limited to 100 packets per second. > Use something like iperf in UDP mode instead. CLIENT: DESKTOP # iperf3 -c 172.27.64.45 -u -b 950M Connecting to host 172.27.64.45, port 5201 [ 4] local 172.27.64.1 port 55533 connected to 172.27.64.45

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 18:10, Måns Rullgård wrote: > Mason writes: > >> On 02/08/2017 17:56, Måns Rullgård wrote: >> >>> What does the tango5 do if you flood it with packets faster than the >>> kernel can keep up with? That would make it hit the end of the rx >&

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 17:56, Måns Rullgård wrote: > Mason writes: > >> From my perspective, the older method does not work on newer chips :-) > > It does work on tango4. Agreed. > What does the tango5 do if you flood it with packets faster than the > kernel can keep up with?

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 17:36, Måns Rullgård wrote: > Mason wrote: > >> Looking at the tango-specific integration, I note this nugget: >> >> 1.5.4 Stopping & Starting the DMA >> >> This feature has been added to allow the software to stop and start >> the

Toggling link state breaks network connectivity

Hello, I am using the following drivers for Ethernet connectivity. drivers/net/ethernet/aurora/nb8800.c drivers/net/phy/at803x.c Pulling the cable and plugging it back works as expected. (I can ping both before and after.) However, if I toggle the link state in software (using ip link set), the

Re: Toggling link state breaks network connectivity

Hello Florian, On 12/06/2017 18:38, Florian Fainelli wrote: > On 06/12/2017 06:22 AM, Mason wrote: > >> I am using the following drivers for Ethernet connectivity. >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> Pulling the cable an

Re: Toggling link state breaks network connectivity

On 13/06/2017 11:39, Matthias May wrote: > On 12/06/17 15:22, Mason wrote: >> Hello, >> >> I am using the following drivers for Ethernet connectivity. >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> Pulling the cable and plugg

Re: Toggling link state breaks network connectivity

On 13/06/2017 17:50, Florian Fainelli wrote: > On 06/13/2017 08:47 AM, Mason wrote: > >> If I unplug/replug the cable, ping still works afterward. >> (Packet RX appears to be *not* wedged) >> >> If I toggle the link state in SW (set link down/set link up), >

  1   2   3   >