Hi Billy,

On Tue, 2026-02-10 at 06:28 +0000, Billy Tsai wrote:

quoted

* Linus Walleij [off-list ref] [260209 09:51]:

quoted

On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai [off-list ref] wrote:

quoted

To make sure I align with your expectations:
1) Would you prefer the new driver to be fully standalone (using the
   GENERIC_PIN* helpers + syscon/regmap-mmio), rather than trying to
   refactor/export helpers from pinctrl-single?

Yes. Conor improved these helpers so now it should be possible
to use these to do a very simple and slim driver for what you
want to do.

quoted

   Action item: Introduce a new pinctrl-single-bit.c driver and DT
   binding, which can also cover the existing bit-per-mux logic currently
   in pinctrl-single.c.

Sounds about right.

quoted

2) For the syscon/regmap hookup, is it acceptable to add a syscon phandle
   property in DT (e.g. "syscon = <&scu>;") for the new driver to obtain
   the regmap, or do you prefer a different binding/property name?

This works for me.

quoted

Great, sounds good to me too!

Hi Tony & Linus,

Thanks again for the earlier guidance — that was very helpful.

I wanted to double-check one remaining detail around the syscon/regmap
hookup. As discussed before, using an explicit syscon phandle on the
pinctrl node (e.g. syscon = <&scu>) is fine from my side, and I
understand that approach is acceptable.

Andrew also pointed out that, for AST2700/SoC0, the SCU is moving towards
an auxiliary-bus based model, where subfunctions such as pinctrl are
instantiated as auxiliary devices by the SCU driver itself, with the
pinctrl node appearing as a subnode of the SCU binding. In that setup,
the pinctrl driver would obtain the regmap from its parent device rather
than via an explicit DT phandle, similar to what is discussed here:
  https://lore.kernel.org/all/459f84c56a5010910ecbf8b445c092674f060691.camel@codeconstruct.com.au/ (local)

Before proceeding, I wanted to confirm whether this auxbus-based approach
for the new pinctrl-single-bit driver would also be acceptable from your
perspective, given that it avoids introducing a generalized DT-based
syscon hookup up front and aligns with the SoC0 direction.

While how we describe the hardware in the devicetree is important, the
impact on the driver is ultimately some glue code. I think the thing to
prioritise right now is the design, implementation and testing of the
bit-per-mux functionality, less so how we get the driver bound to the
device and retrieve the syscon.

The proposal I made in the message you linked is a bit speculative at
the moment. It needs buy-in from the DT maintainers as it proposes some
rework of what's already in-place. That needs thought, but perhaps it
can come a bit later. For now you could write a proof-of-concept
implementation of the glue code for testing purposes (which we may
replace once we resolve the binding discussion).

Andrew

PS: However, regarding the syscon property itself, it's probably worth
paying attention to the "“syscon” is not a generic property" note in
https://docs.kernel.org/devicetree/bindings/writing-bindings.html#typical-cases-and-caveats