From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: Daniel Golle <daniel@makrotopia.org>,
DENG Qingfang <dqfext@gmail.com>,
Sean Wang <sean.wang@mediatek.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>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
Bartel Eerdekens <bartel.eerdekens@constell8.be>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next v3 4/7] net: dsa: mt7530: move XTAL check to mt7530_setup()
Date: Sun, 4 Feb 2024 14:18:28 +0000 [thread overview]
Message-ID: <Zb+ctEe9TVA3zhv8@shell.armlinux.org.uk> (raw)
In-Reply-To: <f6234b46-ce30-4b2a-9681-15633a06feff@arinc9.com>
On Sun, Feb 04, 2024 at 04:55:40PM +0300, Arınç ÜNAL wrote:
> On 2.02.2024 21:39, Daniel Golle wrote:
> > On Fri, Feb 02, 2024 at 09:16:02PM +0300, Arınç ÜNAL wrote:
> > > On 2.02.2024 14:48, Russell King (Oracle) wrote:
> > > > On Fri, Feb 02, 2024 at 12:19:10PM +0300, Arınç ÜNAL via B4 Relay wrote:
> > > > > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > > >
> > > > > The crystal frequency concerns the switch core. The frequency should be
> > > > > checked when the switch is being set up so the driver can reject the
> > > > > unsupported hardware earlier and without requiring port 6 to be used.
> > > > >
> > > > > Move it to mt7530_setup(). Drop the unnecessary function printing.
> > > > >
> > > > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > > > > Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> > > >
> > > > I would prefer this to be earlier in the series, before patch 2 which
> > > > moves mt7530_setup_port6() to be called from mac_config(). mac_config()
> > > > is supposed to be configuration error-free - in other words, all state
> > > > should have been checked before hand.
> > >
> > > I agree but mt7530_mac_config() is not a void function yet. The
> > > mac_port_config member of the mt753x_info structure points to this
> > > function. My next patch series gets rid of all useless error returns on the
> > > phylink path and change mac_port_config to void. So I don't think working
> > > on this patch series further will worth the effort. I'd rather have this
> > > version applied as is.
> >
> > I agree regarding not changing the patch itself, but I also agree
> > with Russell regarding the patch ordering. I know it's a 10-minute
> > git headache to rebase the patches on top of each other in a different
> > order, but you can easily compare the end result being identical to
> > what you had before and hence don't need to retest.
>
> This is not about laziness. This is before patch 2:
>
> phylink_mac_ops :: mac_config() -> dsa_port_phylink_mac_config()
> -> dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config()
> -> mt753x_mac_config()
> -> mt753x_info :: mac_port_config() -> mt7530_mac_config()
> -> mt7530_setup_port5()
> -> mt753x_pad_setup()
> -> mt753x_info :: pad_setup() -> mt7530_pad_clk_setup()
>
> This is after:
>
> phylink_mac_ops :: mac_config() -> dsa_port_phylink_mac_config()
> -> dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config()
> -> mt753x_mac_config()
> -> mt753x_info :: mac_port_config() -> mt7530_mac_config()
> -> mt7530_setup_port5()
> -> mt7530_setup_port6()
>
> Patch 2 does not move mt7530_setup_port6() to be called from
> phylink_mac_ops :: mac_config(), it already is. There is no valid reason to
> reorder the patches.
>
> My response to Russell should've stated this instead of focusing on his
> second sentence.
This patch moves the test for a 20MHz crystal to mt7530_setup(),
which is something that is entirely orthogonal to patch 2, which
can be done cleanly (I've just applied the patches in the original
order and then reordered them:
98c481f5d706 net: dsa: mt7530: do not clear config->supported_interfaces
93c6b53b17f4 net: dsa: mt7530: correct port capabilities of MT7988
c9c6d4c51a1d net: dsa: mt7530: simplify mt7530_setup_port6() and change to void
adfa948253e0 net: dsa: mt7530: remove pad_setup function pointer
57e21e6c2fc0 net: dsa: mt7530: call port 6 setup from mt7530_mac_config()
959a0f9323c8 net: dsa: mt7530: move XTAL check to mt7530_setup()
856ab64a22ef net: dsa: mt7530: empty default case on mt7530_setup_port5()
No problems. The end result is identical comparing the git tree at the
original "move XTAL" patch with adfa948253e0.
Now, if we look at "net: dsa: mt7530: remove pad_setup function pointer"
we can see that yes, the pad_setup() method was called from mac_confing,
but this is the exact contents of that patch removing the callsite:
- mt753x_pad_setup(ds, state);
This returns an integer, which may be an error code, which is ignored.
Therefore, if the XTAL frequency check fires, and mt753x_pad_setup()
returns an error, it is ignored today.
After "net: dsa: mt7530: call port 6 setup from mt7530_mac_config()"
the renamed pad_setup() method is now called from mac_config() thusly:
+ ret = mt7530_setup_port6(priv->ds, interface);
+ if (ret)
+ return ret;
So now the error checks cause mt7530_mac_config() to return an error
which in turn causes mt753x_mac_config() to fail, and therefore
mt753x_phylink_mac_config() has different behaviour.
So, patch 2 changes the driver behaviour in the case of a 20MHz XTAL,
which is then changed again by patch 4.
It would be better to have only one change of behaviour by moving
patch 4 before patch 2.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Arınç ÜNAL" <arinc.unal@arinc9.com>
Cc: Daniel Golle <daniel@makrotopia.org>,
DENG Qingfang <dqfext@gmail.com>,
Sean Wang <sean.wang@mediatek.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>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
Bartel Eerdekens <bartel.eerdekens@constell8.be>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next v3 4/7] net: dsa: mt7530: move XTAL check to mt7530_setup()
Date: Sun, 4 Feb 2024 14:18:28 +0000 [thread overview]
Message-ID: <Zb+ctEe9TVA3zhv8@shell.armlinux.org.uk> (raw)
In-Reply-To: <f6234b46-ce30-4b2a-9681-15633a06feff@arinc9.com>
On Sun, Feb 04, 2024 at 04:55:40PM +0300, Arınç ÜNAL wrote:
> On 2.02.2024 21:39, Daniel Golle wrote:
> > On Fri, Feb 02, 2024 at 09:16:02PM +0300, Arınç ÜNAL wrote:
> > > On 2.02.2024 14:48, Russell King (Oracle) wrote:
> > > > On Fri, Feb 02, 2024 at 12:19:10PM +0300, Arınç ÜNAL via B4 Relay wrote:
> > > > > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > > >
> > > > > The crystal frequency concerns the switch core. The frequency should be
> > > > > checked when the switch is being set up so the driver can reject the
> > > > > unsupported hardware earlier and without requiring port 6 to be used.
> > > > >
> > > > > Move it to mt7530_setup(). Drop the unnecessary function printing.
> > > > >
> > > > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > > > > Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> > > >
> > > > I would prefer this to be earlier in the series, before patch 2 which
> > > > moves mt7530_setup_port6() to be called from mac_config(). mac_config()
> > > > is supposed to be configuration error-free - in other words, all state
> > > > should have been checked before hand.
> > >
> > > I agree but mt7530_mac_config() is not a void function yet. The
> > > mac_port_config member of the mt753x_info structure points to this
> > > function. My next patch series gets rid of all useless error returns on the
> > > phylink path and change mac_port_config to void. So I don't think working
> > > on this patch series further will worth the effort. I'd rather have this
> > > version applied as is.
> >
> > I agree regarding not changing the patch itself, but I also agree
> > with Russell regarding the patch ordering. I know it's a 10-minute
> > git headache to rebase the patches on top of each other in a different
> > order, but you can easily compare the end result being identical to
> > what you had before and hence don't need to retest.
>
> This is not about laziness. This is before patch 2:
>
> phylink_mac_ops :: mac_config() -> dsa_port_phylink_mac_config()
> -> dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config()
> -> mt753x_mac_config()
> -> mt753x_info :: mac_port_config() -> mt7530_mac_config()
> -> mt7530_setup_port5()
> -> mt753x_pad_setup()
> -> mt753x_info :: pad_setup() -> mt7530_pad_clk_setup()
>
> This is after:
>
> phylink_mac_ops :: mac_config() -> dsa_port_phylink_mac_config()
> -> dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config()
> -> mt753x_mac_config()
> -> mt753x_info :: mac_port_config() -> mt7530_mac_config()
> -> mt7530_setup_port5()
> -> mt7530_setup_port6()
>
> Patch 2 does not move mt7530_setup_port6() to be called from
> phylink_mac_ops :: mac_config(), it already is. There is no valid reason to
> reorder the patches.
>
> My response to Russell should've stated this instead of focusing on his
> second sentence.
This patch moves the test for a 20MHz crystal to mt7530_setup(),
which is something that is entirely orthogonal to patch 2, which
can be done cleanly (I've just applied the patches in the original
order and then reordered them:
98c481f5d706 net: dsa: mt7530: do not clear config->supported_interfaces
93c6b53b17f4 net: dsa: mt7530: correct port capabilities of MT7988
c9c6d4c51a1d net: dsa: mt7530: simplify mt7530_setup_port6() and change to void
adfa948253e0 net: dsa: mt7530: remove pad_setup function pointer
57e21e6c2fc0 net: dsa: mt7530: call port 6 setup from mt7530_mac_config()
959a0f9323c8 net: dsa: mt7530: move XTAL check to mt7530_setup()
856ab64a22ef net: dsa: mt7530: empty default case on mt7530_setup_port5()
No problems. The end result is identical comparing the git tree at the
original "move XTAL" patch with adfa948253e0.
Now, if we look at "net: dsa: mt7530: remove pad_setup function pointer"
we can see that yes, the pad_setup() method was called from mac_confing,
but this is the exact contents of that patch removing the callsite:
- mt753x_pad_setup(ds, state);
This returns an integer, which may be an error code, which is ignored.
Therefore, if the XTAL frequency check fires, and mt753x_pad_setup()
returns an error, it is ignored today.
After "net: dsa: mt7530: call port 6 setup from mt7530_mac_config()"
the renamed pad_setup() method is now called from mac_config() thusly:
+ ret = mt7530_setup_port6(priv->ds, interface);
+ if (ret)
+ return ret;
So now the error checks cause mt7530_mac_config() to return an error
which in turn causes mt753x_mac_config() to fail, and therefore
mt753x_phylink_mac_config() has different behaviour.
So, patch 2 changes the driver behaviour in the case of a 20MHz XTAL,
which is then changed again by patch 4.
It would be better to have only one change of behaviour by moving
patch 4 before patch 2.
--
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
next prev parent reply other threads:[~2024-02-04 14:18 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 9:19 [PATCH net-next v3 0/7] MT7530 DSA Subdriver Improvements Act II Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` [PATCH net-next v3 1/7] net: dsa: mt7530: empty default case on mt7530_setup_port5() Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:40 ` Russell King (Oracle)
2024-02-02 11:40 ` Russell King (Oracle)
2024-02-02 17:44 ` Arınç ÜNAL
2024-02-02 17:44 ` Arınç ÜNAL
2024-02-02 18:05 ` Russell King (Oracle)
2024-02-02 18:05 ` Russell King (Oracle)
2024-02-02 20:25 ` Andrew Lunn
2024-02-02 20:25 ` Andrew Lunn
2024-02-05 20:29 ` Vladimir Oltean
2024-02-05 20:29 ` Vladimir Oltean
2024-02-02 9:19 ` [PATCH net-next v3 2/7] net: dsa: mt7530: call port 6 setup from mt7530_mac_config() Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:45 ` Russell King (Oracle)
2024-02-02 11:45 ` Russell King (Oracle)
2024-02-02 9:19 ` [PATCH net-next v3 3/7] net: dsa: mt7530: remove pad_setup function pointer Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:46 ` Russell King (Oracle)
2024-02-02 11:46 ` Russell King (Oracle)
2024-02-02 9:19 ` [PATCH net-next v3 4/7] net: dsa: mt7530: move XTAL check to mt7530_setup() Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:48 ` Russell King (Oracle)
2024-02-02 11:48 ` Russell King (Oracle)
2024-02-02 18:16 ` Arınç ÜNAL
2024-02-02 18:16 ` Arınç ÜNAL
2024-02-02 18:39 ` Daniel Golle
2024-02-02 18:39 ` Daniel Golle
2024-02-04 13:55 ` Arınç ÜNAL
2024-02-04 13:55 ` Arınç ÜNAL
2024-02-04 14:18 ` Russell King (Oracle) [this message]
2024-02-04 14:18 ` Russell King (Oracle)
2024-02-04 15:55 ` Arınç ÜNAL
2024-02-04 15:55 ` Arınç ÜNAL
2024-02-04 16:38 ` Russell King (Oracle)
2024-02-04 16:38 ` Russell King (Oracle)
2024-02-04 16:51 ` Arınç ÜNAL
2024-02-04 16:51 ` Arınç ÜNAL
2024-02-04 17:07 ` Russell King (Oracle)
2024-02-04 17:07 ` Russell King (Oracle)
2024-02-04 17:14 ` Arınç ÜNAL
2024-02-04 17:14 ` Arınç ÜNAL
2024-02-02 9:19 ` [PATCH net-next v3 5/7] net: dsa: mt7530: simplify mt7530_setup_port6() and change to void Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:51 ` Russell King (Oracle)
2024-02-02 11:51 ` Russell King (Oracle)
2024-02-02 9:19 ` [PATCH net-next v3 6/7] net: dsa: mt7530: correct port capabilities of MT7988 Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` [PATCH net-next v3 7/7] net: dsa: mt7530: do not clear config->supported_interfaces Arınç ÜNAL
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 9:19 ` Arınç ÜNAL via B4 Relay
2024-02-02 11:52 ` Russell King (Oracle)
2024-02-02 11:52 ` Russell King (Oracle)
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=Zb+ctEe9TVA3zhv8@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arinc.unal@arinc9.com \
--cc=bartel.eerdekens@constell8.be \
--cc=daniel@makrotopia.org \
--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=matthias.bgg@gmail.com \
--cc=mithat.guner@xeront.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.