Moving Octeon ethernet out of staging
Hi there,
Octeon ethernet drivers were once kicked out of staging, just to be returned back a while after:
https://lore.kernel.org/lkml/[email protected]/
All that patchset ends with an optimistic comment:
Quoted 4 lines · On Wed, 2020-03-04 Chris Packham wrote:
I have had a reply from Marvell. They've contracted support for the old Cavium Octeon designs out to an external company. I'm not sure that means that we'll see some action on these drivers any time soon but at least they're doing something.
Now based on Marvell's 277 patches long set against 5.4.30 it seems that 'an external company' is Wipro and 'doing something' is the exact opposite to 'make driver self-contained' as described in drivers/staging/octeon/TODO
That patchset contains dozen of *Sync-up-SE* patches which basically dumps mainline changes and replaces platform files with the BSD licensed ones common for Linux, U-Boot and Cavium tools. Ethernet driver is then synced to that changes, making it even more dependent on arch/mips/cavium-octeon code.
To fix staging driver to work with customer's CN7020 based board I'd had to either go Marvell's direction or use DT for driver configuration, so I partially did the latter. It is probably broken for anything else than CN70XX and it breaks the ABI, newer kernel will not work with older bindings. Is that okay for staging drivers? Does anyone even intend to use mainline kernel with Octeon SoCs? Of course I'd be happy hearing something changed at Marvell and they are willing to mainline support for their MIPS based SoCs ;-)
ladis
Hi Ladis,
Quoted 22 lines · Ladislav Michl
Hi there,
Octeon ethernet drivers were once kicked out of staging, just to be returned back a while after:
https://scanmail.trustwave.com/?c=20988&d=_eyq4wb_Cf8A27MjylFU_gZpLMEEtZOmwZm-lqT0RQ&u=https%3a%2f%2flore%2ekernel%2eorg%2flkml%2f20200205001116%2e14096-1-chris%2epackham%40alliedtelesis%2eco%2enz%2fAll that patchset ends with an optimistic comment:
Quoted 4 lines · On Wed, 2020-03-04 Chris Packham wrote:
I have had a reply from Marvell. They've contracted support for the old Cavium Octeon designs out to an external company. I'm not sure that means that we'll see some action on these drivers any time soon but at least they're doing something.
Now based on Marvell's 277 patches long set against 5.4.30 it seems that 'an external company' is Wipro and 'doing something' is the exact opposite to 'make driver self-contained' as described in
drivers/staging/octeon/TODOThat patchset contains dozen of *Sync-up-SE* patches which basically dumps mainline changes and replaces platform files with the BSD licensed ones common for Linux, U-Boot and Cavium tools. Ethernet driver is then synced to that changes, making it even more dependent on
arch/mips/cavium-octeoncode.
Quoted 8 lines
To fix staging driver to work with customer's CN7020 based board I'd had to either go Marvell's direction or use DT for driver configuration, so I partially did the latter. It is probably broken for anything else than CN70XX and it breaks the ABI, newer kernel will not work with older bindings. Is that okay for staging drivers? Does anyone even intend to use mainline kernel with Octeon SoCs? Of course I'd be happy hearing something changed at Marvell and they are willing to mainline support for their MIPS based SoCs ;-)
From our end we still have our Octeon MIPS based routers which we still
want to support but for various reasons these aren't seeing the kernel updates that I might like. And because these are technically legacy I'm having a hard time convincing anyone to dedicate any resources to helping with any effort to improve these drivers (whatever is happening is just "spare time" work).
As a user I can say that we'd probably be OK if we had to make some dts updates as we ship our kernel+dtb+initrd as a FIT image so we can update the kernel+dtb at the same time if necessary.
Hi Chris,
[snip]
Quoted 6 lines · Chris Packham
From our end we still have our Octeon MIPS based routers which we still want to support but for various reasons these aren't seeing the kernel updates that I might like. And because these are technically legacy I'm having a hard time convincing anyone to dedicate any resources to helping with any effort to improve these drivers (whatever is happening is just "spare time" work).
At this end, the intention is still to use mainline kernel. So far the show-stoppers are SFP and AGL support. Therefore TODO list looks like:
1. Covert driver to use PHYLINK (see attached patch)
2. Implement phylink_mac_ops using code from arch/mips/cavium-octeon/executive (cvmx-helper-rgmii.c, cvmx-helper-sgmii.c, etc...)
3. Now it should be easy to add AGL after DT representation is decided.
4. Fix GPIO driver as it does not currently service interrupts, causing troubles to both SFP and MDIO hanging there.
5. Let people test it.
6. Move out of staging ;-)
Quoted 3 lines
As a user I can say that we'd probably be OK if we had to make some dts updates as we ship our kernel+dtb+initrd as a FIT image so we can update the kernel+dtb at the same time if necessary.
Indeed, it all boils down to DT representation. I'd probably go with topology, interfaces and port register address taken from device tree.
Patch bellow does not make things worse and you'll get SFP for free.
There are some glitches, for example setting ports up:octeon_ethernet 11800a0000000.pip eth0: configuring for inband/1000base-x link mode octeon_ethernet 11800a0000000.pip eth1: PHY [8001180000001800:00] driver [Generic PHY] (irq=POLL) octeon_ethernet 11800a0000000.pip eth1: configuring for phy/sgmii link mode octeon_ethernet 11800a0000000.pip eth2: PHY [8001180000001800:01] driver [Generic PHY] (irq=POLL) octeon_ethernet 11800a0000000.pip eth2: configuring for phy/sgmii link mode octeon_ethernet 11800a0000000.pip eth0: switched to inband/sgmii link mode octeon_ethernet 11800a0000000.pip eth0: PHY [i2c:sfp:16] driver [Marvell 88E1111] (irq=POLL) octeon_ethernet 11800a0000000.pip eth3: PHY [8001180000001800:02] driver [Marvell 88E1340S] (irq=25) octeon_ethernet 11800a0000000.pip eth3: configuring for phy/sgmii link mode octeon_ethernet 11800a0000000.pip eth4: PHY [8001180000001800:03] driver [Marvell 88E1340S] (irq=25) octeon_ethernet 11800a0000000.pip eth4: configuring for phy/sgmii link mode octeon_ethernet 11800a0000000.pip eth1: Link is Up - 100Mbps/Full - flow control off I do not know why are eth1 and eth2 attached to Generic PHY, while
the rest to the Marvell 88E1111 - all nodes are the same.
Comments welcome,
ladis
From: Ladislav Michl <[email protected]>
Subject: [PATCH] staging: octeon: phylink
--- drivers/staging/octeon/Kconfig | 2 +- drivers/staging/octeon/ethernet-mdio.c | 171 ++++++++++++++--------- drivers/staging/octeon/ethernet-rgmii.c | 13 +- drivers/staging/octeon/ethernet.c | 55 +++----- drivers/staging/octeon/octeon-ethernet.h | 8 +- 5 files changed, 131 insertions(+), 118 deletions(-)
drivers/staging/octeon/Kconfig +1 -1
@@ -3,7 +3,7 @@ config OCTEON_ETHERNET tristate "Cavium Networks Octeon Ethernet support" depends on CAVIUM_OCTEON_SOC || COMPILE_TEST depends on NETDEVICES - select PHYLIB + select PHYLINK select MDIO_OCTEON help This driver supports the builtin ethernet ports on Cavium
drivers/staging/octeon/ethernet-mdio.c +106 -65
238 lines not on this page · raw message
drivers/staging/octeon/ethernet-rgmii.c +2 -11
@@ -115,17 +115,8 @@ static void cvm_oct_rgmii_poll(struct net_device *dev)cvm_oct_check_preamble_errors (dev); -if (likely (!status_change)) -return ; - -/* Tell core. */ -if (link_info.s.link_up) { -if (!netif_carrier_ok (dev)) -netif_carrier_on (dev); - }else if (netif_carrier_ok (dev)) { -netif_carrier_off (dev); - } -cvm_oct_note_carrier (priv, link_info); +if (likely (status_change)) +phylink_mac_change (priv->phylink, link_info.s.link_up); }int cvm_oct_rgmii_open (struct net_device *dev)
drivers/staging/octeon/ethernet.c +18 -37
108 lines not on this page · raw message
drivers/staging/octeon/octeon-ethernet.h +4 -4
@@ -12,7 +12,7 @@#define OCTEON_ETHERNET_H #include <linux/of.h> -#include <linux/phy.h> +#include <linux/phylink.h> #ifdef CONFIG_CAVIUM_OCTEON_SOC
@@ -62,6 +62,8 @@ struct octeon_ethernet {int imode;/* PHY mode */ phy_interface_t phy_mode; +struct phylink *phylink; +struct phylink_config phylink_config;/* List of outstanding tx buffers per queue */ struct sk_buff_head tx_free_list[16 ];unsigned int last_speed;
@@ -69,6 +71,7 @@ struct octeon_ethernet {/* Last negotiated link state */ u64 link_info;/* Called periodically to check link status */ +bool poll_used;void (*poll)(struct net_device *dev);struct delayed_work port_periodic_work;struct device_node *of_node;
@@ -86,12 +89,9 @@ void cvm_oct_spi_uninit(struct net_device *dev);int cvm_oct_common_init (struct net_device *dev);void cvm_oct_common_uninit (struct net_device *dev); -void cvm_oct_adjust_link (struct net_device *dev);int cvm_oct_common_stop (struct net_device *dev);int cvm_oct_common_open (struct net_device *dev,void (*link_poll)(struct net_device *)); -void cvm_oct_note_carrier (struct octeon_ethernet *priv, -union cvmx_helper_link_info li);void cvm_oct_link_poll (struct net_device *dev);extern int always_use_pow;
Signature · 1 line
2.32.0