Re: [PATCH v2 1/6] dt-bindings: bluetooth: qca: add QCC2072

On 01/08/2026 17:31, Rahul Samana wrote:
> 
> 
> On 01-08-2026 20:18, Krzysztof Kozlowski wrote:
>> On 31/07/2026 17:51, Rahul Samana wrote:
>>>
>>>
>>> On 31-07-2026 20:34, Krzysztof Kozlowski wrote:
>>>> On 31/07/2026 16:45, Rahul Samana wrote:
>>>>>
>>>>>
>>>>> On 31-07-2026 15:16, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Jul 27, 2026 at 09:15:01PM +0530, Rahul Samana wrote:
>>>>>>> QCC2072 can be used on M.2 E-key cards where the card power resources are
>>>>>>> described by the pcie-m2-e-connector node. In that setup, the M.2 power
>>>>>>> sequencing provider creates the Bluetooth serdev child after matching the
>>>>>>> QCC2072 PCI function.
>>>>>>>
>>>>>>> Integrated non-M.2 designs need board-specific power resources. Document
>>>>>>> only the compatible for now and leave those properties to be added with
>>>>>>> matching driver support.
>>>>>>>
>>>>>>> Document the qcom,qcc2072-bt compatible used for QCC2072 Bluetooth
>>>>>>> controllers connected over UART.
>>>>>>>
>>>>>>> Signed-off-by: Rahul Samana <[email protected]>
>>>>>>
>>>>>> NAK, exactly same comments as before.
>>>>>>
>>>>>> Nothing got improved, although what is weird - original SoB is gone, so
>>>>>> this is legally dubious work.
>>>>>>
>>>>>> Best regards,
>>>>>> Krzysztof
>>>>>>
>>>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> Thanks for the review.
>>>>>
>>>>> For the binding contents, I tried to capture the current scope in the binding
>>>>> description itself. This series supports QCC2072 only as an M.2 E-key card,
>>>>> where the card power resources are described by the pcie-m2-e-connector node
>>>>> and the M.2 pwrseq provider creates the Bluetooth serdev child.
>>>>>
>>>>> The binding also says:
>>>>>
>>>>>   Integrated non-M.2 designs require board-specific power resources. Those
>>>>>   properties, together with a static devicetree example, should be added when
>>>>>   integrated non-M.2 support is added.
>>>>
>>>> Bindings must be complete and your driver support is irrelevant here.
>>>>
>>>> If you claim this is a PCI device thus you do not need any resources,
>>>> then the binding is not needed either. PCI devices are enumerable. And
>>>> to prove it: look at your DTS. Do you see qcom,qcc2072-bt being used? No.
>>>>
>>>>>
>>>>> We do not currently have an integrated non-M.2 QCC2072 design, so I do not
>>>>> have board-specific regulator supplies to document for that topology.
>>>>>
>>>>> Could you please suggest how you would prefer this binding to be handled for
>>>>> the current M.2-only use case? 
>>>>
>>>> Drop the binding, you do not need it.
>>>>
>>>> Anyway the problem is that more comments were ignored.
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>> Just to clarify the reason for adding this binding in v2: 
>>> v1 did not add a binding because this series only targets the M.2 use case.
>>>
>>> I added the minimal binding in v2 because checkpatch reported
>>> qcom,qcc2072-bt as an undocumented compatible, and I interpreted the request
>>> to fix the checkpatch warnings as requiring this compatible to be documented.
>>> I also had the earlier feedback in mind, where the indirect
>>> qcom,qcc2072-bt compatible was pushed back because it was undocumented:
>>>
>>> https://lore.kernel.org/all/[email protected]/
>>>
>>> Based on your clarification here, I will drop the binding patch in v3 and
>>> keep qcom,qcc2072-bt only as the pwrseq-created child compatible for this
>>> M.2 case.
>>
>> My previous statement is also valid, please read entire threads.
>>
>> You cannot have undocumented qcom,qcc2072-bt.
>>
>> I ask you to drop both, because they are not needed. But feel free to
>> prove me wrong, see my first paragraph in the previous reply.
>>
>>
> The PCIe M.2 power sequencing driver, pwrseq-pcie-m2.c, uses
> pwrseq_m2_pci_ids to translate the enumerated PCI function into the
> Bluetooth compatible used for the generated serdev child.
> 
> For example, WCN7850 maps PCI ID 17cb:1107 to qcom,wcn7850-bt, then hci_qca
> matches that compatible to select qca_soc_data_wcn7850.
> 
> For QCC2072, pwrseq-pcie-m2.c matches PCI ID 17cb:1112 and creates the
> generated Bluetooth serdev child with compatible "qcom,qcc2072-bt". The
> hci_qca driver then matches "qcom,qcc2072-bt" and uses qca_soc_data_qcc2072
> as the controller-specific data.

The purpose of Devicetree is not to describe Linux internal driver
matching. Do not use compatibles for that.


> 
> That match data is needed by hci_qca to select the QCC2072 soc_type,
> firmware/NVM naming, calibration handling, and capabilities. Without some
> identity being passed from the PCI match to the generated serdev child,
> hci_qca cannot distinguish QCC2072 from the other Qualcomm UART Bluetooth
> controllers on this path.
> 
> Please correct me if I misunderstood the concern or if you are asking for
> this identity to be passed from pwrseq-pcie-m2.c to hci_qca through a
> different mechanism.
> 
> I can drop the binding patch, but unless there is a preferred alternative
> mechanism, I think we still need the pwrseq-pcie-m2 QCC2072 PCI ID support
> from patch 3 so the power sequencing driver can pass the QCC2072 identity
> into hci_qca through the generated serdev child:

You have plenty of options, starting from what is very common already -
driver name used by MFD or aux devices.

Best regards,
Krzysztof