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@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