Re: [PATCH net-next v4 2/9] net: stmmac: xgmac: add more feature parsing from hw cap
From: Serge Semin
Date: Mon Aug 21 2023 - 09:25:51 EST
Hi Russel, Andrew
On Sun, Aug 20, 2023 at 08:51:41PM +0100, Russell King (Oracle) wrote:
> On Sun, Aug 20, 2023 at 09:15:06PM +0200, Andrew Lunn wrote:
> > On Wed, Aug 16, 2023 at 11:29:19PM +0800, Jisheng Zhang wrote:
> > > The XGMAC_HWFEAT_GMIISEL bit also indicates whether support 10/100Mbps
> > > or not.
> >
> > The commit message fails to explain the 'Why?' question. GMII does
> > normally imply 10/100/1000, so i would expect dma_cap->mbps_1000 also
> > implies 10/100/1000? So why also set dma_cap->mbps_10_100?
Regarding DW XGMAC. I can't say for sure. Based on DW XGMAC v2.10
IP-core HW manual it has MAC_HW_Feature0.GMIISEL(1) flag indicating
whether there is GMII interface besides of the XGMII interface. But in
my databook MAC_HW_Feature0.BIT(0) is marked as reserved and
MAC_Tx_Configuration.SS field doesn't have 10/100Mbps modes despite of
what is defined in dwxgmac2.h by means of the XGMAC_CONFIG_SS_10_MII
and XGMAC_CONFIG_SS_1000_GMII macros.
But DW GMAC or DW Eth QoS can be synthesized with the 1000-only
mode enabled. GMIISEL and MIISEL flags reflect the OP_MODE IP-core
synthesize parameter state. It can have three different values:
Mode of Operation Description: Configures the MAC to work in
10/100/1000 Mbps mode. Select 10/100/1000
Mbps for enabling both Fast Ethernet and Gigabit
operations, 10/100 Mbps for Fast Ethernet-only
operations, and 1000 Mbps for Gigabit-only operations.
!!! Value Range: 10/100/1000 Mbps, 10/100 Mbps, or 1000 Mbps
Default Value:
10/100/1000 Mbps with Gigabit License
10/100 with Fast Ethernet license
HDL Parameter Name: OP_MODE
> >
> > Maybe a better change would be to modify:
> >
> > seq_printf(seq, "\t1000 Mbps: %s\n",
> > (priv->dma_cap.mbps_1000) ? "Y" : "N");
> >
> > to actually say 10/100/1000 Mbps? It does not appear this is used for
> > anything other than debugfs?
>
> Indeed, it also looks to me like mbps_1000 and mbps_10_100 are only
> used to print things in the debugfs file, and do not have any effect
> on the driver.
They should have been utilized somehow in the stmmac_mac_link_up() and
in the dwmac1000_setup(), dwmac4_setup(), etc methods in order to
select the proper speed. But yeah, currently they are used to print the
DebugFS node data only.
>
> Moreover:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h:#define GMAC_HW_FEAT_GMIISEL BIT(1)
> drivers/net/ethernet/stmicro/stmmac/common.h:#define DMA_HW_FEAT_GMIISEL 0x00000002 /* 1000 Mbps Support */
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h:#define XGMAC_HWFEAT_GMIISEL BIT(1)
>
> Seems to be all the same bit, and:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h:#define GMAC_HW_FEAT_MIISEL BIT(0)
> drivers/net/ethernet/stmicro/stmmac/common.h:#define DMA_HW_FEAT_MIISEL 0x00000001 /* 10/100 Mbps Support */
>
> So, if everyone defines the first few bits of the hw_cap identically,
> is there any point to decoding this separately in each driver? Couldn't
> the debugfs "show" function just parse the hw_cap directly?
The rest of the data in the HW-feature registers is almost completely
different. DW GMAC (common.h) has a single HW-Feature register which
has very little in common with the DW XGMAC (dwxgmac2.h) and DW Eth
QoS (dwmac4.h) MAC_HW_Feature0 register. The later two IP-cores have
the HW-feature registers looking very similar but still differing in
some flags. So in order not to have a partly measured change I would
suggest to preserve the separate HW-features macros space for each
type of the devices for now. If somebody cares to have them indicating
common and separate flags one could provide a comprehensive patch
fixing the entire HW-feature macros definitions. Although I don't see
this being that much necessary.
> Wouldn't it
> make more sense to print MII / GMII rather than 10/100 and 1000 ?
>
Based on the GMIISEL and MIISEL flags description they are
speed-related, not the interface type:
GMIISEL 1000 Mbps Support
MIISEL 10 or 100 Mbps support
> It does bring up one last question though: if the driver makes no use
> of these hw_cap bits, then is there any point in printing them in the
> debugfs file?
This question can be applied to almost the half of the dma_feature
structure fields.) One more patch extends it with even more mainly
unused fields:
https://lore.kernel.org/netdev/20230819105440.226892-1-0x1207@xxxxxxxxx/
-Serge(y)
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>