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