[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7572a63-73e0-4d1c-af04-6930e4bdc84f@bootlin.com>
Date: Wed, 4 Sep 2024 16:32:15 +0200
From: Alexis Lothoré <alexis.lothore@...tlin.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, 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
Hi Krzysztof,
On 9/3/24 20:47, Krzysztof Kozlowski wrote:
> On 03/09/2024 18:09, Alexis Lothoré wrote:
[...]
>> After considering multiple solutions to try to share this bus between existing
>> wlan driver and a new bt driver (mfd device, auxiliary bus, device link + some
>
> Driver design should not have impact on bindings.
>
>> handles, etc), my current best guess is to convert wilc driver to a MFD driver
>> for wilc3000. I guess some work can be done so that the driver can still be
>> shared between wilc1000 and wilc3000 _while_ remaining compatible with current
>> wilc1000 description, but it would impact the DT description for wilc3000, which
>> would need to switch from this:
>>
>> spi {
>> wifi@0 {
>> compatible = "microchip,wilc3000";
>> [...]
>> };
>> };
>>
>> To something like this:
>>
>> spi {
>> wilc@0 {
>> compatible = "microchip,wilc3000"; /* mfd driver */
>
> I do not see any reason why... or rather: What is MFD here? MFD is Linux
> stuff and we talk about hardware.
>
>> wifi {
>> compatible = "microchip,wilc3000-wlan";
>
> Why? Just merge it to parent...
>
>> [...]
>> };
>> bt {
>> compatible = "microchip,wilc3000-bt";
>> XXXX; /* some link to the uart controller connected to the chip */
>
> That's not how we represent UART devices. I don't understand why do you
> need these - if for power sequencing, then use power sequencing
> framework and describe associated hardware (there are some talks coming
> about it in 2 weeks). If for something else, then for what?
I have to check more for this power sequencing framework, it look likes it could
handle parts of the wifi/bt shared power management, but it will not cover
everything. The need for this bus on the BT side is not only for power
sequencing, there is some chip initialization to be performed over this bus,
like firmware upload to the chip (not the wifi firmware, it is an additional
bluetooth firmware).
I guess you are referring to Bartosz Golaszewski's talk at Plumbers.
Unfortunately I can not attend, but I'll make sure to check the materials once
available :)
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists