> -----Ursprüngliche Nachricht----- > Von: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > Gesendet: Dienstag, 8. Oktober 2024 10:32 > An: markus.stockhausen@xxxxxx; linux-phy@xxxxxxxxxxxxxxxxxxx; chris.packham@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx > 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@xxxxxx 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
