On Tue, Jan 30, 2024 at 3:37 PM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 30/01/2024 04:32, Chen-Yu Tsai wrote:
> > On Mon, Jan 29, 2024 at 3:34 PM Krzysztof Kozlowski
> > <[email protected]> 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.
There's only one interface, SDIO, but two SDIO functions. The two
functions, if both were to be described in the device tree, would
be two separate nodes. We just don't have any use for the WiFi one
right now. Does that make sense to keep the suffix?
> > 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.
I get that. I can fix up the existing users where necessary. A proper
binding would make the driver lookup be more efficient as well.
Thanks
ChenYu
On 30/01/2024 08:47, Chen-Yu Tsai wrote:
> On Tue, Jan 30, 2024 at 3:37 PM Krzysztof Kozlowski
> <[email protected]> wrote:
>>
>> On 30/01/2024 04:32, Chen-Yu Tsai wrote:
>>> On Mon, Jan 29, 2024 at 3:34 PM Krzysztof Kozlowski
>>> <[email protected]> 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.
>
> There's only one interface, SDIO, but two SDIO functions. The two
> functions, if both were to be described in the device tree, would
> be two separate nodes. We just don't have any use for the WiFi one
> right now. Does that make sense to keep the suffix?
Number of functions does not really matter. Number of interfaces on the
bus would matter. Why would you have two separate nodes for the same
SDIO interface? Or do you want to say there are two interfaces?
Best regards,
Krzysztof
On Tue, Jan 30, 2024 at 05:25:38PM +0100, Krzysztof Kozlowski wrote:
> On 30/01/2024 08:47, Chen-Yu Tsai wrote:
> > On Tue, Jan 30, 2024 at 3:37 PM Krzysztof Kozlowski
> > <[email protected]> wrote:
> >>
> >> On 30/01/2024 04:32, Chen-Yu Tsai wrote:
> >>> On Mon, Jan 29, 2024 at 3:34 PM Krzysztof Kozlowski
> >>> <[email protected]> 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.
> >
> > There's only one interface, SDIO, but two SDIO functions. The two
> > functions, if both were to be described in the device tree, would
> > be two separate nodes. We just don't have any use for the WiFi one
> > right now. Does that make sense to keep the suffix?
>
> Number of functions does not really matter. Number of interfaces on the
> bus would matter. Why would you have two separate nodes for the same
> SDIO interface? Or do you want to say there are two interfaces?
Right, one device at 2 addresses on a bus should be a node with 2 "reg"
entries, not 2 nodes with 1 "reg" address each.
Rob