On Mon, 2025-04-28 at 16:08 +0200, Andrew Lunn wrote: > > > > However, with the yaml stuff, if that is basically becoming "DT > > > specification" then it needs to be clearly defined what each value > > > actually means for the system, and not this vague airy-fairy thing > > > we have now. > > > > I agree with Russell that it seems preferable to make it unambiguous whether > > delays are added on the MAC or PHY side, in particular for fine-tuning. If > > anything is left to the implementation, we should make the range of acceptable > > driver behavior very clear in the documentation. > > I think we should try the "Informative" route first, see what the DT > Maintainers think when we describe in detail how Linux interprets > these values. Oh, we should not be Linux-specific. We should describe in detail how *any OS* must interpret values. > > I don't think a whole new set of properties will solve anything. I > would say the core of the problem is that there are multiple ways of > getting a working system, many of which don't fit the DT binding. But > DT developers don't care about that, they are just happy when it > works. Adding a different set of properties won't change that. > > Andrew Hmm, considering that - interpretation of existing properties is inconsistent - we could like something with a consistent interpretation - we can't change how existing drivers interpret the properties, as that would be a breaking change, I don't think we really have any options but to introduce something new, or keep the inconsistent status quo. Best, Matthias -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider https://www.tq-group.com/
