On Mon, Apr 15, 2024 at 11:45:29AM +0100, Caleb Connolly wrote: > > > On 12/04/2024 20:45, Tom Rini wrote: > > On Fri, Apr 12, 2024 at 08:04:02PM +0100, Caleb Connolly wrote: > > > >> Introduce a new EVT_OF_LIVE event to allow for the livetree to be > >> modified before dm_init_and_scan(). Boards can perform fixups here to > >> handle incompatibilities between U-Boot drivers and upstream DT. > >> > >> This will be used by Qualcomm platforms in future patches to enable > >> setting the dr_mode property if the board doesn't provide one. This has to > >> be > >> set before dm_init_and_scan() is called as this property effects the > >> binding of > >> drivers. > > > > This doesn't quite explain why the answer isn't "fix the device tree > > source" and instead "perform a live fixup". Thanks. > > Hi Tom, > > I think the specifics here that make this difficult is that on some > Qualcomm boards there is only one USB controller, which can be muxed > either to a type-c port or to a USB hub via a DIP switch (the state of > which cannot easily be read out). > > The DT should therefore either not set dr_mode or set it to OTG. This is > what Linux expects (and it can do proper role detection). > > The dwc3 driver in U-Boot currently doesn't have the ability to > dynamically mode switch, this is something I'd like to add (as it would > let us easily flash these boards from U-Boot as well as boot from USB or > ethernet), but in the mean time the only way to get these boards into > host mode (which is the preferred default) is to modify the DT in a way > that breaks Linux. > > Hence the proposal in this patch. > > If this is ok for you then I'll re-send with this additional context in > the commit description.
So this seems even more special cased than what I was thinking it was. Would it really be so hard to just add a dummy driver for a few compatibles in this case? I prefer having two or three real users of a use case before designing the abstraction for it. Thanks. -- Tom
signature.asc
Description: PGP signature