netdev - Re: [PATCH v4 1/5] dt-bindings: wireless: wilc1000: Document WILC3000 compatible string

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: <6d73f3da-315b-485c-a1d5-03d5ea378922@denx.de>
Date: Wed, 4 Sep 2024 19:45:44 +0200
From: Marek Vasut <marex@...x.de>
To: Alexis Lothoré <alexis.lothore@...tlin.com>,
 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

On 9/4/24 4:50 PM, Alexis Lothoré wrote:
> Hello Marek,

Hi,

>>> 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).

Maybe switching the current WILC power management to runtime PM would 
simplify things greatly ?