From: sashiko-bot@kernel.org
To: "Alexander Sverdlin" <alexander.sverdlin@gmail.com>
Cc: robh@kernel.org, linux-sunxi@lists.linux.dev,
conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 4/5] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
Date: Mon, 18 May 2026 00:26:31 +0000 [thread overview]
Message-ID: <20260518002631.EBDE7C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260517234134.2737320-5-alexander.sverdlin@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Misplaced `vcc-pl-supply` property and incorrect architectural attribution in comments.
- [Low] Commit message contradiction regarding USB topology.
--
commit d668428c158ab5f1654141d1c2e6dd96b970af49
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
Add initial support for both the Helper and Core boards, including UART,
PMU, eMMC, USB, Ethernet, and LRADC-connected buttons.
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
This isn't a bug, but is the description of the USB topology accurate?
A USB port operating in peripheral mode cannot be routed through a standard
downstream USB hub to act as a device, as USB hubs are strictly
host-to-device interfaces.
Does the onboard hub instead connect to the ehci1/ohci1 host port to
provide the 2 USB 2.0 ports, while the usb_otg port is directly
connected to the USB-C port?
[ ... ]
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-core.dtsi
> new file mode 100644
> index 0000000000000..7a09a5181c03b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-core.dtsi
[ ... ]
> +&pio {
> + vcc-pb-supply = <®_dcdc1>;
> + vcc-pc-supply = <®_eldo1>;
> + vcc-pd-supply = <®_dcdc1>;
> + vcc-pe-supply = <®_dldo2>;
> + vcc-pf-supply = <®_dcdc1>;
> + vcc-pg-supply = <®_dldo1>;
> + vcc-ph-supply = <®_dcdc1>;
> + /*
> + * PL0/PL1 are the I2C connection to PMIC, but it would create a
> + * circular dependency:
> + * vcc-pl-supply = <®_aldo3>;
> + */
> +};
Does this comment accurately reflect the hardware architecture?
In Allwinner A100/A133 SoCs, the main pio pin controller manages banks
PB through PH, while Port L (PL) pins are managed by a separate r_pio
controller in the PRCM domain.
If vcc-pl-supply were uncommented here, wouldn't it simply be ignored
by the pio node rather than creating a circular dependency? Should this
property and comment instead be associated with the r_pio node?
[ ... ]
> +®_aldo3 {
> + /*
> + * Port L, but linking it to &pio node would create a circular
> + * dependency because of PL0/PL1 I2C connection to PMIC
> + */
> + regulator-always-on;
> + regulator-min-microvolt = <1800000>;
Similarly here, should this comment refer to the r_pio node instead of
the pio node?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260517234134.2737320-1-alexander.sverdlin@gmail.com?part=4
next prev parent reply other threads:[~2026-05-18 0:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 23:41 [PATCH v3 0/5] Add support for Baijie Helper A133 board Alexander Sverdlin
2026-05-17 23:41 ` [PATCH v3 1/5] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd Alexander Sverdlin
2026-05-17 23:41 ` [PATCH v3 2/5] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible Alexander Sverdlin
2026-05-17 23:50 ` sashiko-bot
2026-05-18 16:47 ` Conor Dooley
2026-05-17 23:41 ` [PATCH v3 3/5] arm64: dts: allwinner: a100: Add LRADC node Alexander Sverdlin
2026-05-18 0:02 ` sashiko-bot
2026-05-24 19:23 ` Chen-Yu Tsai
2026-05-17 23:41 ` [PATCH v3 4/5] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board Alexander Sverdlin
2026-05-18 0:26 ` sashiko-bot [this message]
2026-05-17 23:41 ` [PATCH v3 5/5] arm64: defconfig: Enable Allwinner LRADC input driver Alexander Sverdlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260518002631.EBDE7C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexander.sverdlin@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.