Rob Herring wrote on Wed, Nov 09, 2022 at 04:00:05PM -0600: > Punting the issue to userspace is not a great solution... I can definitely agree with that :) Userspace has the advantage of being easy to shove ugly things under the rug, whereas I still have faint hope of keeping down the divergences we have with upstream kernel... But that's about it. If we can work out a solution here I'll be very happy. Rob Herring wrote on Wed, Nov 09, 2022 at 04:00:05PM -0600: > > This actually hasn't taken long to bite us: while the driver does work, > > we get error messages early on before the firmware is loaded. > > (In hindsight, I probably should have waited a few days before sending > > this...) > > > > > > My current workaround is to return EPROBE_DEFER until we can find a > > netdev with a known name in the init namespace, but that isn't really > > something I'd consider upstreamable for obvious reasons (interfaces can > > be renamed or moved to different namespaces so this is inherently racy > > and it's just out of place in BT code) > > Can't you just try to access the BT h/w in some way and defer when that > fails? This is just a serial link; I've tried poking at it a bit before the firmware is loaded but mostly never got any reply, or while the driver sometimes got garbage back at some point (baudrate not matching with fresh boot default?) Either way, no reply isn't great -- just waiting a few ms for reply or not is not my idea of good design... > Or perhaps use fw_devlink to create a dependency on the wifi node. I'm > not sure offhand how exactly you do that with a custom property. That sounds great if we can figure how to do that! >From what I can see this doesn't look possible to express in pure devicetree, but I see some code initializing a fwnode manually in a constructor function with fwnode_init and a fwnode_operations vector that has .add_links, which in turn could add a link. ... My problem at this point would be that I currently load the wireless driver as a module as it's vendor provided out of tree... (it's loaded through its pci alias, I guess it's udev checking depmod infos? not familiar how that part of autoloading really works...) But that makes me think that rather than defining the bluetooth serdev in dts early, I could try to have the wireless driver create it once it's ready? hmm... Let me sleep on that a bit and have another look at both fwnode (fw_devlink) and dynamic device creation. Cheers, -- Dominique
