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

On Wed, Aug 05, 2026 at 02:33:51PM +0200, Krzysztof Kozlowski wrote:
> On 05/08/2026 14:09, Manivannan Sadhasivam wrote:
> > On Sat, Aug 01, 2026 at 05:49:53PM +0200, Krzysztof Kozlowski wrote:
> >> On 01/08/2026 17:31, Rahul Samana wrote:
> >>>
> >>>
> >>> 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 <[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.
> >>>>>>
> >>>>>> 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/[email protected]/
> >>>>>
> >>>>> 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.
> >>
> >> The purpose of Devicetree is not to describe Linux internal driver
> >> matching. Do not use compatibles for that.
> >>
> >>
> >>>
> >>> 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:
> >>
> >> You have plenty of options, starting from what is very common already -
> >> driver name used by MFD or aux devices.
> >>
> > 
> > It is not just a driver matching problem, but ensuring that we properly describe
> > the BT device in DT. Since the BT interface of the M.2 device is not
> 
> This device does not exist in DT. This is the problem which started my
> entire investigation and above email.
> 
> I am happy to see proofs of it existing in DTS.
> 
> My proof:
> 1. copy-paste the compatible (qcom,qcc2072-bt) from the binding.
> 2. Open each DTS patch and look for that compatible: no results.
> 

You are right that this compatible didn't exist in DT and I never claimed that
it does.

> 
> 
> > discoverable, we are currently using the PCIe IDs of the M.2 device to create
> > the BT node dynamically under UART node using OF_DYNAMIC as proposed in this
> > patch which got merged already [1]. Then we also create the serdev device and
> > allow the existing BT hci_qca driver to probe and make use of the created DT
> > node.
> 
> Your Linux drivers are not supposed to create internal OF for regular
> DT. Please drop that patch. I do not get why that patch was merged
> without any DT approval.
> 

Both Rob, you and devicetree lists were CCed to the series and there were
reviews from Rob for multiple patches in that series too. So I interpreted his
absence of reviews on other patches in the series as silent Acks.

> DT is not representation of internal device driver instantiation mechanism.
> 

Here, the driver is just creating compatible for a real device. What difference
does it make if the BT node was defined statically in the DT vs created
dynamically? Both nodes do represent a real BT device, not driver's own
representation. And by the time the node was created, the device is physically
attached to the system.

- Mani

-- 
மணிவண்ணன் சதாசிவம்