On 30/01/2024 04:32, Chen-Yu Tsai wrote: > On Mon, Jan 29, 2024 at 3:34 PM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 29/01/2024 04:38, Chen-Yu Tsai wrote: >> >>>>> +allOf: >>>>> + - $ref: bluetooth-controller.yaml# >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + enum: >>>>> + - mediatek,mt7921s-bluetooth >>>> >>>> Can it be also WiFi on separate bus? How many device nodes do you need >>>> for this device? >>> >>> For the "S" variant, WiFi is also on SDIO. For the other two variants, >>> "U" and "E", WiFi goes over USB and PCIe respectively. On both those >>> variants, Bluetooth can either go over USB or UART. That is what I >>> gathered from the pinouts. There are a dozen GPIO pins which don't >>> have detailed descriptions though. If you want a comprehensive >>> binding of the whole chip and all its variants, I suggest we ask >>> MediaTek to provide it instead. My goal with the binding is to document >>> existing usage and allow me to upstream new device trees. >>> >>> For now we only need the Bluetooth node. The WiFi part is perfectly >>> detectable, and the driver doesn't seem to need the WiFi reset pin. >>> The Bluetooth driver only uses its reset pin to reset a hung controller. >> >> Then suffix "bluetooth" seems redundant. > > I think keeping the suffix makes more sense though. The chip is a two > function piece, and this only targets one of the functions. Also, the That's why I asked and you said there is only one interface: SDIO. > compatible string is already used in an existing driver [1] and > soon-to-be in-tree device tree [2]. That's not the way to upstream compatible. You cannot send it bypassing bindings and review and later claim that's an ABI. Best regards, Krzysztof
