All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jisheng Zhang <jszhang@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v4 2/9] net: stmmac: xgmac: add more feature parsing from hw cap
Date: Sun, 20 Aug 2023 20:51:41 +0100	[thread overview]
Message-ID: <ZOJuzakni1youMtX@shell.armlinux.org.uk> (raw)
In-Reply-To: <9e55fd03-6b05-46de-874e-01d9cdbf4524@lunn.ch>

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?
> 
> 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.

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? Wouldn't it
make more sense to print MII / GMII rather than 10/100 and 1000 ?

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?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jisheng Zhang <jszhang@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v4 2/9] net: stmmac: xgmac: add more feature parsing from hw cap
Date: Sun, 20 Aug 2023 20:51:41 +0100	[thread overview]
Message-ID: <ZOJuzakni1youMtX@shell.armlinux.org.uk> (raw)
In-Reply-To: <9e55fd03-6b05-46de-874e-01d9cdbf4524@lunn.ch>

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?
> 
> 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.

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? Wouldn't it
make more sense to print MII / GMII rather than 10/100 and 1000 ?

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?

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

  reply	other threads:[~2023-08-20 19:54 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16 15:29 [PATCH net-next v4 0/9] net: stmmac: add new features to xgmac Jisheng Zhang
2023-08-16 15:29 ` Jisheng Zhang
2023-08-16 15:29 ` [PATCH net-next v4 1/9] net: stmmac: correct RX COE parsing for xgmac Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-16 15:29 ` [PATCH net-next v4 2/9] net: stmmac: xgmac: add more feature parsing from hw cap Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-20 19:15   ` Andrew Lunn
2023-08-20 19:15     ` Andrew Lunn
2023-08-20 19:51     ` Russell King (Oracle) [this message]
2023-08-20 19:51       ` Russell King (Oracle)
2023-08-21 13:25       ` Serge Semin
2023-08-21 13:25         ` Serge Semin
2023-08-21 13:57         ` Russell King (Oracle)
2023-08-21 13:57           ` Russell King (Oracle)
2023-08-21 14:41           ` Serge Semin
2023-08-21 14:41             ` Serge Semin
2023-08-16 15:29 ` [PATCH net-next v4 3/9] net: stmmac: enlarge max rx/tx queues and channels to 16 Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-20 19:19   ` Andrew Lunn
2023-08-20 19:19     ` Andrew Lunn
2023-08-16 15:29 ` [PATCH net-next v4 4/9] net: stmmac: reflect multi irqs for tx/rx channels and mac and safety Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-16 15:29 ` [PATCH net-next v4 5/9] net: stmmac: xgmac: support per-channel irq Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-16 15:29 ` [PATCH net-next v4 6/9] dt-bindings: net: snps,dwmac: add safety irq support Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-17 15:37   ` Rob Herring
2023-08-17 15:37     ` Rob Herring
2023-08-16 15:29 ` [PATCH net-next v4 7/9] net: stmmac: platform: support parsing safety irqs from DT Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-20 19:28   ` Andrew Lunn
2023-08-20 19:28     ` Andrew Lunn
2023-08-16 15:29 ` [PATCH net-next v4 8/9] dt-bindings: net: snps,dwmac: add per channel irq support Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-16 15:29 ` [PATCH net-next v4 9/9] net: stmmac: platform: support parsing per channel irq from DT Jisheng Zhang
2023-08-16 15:29   ` Jisheng Zhang
2023-08-20 19:29   ` Andrew Lunn
2023-08-20 19:29     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZOJuzakni1youMtX@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=jszhang@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peppe.cavallaro@st.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.