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

Svyatoslav Ryhel clamor95 at gmail.com
Fri Mar 20 09:01:01 CET 2026


чт, 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.)
>


More information about the U-Boot mailing list