Re: [RFC PATCH v11 08/12] net: ethernet: mtk_eth_soc: fix RX data corruption issue

[Vladimir Oltean]

On Thu, Mar 02, 2023 at 11:56:56AM +0000, Daniel Golle wrote:
> The issues affects PHYs (and potentially switch PHY ICs) connected via
> SGMII operating at 1.25Mbaud.
> 
> The only officially supported board affected by this is the BPi-R3 where
> it affects the SFP cages -- the on-board MT7531 switch which is also
> used on all other boards using these SoCs is connected with 2500Base-X.
> 
> The issue does **not** affect RGMII or GMII on the MT7623 SoC, but I
> don't have any way to try RGMII or GMII on more recent SoCs as I lack
> hardware making use of that to connect a PHY.

I don't believe that board vendors need to have their device tree
"officially supported" in Linux in order to claim that a bug affecting
them should be fixed on stable kernels. As long as the PHY interface
type is generally supported by the driver and is expected to work,
it should work with any board (the exception being if there are other
configuration steps specific to that board required).

In any case, a good commit message for a bug fix explains what is the
user impact of the bug being fixed, the configurations which are affected,
how it was noticed, an adequate Fixes: tag, and if necessary, why it is
being fixed the way it is. In other words, it must be able to respond to
normal questions that a reader might have when he/she stumbles upon it,
for various reasons (it introduces a regression, they are debugging an
issue and want to assess whether backporting this patch would help them,
etc). The reader might be in the not so close future, when you might not
be able to provide clarifications personally, so the commit message
should contain all that you know which is relevant to the topic.

Most of these clarifications were provided by you as replies to the
patch, but they should be present in the commit message instead.