On Wed, Nov 09, 2022 at 04:29:52PM +0900, Dominique Martinet wrote: > Dominique Martinet wrote on Wed, Nov 09, 2022 at 08:54:42AM +0900: > > This is a pretty terrible design, as the Bluetooth side cannot actually > > know when the device is ready as the initialization takes place, but > > that means there really aren't any property to give here > > > > (I haven't reproduced during normal boot, but in particular if I run > > bluetoothd before loading the wifi driver, I need to unbind/bind the > > serial device from the hci_uart_h4 driver to recover bluetooth... > > With that in mind it might actually be best to try to coordinate this > > from userspace with btattach after all, and I'd be happy with that if I > > didn't have to fight our init system so much, but as things stand having > > it autoloaded by the kernel is more convenient for us... Which is > > admitedly a weak reason for you all, feel free to tell me this isn't > > viable) Punting the issue to userspace is not a great solution... > 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? 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. Rob
