Re: [PATCH 01/12] dt-bindings: bluetooth: describe wilc 3000 bluetooth chip

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

Hi Krzysztof,

On 2/13/25 10:25, Krzysztof Kozlowski wrote:
>> +  wlan:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      Phandle to the wlan part of the combo chip
> 
> No resources here and judging by the driver everything is part of wifi.
> Either you wrote it to match driver or indeed hardware is like that. In
> the first case, why this cannot be part of WiFi with phandle to serial
> bus? In the second case, this needs to be proper hardware description

First, I'd like to reclarify what the chip exactly is, to make sure that we are
talking about the same thing. The wilc3000 ([1]) is a single physical device
packaging two different discrete modules inside (one for 802.11, one for
bluetooth). The WLAN part has its own binding integrated in upstream kernel
([2]) and is based on a similar chip in the same family (wilc1000, which only
have 802.11, and so only SPI/SDIO, no UART).

Now that it is said, no, I did not write this binding only aiming to match the
new driver. I tried to base this description on how similar WLAN/BT combo chips
are usually described (based on those which have existing bindings), and they
seem to describe distinctly the two internal parts of those chips as well. For
those who use HCI commands over uart for the bluetooth part, they expose a
dedicated child node of a serial controller (distinct from the wlan part,
described as another node on PCI/SDIO/SPI/etc). The hardware architecture for
wilc3000 is similar to those, so since the serial bus is the primary interface
to operate the bluetooth part inside the chip, doesn't it makes sense to have it
under a serial controller node (and then to refer to wlan for the additional
operations needed on sdio/spi), than the other way around ?

About the lack of other resources in the new node: there are indeed additional
resources that affect bluetooth, but I am not sure how it should be handled:
there are for example a reset input and a chip enable input exposed by this
chip, which in fact do not only affect the WLAN part but the two parts inside
the chip. But those are currently described and handled by the WLAN part. I
guess that an improvement regarding this point could then be to move those out
of the wlan binding, and find a way to describe it as shared resources between
those two parts of the chip, but how should it be handled ? Is it ok to remove
those from an existing binding (and if so, where to put those ? It is not
bluetooth specific neither) ? Is the issue rather about current WILC3000 binding
kind of mixing overall chip description and internal wlan part description ?

Thanks,

Alexis

[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/IEEE-802.11-b-g-n-Link-Controller-Module-with-Integrated-Bluetooth-5.0-DS70005327B.pdf
[2]
https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml
> Best regards,
> Krzysztof
> 


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