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]
Message-ID: <95ae0eb6-72ec-4261-b9e1-8ee3e831452e@bootlin.com>
Date: Wed, 4 Sep 2024 16:50:29 +0200
From: Alexis Lothoré <alexis.lothore@...tlin.com>
To: Marek Vasut <marex@...x.de>, linux-wireless@...r.kernel.org
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 "David S. Miller" <davem@...emloft.net>,
 Adham Abozaeid <adham.abozaeid@...rochip.com>,
 Ajay Singh <ajay.kathat@...rochip.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>, Conor Dooley
 <conor+dt@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Kalle Valo <kvalo@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH v4 1/5] dt-bindings: wireless: wilc1000: Document WILC3000
 compatible string

Hello Marek,

On 9/3/24 21:30, Marek Vasut wrote:
> On 9/3/24 6:09 PM, Alexis Lothoré wrote:

[...]

>> It is only after those 3 steps that the chip can be used with standard hci
>> commands over serial port. IMHO 1 is the biggest point, because it means that
>> **a bluetooth driver for wilc3000 needs access to the bus used by wlan part**
>> (so only describing the bluetooth part of the chip as a child node of an uart
>> controller is not enough). Aside from bus access, I also expect some
>> interactions between bluetooth and wifi (eg: power management, sleep/wakeup)
> 
> Just a quick idea -- what about having a phandle to the BT UART node in the
> wilc3000 node ? Then the wilc driver can check if the phandle is available and
> valid, and attach the BT part to the UART, while also doing all the necessary
> power sequencing and bus accesses via SDIO/SPI.
> 
> Like this:
> 
> &uart10 {
>   status = "okay";
> };
> 
> &mmc20 {
>   ...
>   wifi@0 {
>     compatible = "microchip,wilc1000";
>     microchip,bt-uart = <&uart10>; // OPTIONAL
>     ...
>   };
> };

I thought about something like this too, indeed (but somehow inverted, a
reference to wilc node in the bt node under uart, to allow the bluetooth part to
ask wilc to perform operations over sdio/spi). The design would likely be
simpler in this case, but some internal discussions with colleagues raised some
concerns, for example with power management (but Krzysztof's suggestion about
power sequencing may help with this).

Thanks,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ