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

[Krzysztof Kozlowski <krzk@kernel.org>]

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.


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