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

[Rahul Samana <rahul.samana@oss.qualcomm.com>]

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 <rahul.samana@oss.qualcomm.com>
>>>>>
>>>>> 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/20260703-eliza_evk-v1-3-7624440bd76d@oss.qualcomm.com/
>>
>> 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.

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:

https://lore.kernel.org/all/20260727-rb3-industrial-bt-uart-v2-3-2d100f30e202@oss.qualcomm.com/

Thanks,
Rahul


>>
>>> And why this is sent so many times?
>>>
>>> https://lore.kernel.org/all/20260218114955.3970974-2-vivek.sahu@oss.qualcomm.com/
>>>
>>> https://lore.kernel.org/all/20260529175342.3363935-1-yepuri.siddu@oss.qualcomm.com/
>>>
>>> and now by you.
>>>
>>> How many times this will be sent in separate patchsets and asking for
>>> separate review ignoring previous review?
>>>
>>
>> Regarding the repeated submissions, the reason for carrying this forward from
>> the earlier QCC2072 work is documented in the cover letter. This series was
>> intended to continue that work for the RB3 Gen 2 Industrial M.2 use case, not
>> to ignore the earlier reviews. 
> 
> If you continue the work, you do not ignore previous comments, so I do
> not see how this is any sort of continuation. Looks like duplicating
> work without looking at previous discussions at all.
> 
> Best regards,
> Krzysztof