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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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