Re: Re: [PATCH net-next v3 1/3] dt-bindings: ethernet: eswin: add clock sampling control

[Conor Dooley]

On Thu, Mar 05, 2026 at 10:52:38AM +0800, 李志 wrote:
> 
> 
> 
> > -----原始邮件-----
> > 发件人: "Conor Dooley" <conor@xxxxxxxxxx>
> > 发送时间:2026-03-04 17:30:57 (星期三)
> > 收件人: "Bo Gan" <ganboing@xxxxxxxxx>
> > 抄送: "Jakub Kicinski" <kuba@xxxxxxxxxx>, lizhi2@xxxxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, andrew+netdev@xxxxxxx, davem@xxxxxxxxxxxxx, edumazet@xxxxxxxxxx, robh@xxxxxxxxxx, krzk+dt@xxxxxxxxxx, conor+dt@xxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, pabeni@xxxxxxxxxx, mcoquelin.stm32@xxxxxxxxx, alexandre.torgue@xxxxxxxxxxx, rmk+kernel@xxxxxxxxxxxxxxx, wens@xxxxxxxxxx, pjw@xxxxxxxxxx, palmer@xxxxxxxxxxx, aou@xxxxxxxxxxxxxxxxx, alex@xxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, ningyu@xxxxxxxxxxxxxxxxxx, linmin@xxxxxxxxxxxxxxxxxx, pinkesh.vaghela@xxxxxxxxxxxxxx, pritesh.patel@xxxxxxxxxxxxxx, weishangjuan@xxxxxxxxxxxxxxxxxx
> > 主题: Re: [PATCH net-next v3 1/3] dt-bindings: ethernet: eswin: add clock sampling control
> > 
> > On Tue, Mar 03, 2026 at 05:23:18PM -0800, Bo Gan wrote:
> > > Hi All,
> > > 
> > > On 3/3/26 16:47, Conor Dooley wrote:
> > > > On Tue, Mar 03, 2026 at 04:38:46PM -0800, Jakub Kicinski wrote:
> > > > > On Tue,  3 Mar 2026 14:16:37 +0800 lizhi2@xxxxxxxxxxxxxxxxxx wrote:
> > > > > > There are currently no in-tree users of the EIC7700 Ethernet driver, so
> > > > > > these changes are safe.
> > > > > 
> > > > > What do you mean by this sentence? The commit under Fixes was part of
> > > > > Linux v6.19 already.
> > > > 
> > > > The "funny" thing is that caring about users doesn't even really matter
> > > > on the devicetree patch, except for this hunk:
> > > > |@@ -81,7 +99,9 @@ properties:
> > > > |                          or external clock selection
> > > > |           - description: Offset of AXI clock controller Low-Power request
> > > > |                          register
> > > > |+          - description: Offset of register controlling TXD delay
> > > > |           - description: Offset of register controlling TX/RX clock delay
> > > > |+          - description: Offset of register controlling RXD delay
> > > > |
> > > > | required:
> > > > |   - compatible
> > > > And it only matters here because an item is injected mid-list. If this
> > > > was moved to the end with the RXD delay, the **dt-binding** changes
> > > > don't have issues with safety. I've not looked at whether there are
> > > > knock-on concerns about users in the driver or whatever yet, but from a
> > > > binding POV only that hunk can break something that currently works.
> > > 
> > > This was already discussed here in v1:
> > > https://lore.kernel.org/lkml/e7183ae1-8b8b-4e77-9f4e-3bc1b4b63556@xxxxxxx/
> > > 
> > > The device-tree is not checked in yet by ESWIN folks, so there's currently
> > > no user of the dt-binding. No need to worry about backward compat.
> > 
> > The binding and driver exist, there doesn't need to be a dts in tree for
> > there to be potential users. If the break was important I might not
> > care, but this seems to be a gratuitous break, since the new items could
> > be added to the end of the list and compatibility maintained without
> > incurring any more difficulty for you.
> 
> Hi Conor and Krzysztof,
> 
> Thanks for the reviews.
> 
> - The next patch will fix the property order to avoid any breakage
>   with existing DT bindings.

Good, thanks.

> - Eth1 does have a timing issue in silicon, as discussed here:
>   https://lore.kernel.org/lkml/32a1f814.2c79.19bfe173225.Coremail.linmin@xxxxxxxxxxxxxxxxxx/
> 
>   Based on this, and according to the advice from Andrew
>   https://lore.kernel.org/lkml/59cec617-0189-4dc3-bc3f-6346155a62ae@xxxxxxx/
>   https://lore.kernel.org/lkml/bd202cfa-d6eb-4d0e-982d-b49795dd25f7@xxxxxxx/
>   adding a DT property is not a reasonable approach.
>   
>   In the next patch, I will improve the description/paragraph and properly
>   document the timing issues.

I personally don't mind having two compatibles, but I might be more
clear about what device the new one refers to (so something like
s/clk-inversion/eth1/g). But Krzysztof was the one who objected to
having multiple compatibles, so it's worth waiting to see what he has to
say.

Attachment: signature.asc
Description: PGP signature