Re: [PATCH v2 6/6] arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay
Konrad Dybcio <[email protected]> Fri, 31 Jul 2026 17:49:11 +0200
| 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 7/31/26 4:48 PM, Rahul Samana wrote: > > > On 31-07-2026 18:20, Konrad Dybcio wrote: >> On 7/31/26 8:53 AM, Rahul Samana wrote: >>> >>> >>> On 29-07-2026 18:01, Konrad Dybcio wrote: >>>> On 7/27/26 5:45 PM, Rahul Samana wrote: >>>>> The reworked RB3 Gen 2 Industrial mezzanine keeps the common Industrial >>>>> mezzanine hardware description but routes QCC2072 Bluetooth over UART4 >>>>> instead of the default Bluetooth-over-USB path. I only noticed this now - are there 2 variants of the industrial mezz being sold concurrently? Is the already-in-kernel one some sort of a prototype SKU? i.e. should we support both? >>>>> >>>>> Build this variant by applying the common Industrial mezzanine overlay >>>>> first, followed by the BT UART overlay. The overlay models the M.2 E-key >>>>> connector graph endpoints for PCIe and UART, and disables the on-board >>>>> WCN6750 PMU and UART7 path so the M.2 QCC2072 Bluetooth controller can be >>>>> used instead. >>>> >>>> So is the onboard module disabled? Can we not just use two in parallel? >>>> >>> >>> The Industrial mezzanine variants do not support the on-board WCN6750 >>> wireless path. The common Industrial mezzanine overlay already disables >>> the on-board Wi-Fi node. >> >> What does 'do not support' it mean here? They are physically present >> as part of the SoM, so unless the lanes are somehow diverted away, >> why is it not? >> >> Konrad > > Hi Konrad, > > The WCN6750 module is physically present on the SoM. What I meant is that > the current Industrial mezzanine devicetree already disables the on-board > Wi-Fi path, and this BT UART variant followed the same board-level policy > for the on-board Bluetooth UART/PMU path. Okay, and do we know why that's the case in the first place? > For the endpoint labels, I can move the UART endpoint to the SoC DTSI, > kodiak.dtsi, as uart4_ep. Please do > For the PCIe endpoint, the PCIe path to the M.2 QCC2072 device is not the > PCIe0 root port in kodiak.dtsi. In the composed devicetree, it is > behind the Industrial mezzanine PCIe switch, under: > > /soc@0/pcie@1c00000/pcie@0/pcie@0,0/pcie@2,0 > > > So placing pcie0_port0_ep in kodiak.dtsi would not describe the actual > topology. Yes, that was an omission from my side > I tried adding a generic label/endpoint to that downstream port in the > Industrial mezzanine overlay and referencing it from the BT UART overlay. > However, when the overlays are compiled separately and then composed, that > label is not available while applying the BT UART overlay, so the composed > DTB build fails with FDT_ERR_NOTFOUND. I think this generic description is simply not achievable today without a bigger plan in place Konrad