Re: [RFC PATCH 1/2] dt-bindings: net: h4-bluetooth: add new bindings for hci_h4

[Rob Herring]

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