[RFC PATCH 00/15] RFC: dm: Add uclass adjunct support

[Simon Glass]

Hi Svyatoslav,

On Fri, 20 Mar 2026 at 02:01, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
>
> чт, 19 бер. 2026 р. о 23:36 Simon Glass <sjg at chromium.org> пише:
> >
> > [Note: this is marked RFC as I am still not sure that this is the best
> > approach. But this is my third redesign so I think it makes sense to get
> > some feedback before trying to refine it further]
> >
>
> Hello Simon!
>
> With all do respect how this change improves current situation? From
> what I can see introducing multi-uclass will bring only chaos and
> confusion.
>
> > U-Boot's driver model requires each device to belong to exactly one
> > uclass. Multi-function hardware must work around this by creating
> > child devices in different uclasses via device_bind_driver_to_node(),
> > with a NOP parent device.
>
> Example you are targeting behaves as it should. MFD can have a
> multiple cell linked to the parent node and/or its subnodes, this is
> not a workaround, this is how Linux MFD operate too. And a parent may
> not be a NOP device, it may be a core providing access or misc
> communication functions (like PMICs do).
>
> >
> > This is quite common: at least 8 PMIC drivers bind sysreset children,
> > every Qualcomm GCC driver (15+ platforms) does this and several PHY
> > drivers bind clock children.
> >
> > This series adds uclass adjuncts, which allow a device to register
> > in additional uclasses without creating child devices. Each adjunct
> > carries its own ops pointer, per-device uclass private/platform
> > data, and sequence number.
> >
> > With this series, uclass lookup and iteration functions include
> > adjunct registrations alongside primary devices. The
> > uclass_foreach_dev() iterator walks all entries in the uclass,
> > including adjunct ones. Iterators that use a struct udevice * to
> > iterate (uclass_find_first_device() etc.) only see primary devices,
> > since they navigate via the embedded primary ucm.
> >
> > A new ucm_ iterator API uses struct uclass_member * as the cursor,
> > enabling adjunct-aware iteration and lookup. It provides find, probe,
> > check, drvdata, seq and ofnode variants. uclass_foreach_dev_probe()
> > uses this internally so that it includes adjuncts.
> >
>
> It seems to be overcomplication. ATM cells can be bound to the parent
> device node and called by the UCLASS from the parent node. For
> example, if PMIC has gpio cells and does not expose them as an
> individual node then gpio driver can be bound to parents node and used
> as a gpio function provider which matches what OF schema expects
> pretty accurately.
>
> > As a concrete example, a Qualcomm GCC driver could register as
> > UCLASS_CLK (primary) with adjunct UCLASS_RESET and
> > UCLASS_POWER_DOMAIN, thus removing the UCLASS_NOP container and the
> > qcom_cc_bind() function. The raa215300 PMIC conversion in this series
> > demonstrates the pattern: one device, no child sysreset driver,
> > no dev_get_priv(dev->parent) indirection.
> >
> > The mechanism is enabled by a new CONFIG_DM_UC_ADJUNCT option. Code size
> > is largely neutral without this, except for the change to add
> > dev_int_set_seq() which is used by PCI boards.
> >
>
> So you basically propose to squash everything into a single enormous
> driver coding every function that MFD provides instead of keeping
> existing layout of separate cells with dedicated function. This seems
> to be a maintainers hell.
>
> > Note that a couple of linker-list fixes are included so that sandbox
> > will start up correctly. It still does not pass all tests though, due to
> > various bugs surfaced by this series. If we go ahead, we will need at
> > least one precursor series to resolve these pre-existing problems.
> >
> > This is an RFC. The next steps could be:
> > - Convert one Qualcomm GCC driver to use adjuncts
> > - Convert one RK8xx PMIC from child-sysreset to adjunct
> > - Update per-subsystem ops accessors (clk_dev_ops(), etc.)
> >

Just to clarify, the goal here is not to squash all MFDs into one. It
is not intended to move away from how Linux handles a particular
subsystem (quite the opposite!)

This is really just aimed at allowing a driver to support multiple
uclasses, in cases where that is useful. It can actually simplify
certain drivers, since they can have their state in one place rather
than having to deal with the parent/child relationships and multiple
priv/plat data. I have had quite a few bugs calling an operation on
dev instead of dev->parent as well. I still believe that modelling a
PMIC with child devices for CLK, REGULATOR, SYSRESET and GPIO makes
sense in many cases. But now it becomes optional. Ssee the example in
this series, which I hope you will agree does actually simplify the
driver.

The original design of driver model was based on uclass being
associated with a particular API, with a device being in a single
uclass. This series is really just looking at what it might look like
if we relaxed that contraint.

I've been thinking about doing this for years...the most recent
impetus comes from the clk/reset/power domain discussion on irc and
Casey's recent series, although in fact that seems to be heading
towards mostly separate infra rather than enhancing driver model. I
would like to steer it towards still integrating fully with clk - e.g.
using clk_get_by_index(), etc.

Regards,
Simon