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

[Krzysztof Kozlowski]

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

And why this is sent so many times?

https://lore.kernel.org/all/20260218114955.3970974-2-vivek.sahu@xxxxxxxxxxxxxxxx/

https://lore.kernel.org/all/20260529175342.3363935-1-yepuri.siddu@xxxxxxxxxxxxxxxx/

and now by you.

How many times this will be sent in separate patchsets and asking for
separate review ignoring previous review?

Best regards,
Krzysztof