lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <dmfhl4ptoytmconczdkccli5qlkct33tgfqaoigygrzak52g63@qw7pwoa5m2x3> Date: Mon, 21 Aug 2023 16:25:42 +0300 From: Serge Semin <fancer.lancer@...il.com> To: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn <andrew@...n.ch> Cc: Jisheng Zhang <jszhang@...nel.org>, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Giuseppe Cavallaro <peppe.cavallaro@...com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH net-next v4 2/9] net: stmmac: xgmac: add more feature parsing from hw cap 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@gmail.com/ -Serge(y) > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! >
Powered by blists - more mailing lists