Re: [PATCH v1] mfd: core: Support auxiliary device

From: Andy Shevchenko
Date: Fri Apr 04 2025 - 09:00:25 EST


On Fri, Apr 04, 2025 at 03:35:45PM +0300, Raag Jadav wrote:
> On Fri, Apr 04, 2025 at 03:29:52PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 04, 2025 at 02:36:41PM +0300, Raag Jadav wrote:
> > > On Thu, Apr 03, 2025 at 03:02:47PM +0100, Greg KH wrote:
> > > > On Thu, Apr 03, 2025 at 04:30:53PM +0530, Raag Jadav wrote:

...

> > > > > 2. Should we allow auxiliary drivers to manage their own resources
> > > > > (MEM, IO, IRQ etc)?
> > > >
> > > > The resources are all shared by the "parent" device, that's what makes
> > > > aux drivers work, they need to handle this as there is no unique way to
> > > > carve up the resources here.
> > > >
> > > > So I don't know how you would do this, sorry.
> > >
> > > Perhaps we can carve it up in mfd_add_devices() using start and end members
> > > and error out if they overlap.
> >
> > I don't think we want a flag day. If anything, it should be a new call.
>
> Yes, I mean in mfd_add_auxiliary_device() (as in this patch).
>
> > > Can't we still have a struct resource that is unique to that specific
> > > auxiliary device?
> >
> > Oh, believe me, you won't do that. Save yourself from _a lot_ of troubles with
> > different cases when the shared resources are required.
>
> I think we already have ignore_resource_conflicts flag as part of mfd_cell,
> no?

It's not so easy, and it's not the only thing that's needed. You can dive into
it and see how the request of the resource work. Also note the hardware that
has common registers. Again, using regmap solves most of these issues if not all.

--
With Best Regards,
Andy Shevchenko