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

[Chen-Yu Tsai]

On Mon, May 18, 2026 at 7:16 PM Andre Przywara <andre.przywara at arm.com> wrote:
>
> Hi Alexander,
>
> On 5/17/26 22:38, Alexander Sverdlin wrote:
> > Hi Andre,
> >
> > thanks for the quick feedback!
> >
> > On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara 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.


ChenYu