[PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support

[Leo Liang]

Hi YanHong, Torsten, Matthias,

On Thu, Apr 13, 2023 at 06:05:56PM +0800, yanhong wang wrote:
> 
> 
> On 2023/4/13 17:03, Torsten Duwe wrote:
> > On Thu, 13 Apr 2023 10:05:28 +0800
> > yanhong wang <yanhong.wang at starfivetech.com> wrote:
> > 
> >> the definition of DT refers to Linux and is consistent with the definition framework of Linux.
> > 
> > This is one of the desired goals, to avoid confusion, usually. But note there are already the
> > -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel
> > required a different treatment. As long as the resulting tree matches the hardware!
> > 
> >> The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, 
> >> which are reflected in DT, and the difference in defconfig is the configuration of the DT file.
> >> 
> >> Is defconfig defined separately or merged?
> > 
> > You are the implementer, this is your decision. You make a proposal, and it will get accepted
> > or not. We only make suggestions, with the intention to improve the code.
> > 
> 
> Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, 
> so defconfig is better defined separately.
> 
> >> The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to 
> >> incorporate EEPROM into this submission?
> >>
> >> When eeprom is supported, the MAC address will be read from eeprom. The board reversion 
> >> can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT.
> > 
> > But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right?
> > 
> 
> Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B.
> 
> 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined
> by DT, which is more concise and clear.
> 
> > When I look at the code and my test results, this is my proposal to pull this in, in order to
> > simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap:
> > 
> > * the device tree *must* match the hardware at hand.
> > 
> > * the differences are minor and could be patched, Copy&Waste is error prone and causes extra work.
> > 
> > It is my firm conviction that this patch set does not introduce hardware variants, and it would be
> > the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching
> > method. Maybe I find a few cycles to look at the EEPROM.
> > 
> > 	Torsten

Agree with Torsten.

I too IMHO think it makes much sense that 
whether "to split the (DT + defconfig)" or "patching DT"
should be the task of ethernet driver patch.

However, this patch set is rather complete and stay on the ML
for quite a time. And also Torsten has sent out the RFC patch 
that is going for the patching method.

In that sense, I think I could probably merge this v5 patch set
with [v4 17/17] patch that only introduces a single defconfig,
and wait for Torsten's DT patches if you guys agree.

Any thoughts?

Best regards,
Leo