Re: [PATCH v2 04/10] reset: Add reset_controller_get_provider()

[Philipp Zabel <p.zabel@pengutronix.de>]

On Mi, 2026-07-08 at 12:16 +0200, Geert Uytterhoeven wrote:
> The reset subsystem differs from the clock subsystem in multiple ways:
>   1. It does not provide a public way to lookup resets from a reset
>      provider (clock has of_clk_get_from_provider()),
>   2. The xlate callback does not return a reset object, but merely an
>      index, which is converted to a reset object by the reset core.
> 
> Hence add a public helper reset_controller_get_provider(), which just
> returns the provider, and will be used by the R-Car X5H Module
> Controller driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Please don't. Only the owning reset controller driver and the reset
core should interact with struct reset_controller_dev internals.

I'd be very uncomfortable with a driver reaching directly into another
drivers reset_control_ops, bypassing the core entirely.

I think it would be better to let reset-scmi export a specialized
scmi_reset_assert/deassert/reset(id) API, and add a possibility to
suppress registering the reset-scmi reset controller, so that there
aren't two conflicting paths into scmi_reset_proto_ops.

If you want to stack two reset controllers, the upper one should go
through the proper channels: request exclusive reset controls and use
them via the reset_control_*() APIs from the ops.


regards
Philipp