[RFC PATCH v2 net-next 02/14] net: dsa: mt7530: fix phylink for port 5 and fix port 5 modes

Vladimir Oltean olteanv at gmail.com
Tue Apr 11 08:00:56 PDT 2023


On Fri, Apr 07, 2023 at 04:46:14PM +0300, arinc9.unal at gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal at arinc9.com>
> 
> There're two code paths for setting up port 5:
> 
> mt7530_setup()
> -> mt7530_setup_port5()
> 
> mt753x_phylink_mac_config()
> -> mt753x_mac_config()
>    -> mt7530_mac_config()
>       -> mt7530_setup_port5()
> 
> The first code path is supposed to run when PHY muxing is being used. In
> this case, port 5 is somewhat of a hidden port. It won't be defined on the
> devicetree so phylink can't be used to manage the port.
> 
> The second code path used to call mt7530_setup_port5() directly under case
> 5 on mt7530_phylink_mac_config() before it was moved to mt7530_mac_config()
> with 88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a
> new hardware"). mt7530_setup_port5() will never run through this code path
> because the current code on mt7530_setup() bypasses phylink for all cases
> of port 5.
> 
> Fix this by leaving it to phylink if port 5 is used as a CPU, DSA, or user
> port. For the cases of PHY muxing or the port being disabled, call
> mt7530_setup_port5() directly from mt7530_setup() without involving
> phylink.
> 
> Move setting the interface and P5_DISABLED mode to a more specific
> location. They're supposed to be overwritten if PHY muxing is detected.
> 
> Add comments which explain the process.
> 
> Tested-by: Arınç ÜNAL <arinc.unal at arinc9.com>
> Signed-off-by: Arınç ÜNAL <arinc.unal at arinc9.com>
> ---

We have a natural language processing engine (AUTOSEL) which
automatically picks up as candidates for "stable" those patches which
weren't explicitly submitted through the proper process for that (and
they contain words like "fix", "bug", "crash", "leak" etc).

Your chosen wording, both in the commit title and message, would most
likely trigger that bot, and then you'd have to explain why you chose
this language and not something else more descriptive of your change.
It would be nice if you could rewrite the commit messages for your
entire series to be a bit more succint as to what is the purpose of the
change you are making, and don't use the word "fix" when there is no
problem to be observed.



More information about the Linux-mediatek mailing list