[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z_OQqgSjHxq6kwDp@smile.fi.intel.com>
Date: Mon, 7 Apr 2025 11:45:30 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Raag Jadav <raag.jadav@...el.com>
Cc: gregkh@...uxfoundation.org, david.m.ertman@...el.com,
ira.weiny@...el.com, lee@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mfd: core: Support auxiliary device
On Mon, Apr 07, 2025 at 11:44:50AM +0300, Andy Shevchenko wrote:
> On Mon, Apr 07, 2025 at 01:16:14PM +0530, Raag Jadav wrote:
> > Extend MFD subsystem to support auxiliary child device. This is useful
> > for MFD usecases where parent device is on a discoverable bus and doesn't
> > fit into the platform device criteria. Purpose of this implementation is
> > to provide discoverable MFDs just enough infrastructure to register
> > independent child devices with their own memory and interrupt resources
> > without abusing the platform device.
> >
> > Current support is limited to just PCI type MFDs, but this can be further
> > extended to support other types like USB in the future.
>
> > PS: I'm leaning towards not doing any of the ioremap or regmap on MFD
> > side and think that we should enforce child devices to not overlap.
>
> Yes, but we will have the cases in the future, whatever,
> for the first step it's okay.
>
> > If there's a need to handle common register access by parent device,
> > then I think it warrants its own driver which adds auxiliary devices
> > along with a custom interface to communicate with them, and MFD on
> > AUX is not the right solution for it.
And yes, I still consider enforcing regmap is the right step to go.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists