[PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id

Steve Twiss stwiss.opensource at diasemi.com
Fri Mar 22 03:50:56 PDT 2019


Here are my thoughts. 

On 22 March 2019 10:21, Michal Vokáč wrote:

> Subject: Re: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
> 
> On 22. 03. 19 3:24, Fabio Estevam wrote:
> > On Thu, Mar 21, 2019 at 11:15 PM Shawn Guo <shawnguo at kernel.org> wrote:
> >
> >>> Unfortunately, just by looking at the dts files we do not know if a
> >>> board uses an AR803x PHY or not, so I am afraid we can not do an
> >>> automatic conversion.
> >>
> >> At least for those we already know?
> >
> > Yes, I can help preparing a patch that fixes the i.MX boards we know
> > use AR8031 PHY.
> 
> AFACT this issue is not AR803x specific. I was hit by the same problem
> with QCA833x switch on imx6dl-yapp4. Though, we are currently the only
> platform in tree using this chip and Shawn already has the fix in his tree.
> 
> I am not aware of any other PHY drivers that my cause problems.
> 
> $ git log --oneline v5.0..v5.1-rc1 --grep=RGMII --author=Vinod -- drivers/net/
> 6d4cd041f0af net: phy: at803x: disable delay only for RGMII mode
> a968b5e9d587 net: dsa: qca8k: Enable delay for RGMII_ID mode
> 5ecdd77c61c8 net: dsa: qca8k: disable delay for RGMII mode
> cd28d1d6e52e net: phy: at803x: Disable phy delay for RGMII mode

If this is more widespread, as Michal points out, this might affect the way
the fix is approach then?

On 21 March 2019 12:43 Lucas Stach wrote:

> > So yes, we currently have lots of broken dtb's in mainline and I am
> > wondering what is the proper fix here.
[...]
> but if the DT is clearly broken and fixing it in a backward
> compatible way is not really feasible, I would argue that we should
> treat a DT bug like any other bug.

There is a way of doing this to preserve backwards compatibility I think.
Maybe deprecating the previous DTS phy-mode and replacing it with a new one,
phy-mode-v2 instead?

At the moment, there is only a weak link between DTS and the driver in the kernel
which  makes finding the error difficult. Also, it seems that partly, the direction of
change is caused by software which is pushing alterations in the DTS -- and not the
other way round.

Regards,
Steve


More information about the linux-arm-kernel mailing list