netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next v2 0/10] stmmac cleanups
@ 2023-08-24 13:37 Russell King (Oracle)
  2023-08-24 13:37 ` [PATCH net-next 01/10] net: phylink: add phylink_limit_mac_speed() Russell King (Oracle)
                   ` (10 more replies)
  0 siblings, 11 replies; 17+ messages in thread
From: Russell King (Oracle) @ 2023-08-24 13:37 UTC (permalink / raw)
  To: Alexandre Torgue, Jose Abreu
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Feiyang Chen,
	Heiner Kallweit, Jakub Kicinski, linux-arm-kernel, linux-stm32,
	Maxime Coquelin, netdev, Paolo Abeni

Hi,

One of the comments I had on Feiyang Chen's series was concerning the
initialisation of phylink... and so I've decided to do something about
it, cleaning it up a bit.

This series:

1) adds a new phylink function to limit the MAC capabilities according
   to a maximum speed. This allows us to greatly simplify stmmac's
   initialisation of phylink's mac capabilities.

2) everywhere that uses priv->plat->phylink_node first converts this
   to a fwnode before doing anything with it. This is silly. Let's
   instead store it as a fwnode to eliminate these conversions in
   multiple places.

3) clean up passing the fwnode to phylink - it might as well happen
   at the phylink_create() callsite, rather than being scattered
   throughout the entire function.

4) same for mdio_bus_data

5) use phylink_limit_mac_speed() to handle the priv->plat->max_speed
   restriction.

6) add a method to get the MAC-specific capabilities from the code
   dealing with the MACs, and arrange to call it at an appropriate
   time.

7) convert the gmac4 users to use the MAC specific method.

8) same for xgmac.

9) group all the simple phylink_config initialisations together.

10) convert half-duplex logic to being positive logic.

While looking into all of this, this raised eyebrows:

        if (priv->plat->tx_queues_to_use > 1)
                priv->phylink_config.mac_capabilities &=
                        ~(MAC_10HD | MAC_100HD | MAC_1000HD);

priv->plat->tx_queues_to_use is initialised by platforms to either 1,
4 or 8, and can be controlled from userspace via the --set-channels
ethtool op. The implementation of this op in this driver limits the
number of channels to priv->dma_cap.number_tx_queues, which is derived
from the DMA hwcap.

So, the obvious questions are:

1) what guarantees that the static initialisation of tx_queues_to_use
will always be less than or equal to number_tx_queues from the DMA hw
cap?

2) tx_queues_to_use starts off as 1, but number_tx_queues is larger,
we will leave the half-duplex capabilities in place, but userspace can
increase tx_queues_to_use above 1. Does that mean half-duplex is then
not supported?

3) Should we be basing the decision whether half-duplex is supported
off the DMA capabilities?

4) What about priv->dma_cap.half_duplex? Doesn't that get a say in
whether half-duplex is supported or not? Why isn't this used? Why is
it only reported via debugfs? If it's not being used by the driver,
what's the point of reporting it via debugfs?

 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  8 +++
 .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    | 10 ++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h         |  4 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 60 +++++++++-------------
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c  |  3 +-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  2 +-
 drivers/net/phy/phylink.c                          | 18 +++++++
 include/linux/phylink.h                            |  2 +
 include/linux/stmmac.h                             |  2 +-
 9 files changed, 70 insertions(+), 39 deletions(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2023-08-26 19:01 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-24 13:37 [PATCH net-next v2 0/10] stmmac cleanups Russell King (Oracle)
2023-08-24 13:37 ` [PATCH net-next 01/10] net: phylink: add phylink_limit_mac_speed() Russell King (Oracle)
2023-08-24 13:37 ` [PATCH net-next 02/10] net: stmmac: convert plat->phylink_node to fwnode Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 03/10] net: stmmac: clean up passing fwnode to phylink Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 04/10] net: stmmac: use "mdio_bus_data" local variable Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 05/10] net: stmmac: use phylink_limit_mac_speed() Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 06/10] net: stmmac: provide stmmac_mac_phylink_get_caps() Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 07/10] net: stmmac: move gmac4 specific phylink capabilities to gmac4 Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 08/10] net: stmmac: move xgmac specific phylink caps to dwxgmac2 core Russell King (Oracle)
2023-08-26 13:32   ` Serge Semin
2023-08-26 14:51     ` Russell King (Oracle)
2023-08-26 19:01       ` Serge Semin
2023-08-26 13:36   ` Serge Semin
2023-08-26 14:53     ` Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 09/10] net: stmmac: move priv->phylink_config.mac_managed_pm Russell King (Oracle)
2023-08-24 13:38 ` [PATCH net-next 10/10] net: stmmac: convert half-duplex support to positive logic Russell King (Oracle)
2023-08-26  2:00 ` [PATCH net-next v2 0/10] stmmac cleanups patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).