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

[Raag Jadav]

On Fri, Apr 04, 2025 at 04:00:10PM +0300, Andy Shevchenko wrote:
> 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.

What if there are multiple types of resources including multiple ones
of same type?

I know it's not common but we have such cases already in place.

Raag