Hi Michal, On 2026-05-05T12:30:28, Michal Simek <[email protected]> wrote: > reset: Add reset_reset() and reset_reset_bulk() API > > Add reset_reset() and reset_reset_bulk() functions to the reset > controller API. These functions assert and then deassert reset signals > in a single call, providing a convenient way to pulse/toggle a reset > line. > > This mimics the Linux kernel's reset_control_reset() and > reset_control_bulk_reset() APIs. The new functions are useful for > drivers that need to cycle a reset line during initialization or > error recovery but with also passing delay parameter. > > If a driver implements the rst_reset op, it will be called directly > with the delay parameter. Otherwise, the reset core performs > reset_assert(), optional udelay(), and reset_deassert() as fallback. > > Signed-off-by: Michal Simek <[email protected]> > > drivers/reset/reset-uclass.c | 34 ++++++++++++++++++++++++++++++++++ > include/reset-uclass.h | 12 ++++++++++++ > include/reset.h | 41 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 87 insertions(+)
Reviewed-by: Simon Glass <[email protected]> optional nits / thoughts below > diff --git a/include/reset-uclass.h b/include/reset-uclass.h > @@ -76,6 +76,18 @@ struct reset_ops { > + /** > + * rst_reset - Reset a HW module. > + * > + * This optional function triggers a reset pulse on the reset line, > + * asserting and then deasserting the reset signal. If not implemented, > + * the reset core will use rst_assert followed by rst_deassert. > + * > + * @reset_ctl: The reset signal to pulse. > + * @delay_us: Delay in microseconds between assert and deassert. > + * @return 0 if OK, or a negative error code. > + */ > + int (*rst_reset)(struct reset_ctl *reset_ctl, ulong delay_us); Please document that the core inserts a udelay(delay_us) between rst_assert and rst_deassert in the fallback path, and clarify whether an rst_reset implementation must honour delay_us or may treat it as a hint. Without that, authors don't really know what to do with the value. > diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c > @@ -225,6 +226,39 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk) > +int reset_reset_bulk(struct reset_ctl_bulk *bulk, ulong delay_us) > +{ > + int i, ret; > + > + for (i = 0; i < bulk->count; i++) { > + ret = reset_reset(&bulk->resets[i], delay_us); > + if (ret < 0) > + return ret; > + } > + > + return 0; > +} Just to check - pulsing each reset sequentially means the first finishes its full assert/delay/deassert before the next starts asserting. For the cadence_qspi case in 3/4, where multiple OSPI reset lines are expected to be asserted together, the previous code did assert_bulk() / udelay() / deassert_bulk() so all lines were held low simultaneously. The new behaviour is different. Is that intentional, and have you confirmed the cadence controller is happy with it? Regards, Simon
