On Tue, Jan 27, 2026 at 03:05:48PM +0800, Min Lin wrote:

Hi Andrew,

Thank you for taking the time to review the patch.

quoted

-----Original Messages-----
From: "Andrew Lunn" <andrew@lunn.ch>
Send time:Thursday, 22/01/2026 21:27:34
To: 李志 <redacted>
Cc: "Bo Gan" <redacted>, "Russell King (Oracle)" <linux@armlinux.org.uk>, devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com
Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

quoted

We also intend
to upstream complete DTS files for EIC7700 so the bindings can be validated
against real hardware.

I suggest you prioritise this. ARM-SOC is pretty flexible for
accepting work in progress support for new SoCs. All you really need
is for the board to boot to a login prompt on a serial port using an
initramsfs. So the .dtsi and .dts file can be very slim, CPUs, memory
and UARTs.

Once you have that merged you can work on the other drivers, their
bindings, etc.

The eic7700.dtsi and eic7700-hifive-premier-p550.dts are already in
v6.19-rc6.

Great.

Because the device drivers such as Ethernet rely on the clock driver,
our plan is that once the clock driver is applied, we will add other
device nodes such as Ethernet and eMMC in the next upstream patch
of the DTS. Is this reasonable?

Yes, this is reasonable. When you submit Ethernet support, please
include the DT patches as part of the series, so we can see the full
picture. When it comes to actually merging it could be the DT patches
get separated out and go a different path, but we can decide that when
we get to that stage.

Given the new information, it becomes clear that backwards
compatibility is not an issue. Since mainline does not have any users
of the Ethernet driver, you should make non-backwards compatible
changes in order to keep things clean. Just ensure the commit messages
point out there are no users, so the changes are safe.

	Andrew