Re: [PATCH v2 6/6] arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay

[Bjorn Andersson <andersson@kernel.org>]

On Fri, Jul 31, 2026 at 11:20:07PM +0530, Rahul Samana wrote:
> 
> 
> On 31-07-2026 21:19, Konrad Dybcio wrote:
> > 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
> 
> Hi Konrad, Dmitry,
> 
> Yes, both Industrial Kit variants need to be supported.
> 
> The default Industrial Kit uses the common Industrial mezzanine hardware
> description and continues to use the existing Bluetooth-over-USB path.

"Kit uses the common" what do you even mean?! The mezzanine is a
physical thing, it doesn't _use_ anything! The mezzanine exists and the
DeviceTree describe what it is.

> The
> reworked Industrial Kit variant keeps the rest of the Industrial mezzanine
> hardware the same, but routes Bluetooth over UART4 instead.
> 

Does "reworked mezzanine" mean what it usually does? I.e. that you have
taken the mezzanine and modified it?

[..]
> 
> I am open to other suggestions if there is a better way to model this within
> the current overlay structure.
> 

I don't think it's possible to give you other suggestions as you haven't
described what this thing is, you just explaining how you're hacking
something together and ask us to help adjust your hack without knowing
what it is you're trying to describe with your DeviceTree.

Regards,
Bjorn

> Thanks,
> Rahul
>