Re: [PATCH 7/9] reset: make the provider of reset-gpios the parent of the reset device

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

On Di, 2025-10-21 at 18:47 +0300, Andy Shevchenko wrote:
> On Tue, Oct 21, 2025 at 05:23:33PM +0200, Bartosz Golaszewski wrote:
> > On Tue, Oct 21, 2025 at 5:03 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Tue, Oct 21, 2025 at 05:55:02PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Oct 21, 2025 at 11:39:41AM +0200, Bartosz Golaszewski wrote:
> > > > > On Tue, Oct 21, 2025 at 11:31 AM Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > > > > On Di, 2025-10-21 at 11:27 +0200, Bartosz Golaszewski wrote:
> 
> [...]
> 
> > > > > > No need to convert all existing drivers right away, but I'd like to see
> > > > > > a user that benefits from the conversion.
> > > > > > 
> > > > > 
> > > > > The first obvious user will be the reset-gpio driver which will see
> > > > > its core code simplified as we won't need to cast between OF and
> > > > > fwnodes.
> > > > 
> > > > +1 to Bart's work. reset-gpio in current form is useless in all my cases
> > > > (it's OF-centric in 2025! We should not do that in a new code).
> > > > 
> > > > More over, conversion to reset-gpio from open coded GPIO APIs is a clear
> > > > regression and I want to NAK all those changes (if any already done) for
> > > > the discrete components that may be used outside of certainly OF-only niche of
> > > > the platforms.
> > > 
> > > To be clear, the conversion that's done while reset-gpio is kept OF-centric.
> > > I'm in favour of using it, but we need to make it agnostic.
> > 
> > As of now, the whole reset framework is completely OF-centric, I don't
> > know what good blocking any such conversions would bring? I intend to
> > convert the reset core but not individual drivers.
> 
> Blocking making new regressions?
> 
> Otherwise as long as reset framework and reset-gpio are agnostic, I'm pretty
> much fine with the idea and conversion.

I think we might be talking about different "conversions" and different
"blocking" here?

1) Conversion of the reset core from of_node to fwnode.
2) Conversion of reset controller drivers from of_node to fwnode.
3) Conversion of consumer drivers from gpiod to reset_control API.

My understanding is:

Bartosz would like to convert the reset core to fwnode (1) but not
convert all the individual reset controller drivers (2). He doesn't
like blocking (1) - this statement was partially in reaction to me
bringing up a previous attempt that didn't go through.

Andy would like to block consumer driver conversions from gpiod to
reset_control API (3) while the reset-gpio driver only works on OF
platforms.

Please correct me if and where I misunderstood.

I think fwnode conversion of the reset controller framework core is a
good idea, I'd just like to see a use case accompanying the conversion.
It seems like enabling the reset-gpio driver to be used on non-OF
platforms could be that. Andy, do you have an actual case in mind?

Certainly dropping the gpiod reset handling from consumer drivers
should not be done while it introduces regressions.

regards
Philipp