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

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

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.

> 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. 

Regards,
Rahul

> Best regards,
> Krzysztof