Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Jan 23, 2026 at 02:47:18AM -0800, Bo Gan wrote:
> Hi Krzysztof,
> 
> On 1/23/26 02:07, Krzysztof Kozlowski wrote:
> > On 23/01/2026 08:39, Bo Gan wrote:
> > > > I assume the address of the interface is fixed. So you can just key
> > > > off that to distinguish the two instances.
> > > > 
> > > > Since this is an internal property, not a board property, it is not
> > > > clear it actually belongs on DT.
> > > > 
> > > >       Andrew
> > > 
> > > IMO, they should be in DT to provide maximum flexibility. The SoC .dtsi
> > 
> > This is not the purpose of DT. Please rather use arguments in terms of
> > DT rules (see docs, presentations).
> > 
> Any examples? links? Thank you for your patience.
> 
> I'd say if the board .dts never overrides the eswin,rx-clk-invert, (E.g.,
> the SoC .dtsi has rx-clk-invert, later the board /delete-property/'s it)
> then yes, it can be treated as something inherent to the mac, and then
> "use arguments in terms of DT rules". I was thinking about use cases like:
> https://lore.kernel.org/all/20230714104521.18751-3-samin.guo@starfivetech.com/

Your device should be compliant with the RGMII standard by
default. There should not be a DT property to ask it nicely to follow
the standard.

Properties like

motorcomm,tx-clk-adj-enabled;
motorcomm,tx-clk-100-inverted;
motorcomm,tx-clk-1000-inverted;

are for broken boards which break the standard and require the MAC do
also break the standard so that everything works. We should not start
out with the assumption you need to support broken boards which ignore
the standard.

       Andrew