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

[Bo Gan <ganboing@gmail.com>]

Hi Andrew,

On 1/23/26 11:43, Andrew Lunn wrote:
> 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.

My reading of
https://lore.kernel.org/all/308b676.2d03.19bb0caebed.Coremail.lizhi2@eswincomputing.com/
is that the eth1 MAC is already breaking the standard at SoC level, and
the boards can un-break it or break it even more. Hence, even for proper
designed board, SoC .dtsi still needs eswin,rx-clk-invert (for *eth1*).
For broken boards, they may require eswin,rx-clk-invert for *eth0*, even
though SoC doesn't mandate. For *eth1* broken boards might have to
/delete-property/ it and use eswin,tx-clk-invert or something else.
It's clearer to have all these parameters visible and explicit in DT.

ESWIN, please correct me if I'm wrong.

P.S. I'm not affiliated to ESWIN, but I do own eic7700/hifive-premier
board, and I can talk to someone who owns eic7700/megrez. I can help
validating ESWIN's patches independently.

> 
>         Andrew
> 
Bo