[PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Chen-Yu,

On Mon, 2026-05-18 at 22:47 +0800, Chen-Yu Tsai wrote:
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> > > > > @@ -0,0 +1,162 @@
> > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > +/*
> > > > > + * Copyright (c) 2025 Arm Ltd.
> > > > 
> > > > Please put your own copyright here, even if that has been largely copied
> > > > from an existing file.
> > > > 
> > > > > + */
> > > > > +
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "sun50i-a100.dtsi"
> > > > > +#include "sun50i-a100-cpu-opp.dtsi"
> > > > > +
> > > > > +/{
> > > > > +   compatible = "baijie,helper-a133-core",
> > > > > +                "allwinner,sun50i-a100";
> > > > > +
> > > > > +   aliases {
> > > > > +           serial1 = &uart1;       /* BT module */
> > > > 
> > > > Do we really need an alias for the BT UART? And is the BT module
> > > > supported already? Then please add a child node to the UART node.
> > > 
> > > That's the only thing I can do currently regarding BT: stabilize the
> > > serial enumeration, because UART1 cannot be used for anything else
> > > except BT module, because this is soldered inside "core" module.
> > > We can avoid different tty enumeration, should the support for
> > > BT be implemented in the future...
> > > 
> > > > Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
> > > > here. Provide the child node for the WiFi chip, even if there is no
> > > > upstream support in the kernel for it yet.
> > > 
> > > So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> > > has neither upstream driver, nor [upstream] DT bindings. Even github
> > > driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> > > pointless to me at this point to specify anything in the DT for the
> > > chip which doesn't have the bindings idea even theoretically.
> > > 
> > > Nothing in the current DT shall block any future work on the AW869A
> > > support though and the above "aliases" entry shall even guarantee
> > > unchanged serial enumeration shall such support arise.
> > 
> > Fair enough for not providing DT nodes for those unsupported chips, but
> > why do we need to force enumeration? For the eventual Bluetooth usage,
> > the driver will find the respective serial interface by just looking at
> > its parent interface. IIUC there is nothing referring to ttyS1
> > explicitly. So we wouldn't really need an alias, would we?
> > I see that some boards do define an alias, but others with Bluetooth
> > don't, which I think is the right thing to do. Which name the kernel
> > comes up with for UART1 shouldn't matter in any way.
> 
> It does provide a hint for any users enabling more UARTs and adding
> aliases for them that they should number them starting from 2? And
> just stable numbering overall.

that's exactly what I had in mind, as the the status of BT/WiFi might
change in future, we might want to make UART1=tty1 and UART2=tty2
today and this will not change with potentially coming AW869A support.

But that's not an essential feature to me, just nice to have.

-- 
Alexander Sverdlin.