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

[Rahul Samana <rahul.samana@oss.qualcomm.com>]

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.

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

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.

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
>>