[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 at kernel.org>
> > 发送时间:2026-03-04 17:30:57 (星期三)
> > 收件人: "Bo Gan" <ganboing at gmail.com>
> > 抄送: "Jakub Kicinski" <kuba at kernel.org>, lizhi2 at eswincomputing.com, devicetree at vger.kernel.org, andrew+netdev at lunn.ch, davem at davemloft.net, edumazet at google.com, robh at kernel.org, krzk+dt at kernel.org, conor+dt at kernel.org, netdev at vger.kernel.org, pabeni at redhat.com, mcoquelin.stm32 at gmail.com, alexandre.torgue at foss.st.com, rmk+kernel at armlinux.org.uk, wens at kernel.org, pjw at kernel.org, palmer at dabbelt.com, aou at eecs.berkeley.edu, alex at ghiti.fr, linux-riscv at lists.infradead.org, linux-stm32 at st-md-mailman.stormreply.com, linux-arm-kernel at lists.infradead.org, linux-kernel at vger.kernel.org, ningyu at eswincomputing.com, linmin at eswincomputing.com, pinkesh.vaghela at einfochips.com, pritesh.patel at einfochips.com, weishangjuan at eswincomputing.com
> > 主题: 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 at eswincomputing.com 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@lunn.ch/
> > > 
> > > 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@eswincomputing.com/
> 
>   Based on this, and according to the advice from Andrew
>   https://lore.kernel.org/lkml/59cec617-0189-4dc3-bc3f-6346155a62ae@lunn.ch/
>   https://lore.kernel.org/lkml/bd202cfa-d6eb-4d0e-982d-b49795dd25f7@lunn.ch/
>   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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260305/3d87d372/attachment.sig>