From: Andre Przywara <andre.przywara@arm.com>
To: Julian Calaby <julian.calaby@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Chen-Yu Tsai <wens@csie.org>,
Samuel Holland <samuel@sholland.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Yixun Lan <dlan@gentoo.org>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev
Subject: Re: [RFC PATCH 8/9] pinctrl: sunxi: a523-r: add a733-r compatible string
Date: Thu, 10 Sep 2026 15:31:40 +0200 [thread overview]
Message-ID: <82b2541c-ea6b-41d0-89b1-ecf9a9920cd9@arm.com> (raw)
In-Reply-To: <CAGRGNgXsG5FmwFTSE1BM5qDHz_Jovb4EuRtt-=ipavBDf7AzJQ@mail.gmail.com>
Hi Julian,
I know this email is almost comically old, but still didn't want this
left unanswered before sending a new revision:
On 8/24/25 01:09, Julian Calaby wrote:
> Hi Andre,
>
> On Thu, Aug 21, 2025 at 10:46 AM Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> The secondary Allwinner A733 pincontroller ("-r") is interestingly not
>> using the same new MMIO frame layout as the main controller, but is in
>> fact very similar to the A523-r one: it has two banks, with 14 and 6 pins
>> each. From the driver's perspective, this is all we care about, so we can
>> re-use the a523-r pinctrl driver for the a733-r, too.
>>
>> The individual pinmux settings are different, so we must not use the
>> a523-r compatible string as a fallback, but we can surely let the same
>> driver care for both the a523-r and a733-r IP, as the pinmux values will
>> be provided by the DT.
>
> If the bank and pin counts are the same and the pinmux values are
> provided by the DT, that means they _are_ compatible, right?
I wouldn't say so: I would argue the devices are different, and not
necessarily every driver written for the old device can cope with the
new one. For instance U-Boot still goes with hardcoded pinmux tables
(because that's simpler to implement there), which don't match between
A523-R and A733-R.
And I would see a point if that would enable old kernels to use that new
SoC, but because the main pinctrl is different anyway, that doesn't help us.
But it's not a very strong opinion, so if the maintainers disagree with
me, I am happy to change that.
Cheers,
Andre
next prev parent reply other threads:[~2026-09-10 13:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 0:42 [RFC PATCH 0/9] pinctrl: sunxi: Allwinner A733 support Andre Przywara
2025-08-21 0:42 ` [RFC PATCH 1/9] pinctrl: sunxi: rename SUNXI_PINCTRL_NEW_REG_LAYOUT Andre Przywara
2025-09-08 13:53 ` Jernej Škrabec
2025-08-21 0:42 ` [RFC PATCH 2/9] pinctrl: sunxi: pass down flags to pinctrl routines Andre Przywara
2025-08-21 0:42 ` [RFC PATCH 3/9] pinctrl: sunxi: only use PortK special handling on A523 Andre Przywara
2025-08-21 0:42 ` [RFC PATCH 4/9] pinctrl: sunxi: refactor IRQ register accessors Andre Przywara
2025-08-21 0:42 ` [RFC PATCH 5/9] pinctrl: sunxi: support A733 generation MMIO register layout Andre Przywara
2025-08-21 0:42 ` [RFC PATCH 6/9] pinctrl: sunxi: add support for set/clear regs Andre Przywara
2025-08-21 12:35 ` Linus Walleij
2025-08-21 0:42 ` [RFC PATCH 7/9] dt-bindings: pinctrl: add compatible for Allwinner A733 Andre Przywara
2025-08-21 18:14 ` Conor Dooley
2025-08-21 0:42 ` [RFC PATCH 8/9] pinctrl: sunxi: a523-r: add a733-r compatible string Andre Przywara
2025-08-23 23:09 ` Julian Calaby
2026-09-10 13:31 ` Andre Przywara [this message]
2025-08-21 0:42 ` [RFC PATCH 9/9] pinctrl: sunxi: Add support for the Allwinner A733 Andre Przywara
2026-07-03 0:07 ` [RFC PATCH 0/9] pinctrl: sunxi: Allwinner A733 support Enzo Adriano
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=82b2541c-ea6b-41d0-89b1-ecf9a9920cd9@arm.com \
--to=andre.przywara@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@gentoo.org \
--cc=jernej.skrabec@gmail.com \
--cc=julian.calaby@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=samuel@sholland.org \
--cc=wens@csie.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox