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

On Wed, Aug 05, 2026 at 11:48:48AM +0530, Rahul Samana wrote:
> 
> 
> On 02-08-2026 09:08, Bjorn Andersson wrote:
> > 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?
> > 
> 
> Hi Bjorn,
> 
> Let me clarify.
> 
> There are two physical RB3 Gen 2 Industrial mezzanine variants that need
> to be supported:
> 
> 1. The existing RB3 Gen 2 Industrial mezzanine variant currently
>    described in-tree, where the M.2 E-key interface routes Bluetooth over
>    USB.
> 
> 2. A reworked RB3 Gen 2 Industrial mezzanine variant, where the
>    mezzanine board was reworked to make the existing M.2 E-key interface
>    route Bluetooth over UART4.
> 

Reworked as in: "there exist a dozen such boards in the world" or is
this an actually supported configuration that can be purchased?


The fact that you call this mezzanine "the BT-UART mezzanine" forces me
to assume that this isn't an actual product, prove me wrong please.

> The reworked variant is a physical mezzanine board variant, not a
> software-only configuration of the same board.
> 

That's obvious.

> The intent of this overlay is to describe only that board-level
> difference while reusing the common Industrial mezzanine description for
> the hardware that remains unchanged.
> 

But then you need to clearly describe what the difference between the
two boards is and model that in a clear way.

Regards,
Bjorn

> Thanks,
> Rahul
> 
> 
> > [..]
> >>
> >> 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
> >>
>