Re: [PATCH v2 1/6] dt-bindings: bluetooth: qca: add QCC2072
Rahul Samana <[email protected]> Fri, 31 Jul 2026 20:15:09 +0530
| Newsgroups | org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <[email protected]> |
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. 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? For the authorship concern, I mentioned the earlier QCC2072 contributions in the cover letter, but I understand that is not sufficient. Since this still documents the same qcom,qcc2072-bt compatible introduced by the earlier work, I will carry the earlier authorship / Signed-off-by chain in v3. Regards, Rahul