All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	DENG Qingfang <dqfext@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	erkin.bozoglu@xeront.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [RFC PATCH net-next] net: dsa: mt7530: fix port specifications for MT7988
Date: Thu, 6 Apr 2023 22:57:51 +0100	[thread overview]
Message-ID: <ZC9AXyuFqa3bqF3Q@makrotopia.org> (raw)
In-Reply-To: <e413a182-ce93-5831-09f5-19d34d7f7fcf@arinc9.com>

On Fri, Apr 07, 2023 at 12:43:41AM +0300, Arınç ÜNAL wrote:
> On 6.04.2023 14:07, Russell King (Oracle) wrote:
> > On Thu, Apr 06, 2023 at 01:04:45PM +0300, arinc9.unal@gmail.com wrote:
> > > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > 
> > > On the switch on the MT7988 SoC, there are only 4 PHYs. There's only port 6
> > > as the CPU port, there's no port 5. Split the switch statement with a check
> > > to enforce these for the switch on the MT7988 SoC. The internal phy-mode is
> > > specific to MT7988 so put it for MT7988 only.
> > > 
> > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > ---
> > > 
> > > Daniel, this is based on the information you provided me about the switch.
> > > I will add this to my current patch series if it looks good to you.
> > > 
> > > Arınç
> > > 
> > > ---
> > >   drivers/net/dsa/mt7530.c | 67 ++++++++++++++++++++++++++--------------
> > >   1 file changed, 43 insertions(+), 24 deletions(-)
> > > 
> > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> > > index 6fbbdcb5987f..f167fa135ef1 100644
> > > --- a/drivers/net/dsa/mt7530.c
> > > +++ b/drivers/net/dsa/mt7530.c
> > > @@ -2548,7 +2548,7 @@ static void mt7988_mac_port_get_caps(struct dsa_switch *ds, int port,
> > >   	phy_interface_zero(config->supported_interfaces);
> > >   	switch (port) {
> > > -	case 0 ... 4: /* Internal phy */
> > > +	case 0 ... 3: /* Internal phy */
> > >   		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
> > >   			  config->supported_interfaces);
> > >   		break;
> > > @@ -2710,37 +2710,56 @@ mt753x_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
> > >   	struct mt7530_priv *priv = ds->priv;
> > >   	u32 mcr_cur, mcr_new;
> > > -	switch (port) {
> > > -	case 0 ... 4: /* Internal phy */
> > > -		if (state->interface != PHY_INTERFACE_MODE_GMII &&
> > > -		    state->interface != PHY_INTERFACE_MODE_INTERNAL)
> > > -			goto unsupported;
> > > -		break;
> > > -	case 5: /* Port 5, a CPU port. */
> > > -		if (priv->p5_interface == state->interface)
> > > +	if (priv->id == ID_MT7988) {
> > > +		switch (port) {
> > > +		case 0 ... 3: /* Internal phy */
> > > +			if (state->interface != PHY_INTERFACE_MODE_INTERNAL)
> > 
> > How do these end up with PHY_INTERFACE_MODE_INTERNAL ? phylib defaults
> > to GMII mode without something else being specified in DT.
> > 
> > Also note that you should *not* be validating state->interface in the
> > mac_config() method because it's way too late to reject it - if you get
> > an unsupported interface here, then that is down to the get_caps()
> > method being buggy. Only report interfaces in get_caps() that you are
> > prepared to handle in the rest of the system.
> 
> This is already the case for all three get_caps(). The supported interfaces
> for each port are properly defined.
> 
> Though mt7988_mac_port_get_caps() clears the config->supported_interfaces
> bitmap before reporting the supported interfaces. I don't think this is
> needed as all bits in the bitmap should already be initialized to zero when
> the phylink_config structure is allocated.
> 
> I'm not sure if your suggestion is to make sure the supported interfaces are
> properly reported on get_caps(), or validate state->interface somewhere
> else.

I think what Russell meant is just there is no point in being overly
precise about permitted interface modes in mt753x_phylink_mac_config,
as this function is not meant and called too late to validate the
validity of the selected interface mode.

You change to mt7988_mac_port_get_caps looks correct to me and doing
this will already prevent mt753x_phylink_mac_config from ever being
called on MT7988 for port == 4 as well as and port == 5.


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	DENG Qingfang <dqfext@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	erkin.bozoglu@xeront.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [RFC PATCH net-next] net: dsa: mt7530: fix port specifications for MT7988
Date: Thu, 6 Apr 2023 22:57:51 +0100	[thread overview]
Message-ID: <ZC9AXyuFqa3bqF3Q@makrotopia.org> (raw)
In-Reply-To: <e413a182-ce93-5831-09f5-19d34d7f7fcf@arinc9.com>

On Fri, Apr 07, 2023 at 12:43:41AM +0300, Arınç ÜNAL wrote:
> On 6.04.2023 14:07, Russell King (Oracle) wrote:
> > On Thu, Apr 06, 2023 at 01:04:45PM +0300, arinc9.unal@gmail.com wrote:
> > > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > 
> > > On the switch on the MT7988 SoC, there are only 4 PHYs. There's only port 6
> > > as the CPU port, there's no port 5. Split the switch statement with a check
> > > to enforce these for the switch on the MT7988 SoC. The internal phy-mode is
> > > specific to MT7988 so put it for MT7988 only.
> > > 
> > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > ---
> > > 
> > > Daniel, this is based on the information you provided me about the switch.
> > > I will add this to my current patch series if it looks good to you.
> > > 
> > > Arınç
> > > 
> > > ---
> > >   drivers/net/dsa/mt7530.c | 67 ++++++++++++++++++++++++++--------------
> > >   1 file changed, 43 insertions(+), 24 deletions(-)
> > > 
> > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> > > index 6fbbdcb5987f..f167fa135ef1 100644
> > > --- a/drivers/net/dsa/mt7530.c
> > > +++ b/drivers/net/dsa/mt7530.c
> > > @@ -2548,7 +2548,7 @@ static void mt7988_mac_port_get_caps(struct dsa_switch *ds, int port,
> > >   	phy_interface_zero(config->supported_interfaces);
> > >   	switch (port) {
> > > -	case 0 ... 4: /* Internal phy */
> > > +	case 0 ... 3: /* Internal phy */
> > >   		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
> > >   			  config->supported_interfaces);
> > >   		break;
> > > @@ -2710,37 +2710,56 @@ mt753x_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
> > >   	struct mt7530_priv *priv = ds->priv;
> > >   	u32 mcr_cur, mcr_new;
> > > -	switch (port) {
> > > -	case 0 ... 4: /* Internal phy */
> > > -		if (state->interface != PHY_INTERFACE_MODE_GMII &&
> > > -		    state->interface != PHY_INTERFACE_MODE_INTERNAL)
> > > -			goto unsupported;
> > > -		break;
> > > -	case 5: /* Port 5, a CPU port. */
> > > -		if (priv->p5_interface == state->interface)
> > > +	if (priv->id == ID_MT7988) {
> > > +		switch (port) {
> > > +		case 0 ... 3: /* Internal phy */
> > > +			if (state->interface != PHY_INTERFACE_MODE_INTERNAL)
> > 
> > How do these end up with PHY_INTERFACE_MODE_INTERNAL ? phylib defaults
> > to GMII mode without something else being specified in DT.
> > 
> > Also note that you should *not* be validating state->interface in the
> > mac_config() method because it's way too late to reject it - if you get
> > an unsupported interface here, then that is down to the get_caps()
> > method being buggy. Only report interfaces in get_caps() that you are
> > prepared to handle in the rest of the system.
> 
> This is already the case for all three get_caps(). The supported interfaces
> for each port are properly defined.
> 
> Though mt7988_mac_port_get_caps() clears the config->supported_interfaces
> bitmap before reporting the supported interfaces. I don't think this is
> needed as all bits in the bitmap should already be initialized to zero when
> the phylink_config structure is allocated.
> 
> I'm not sure if your suggestion is to make sure the supported interfaces are
> properly reported on get_caps(), or validate state->interface somewhere
> else.

I think what Russell meant is just there is no point in being overly
precise about permitted interface modes in mt753x_phylink_mac_config,
as this function is not meant and called too late to validate the
validity of the selected interface mode.

You change to mt7988_mac_port_get_caps looks correct to me and doing
this will already prevent mt753x_phylink_mac_config from ever being
called on MT7988 for port == 4 as well as and port == 5.

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

  reply	other threads:[~2023-04-06 21:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 10:04 [RFC PATCH net-next] net: dsa: mt7530: fix port specifications for MT7988 arinc9.unal
2023-04-06 10:04 ` arinc9.unal
2023-04-06 10:24 ` Arınç ÜNAL
2023-04-06 10:24   ` Arınç ÜNAL
2023-04-06 11:07 ` Russell King (Oracle)
2023-04-06 11:07   ` Russell King (Oracle)
2023-04-06 13:13   ` Daniel Golle
2023-04-06 13:13     ` Daniel Golle
2023-04-06 21:43   ` Arınç ÜNAL
2023-04-06 21:43     ` Arınç ÜNAL
2023-04-06 21:57     ` Daniel Golle [this message]
2023-04-06 21:57       ` Daniel Golle
2023-04-07  8:56       ` Arınç ÜNAL
2023-04-07  8:56         ` Arınç ÜNAL
2023-04-07  9:28         ` Daniel Golle
2023-04-07  9:28           ` Daniel Golle
2023-04-07 10:46           ` Arınç ÜNAL
2023-04-07 10:46             ` Arınç ÜNAL
2023-04-07 10:50             ` Arınç ÜNAL
2023-04-07 10:50               ` Arınç ÜNAL
2023-04-07 11:04               ` Daniel Golle
2023-04-07 11:04                 ` Daniel Golle
2023-04-07 11:03             ` Daniel Golle
2023-04-07 11:03               ` Daniel Golle

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=ZC9AXyuFqa3bqF3Q@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=Landen.Chao@mediatek.com \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=erkin.bozoglu@xeront.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.com \
    /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.