lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 9 Nov 2022 16:00:05 -0600 From: Rob Herring <robh@...nel.org> To: Dominique Martinet <dominique.martinet@...ark-techno.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Marcel Holtmann <marcel@...tmann.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Luiz Augusto von Dentz <luiz.dentz@...il.com>, Johan Hedberg <johan.hedberg@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, linux-bluetooth@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, "David S . Miller" <davem@...emloft.net>, mizo@...ark-techno.com Subject: Re: [RFC PATCH 1/2] dt-bindings: net: h4-bluetooth: add new bindings for hci_h4 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
Powered by blists - more mailing lists