AW: AW: AW: [PATCH v2 1/3] dt-bindings: phy: add realtek,otto-serdes PHY binding
markus.stockhausen at gmx.de
markus.stockhausen at gmx.de
Tue Oct 8 02:27:15 PDT 2024
> -----Ursprüngliche Nachricht-----
> Von: Krzysztof Kozlowski <krzk at kernel.org>
> Gesendet: Dienstag, 8. Oktober 2024 10:32
> An: markus.stockhausen at gmx.de; linux-phy at lists.infradead.org; chris.packham at alliedtelesis.co.nz; devicetree at vger.kernel.org
> Betreff: Re: AW: AW: [PATCH v2 1/3] dt-bindings: phy: add realtek,otto-serdes PHY binding
>
> On 08/10/2024 08:56, markus.stockhausen at gmx.de wrote:
> >>
> >>> E.g. st,invert-ext. Something like this will be needed in the future
> >>> because the SerDes allow to swap polarity which must be changed
> >>> depending on the switch design. How to do this?
> >>
> >> I do not understand the hardware aspect discussed in the property description... probably because there is no hardware description at all, but instead you speak about driver.
> >>
> >> I do not understand how polarity has anything to do with U-Boot configuring serdes.
> >
> > Maybe my lack of knowledge in platform driver programming or the
> > naming conventions leads to confusion. I'm searching for knobs to
> > control the behaviour of the SerDes depending on the hardware. Two examples are (more may come):
> >
> > - "ignore SerDes X": because the provided patch sequence confuses the
> > SerDes and overwrites registers with wrong values that vendor patched
> > U-Boot has setup correctly before.
>
> And if someone updates the bootloader to a bit different one, the DTS
> becomes wrong? How do you handle then same board with two different
> bootloaders requiring two different DTS? DTS is software-independent
> description of the hardware, so this does not look like DTS property.
Good point. So the initial idea to provide dynamic patch sequences was
the right direction but storing in devicetree is wrong. Like Chris mentioned
I would change the code to make use of a dynamically loaded firmware file.
- if exist: run sequences from there
- if not exist: keep registers as is.
Reasonable idea?
Best regards.
Markus
More information about the linux-phy
mailing list