All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: gregkh@linuxfoundation.org, david.m.ertman@intel.com,
	ira.weiny@intel.com, lee@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mfd: core: Support auxiliary device
Date: Tue, 8 Apr 2025 11:46:59 +0300	[thread overview]
Message-ID: <Z_Tig8ElS5e_UN6I@smile.fi.intel.com> (raw)
In-Reply-To: <Z_TXDg67AtWzNXbg@black.fi.intel.com>

On Tue, Apr 08, 2025 at 10:58:06AM +0300, Raag Jadav wrote:
> 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:

...

> > > 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.
> 
> I've always found such devices to have a parent specific functionality
> that fall under a specific subsystem instead of needing a generic MFD for
> it. But I'd love to be surprised.

We have very "nice" MFD user, which blows up all issues with shared resources
and so on, look at drivers/mfd/sm501.c. The most problematic part there is
request_region().

> > > 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.

...

> > > -static const struct device_type mfd_dev_type = {
> > > -	.name	= "mfd_device",
> > > +enum mfd_dev {
> > > +	MFD_AUX_DEV,
> > > +	MFD_PLAT_DEV,
> > > +	MFD_MAX_DEV
> > > +};
> > > +
> > > +static const struct device_type mfd_dev_type[MFD_MAX_DEV] = {
> > > +	[MFD_AUX_DEV]	= { .name = "mfd_auxiliary_device" },
> > > +	[MFD_PLAT_DEV]	= { .name = "mfd_platform_device" },
> > >  };
> > 
> > This is likely an ABI breakage if anything looks in sysfs for mfd_device.
> 
> I have no insight on the usecase here. Can you please elaborate?

drivers/base/core.c

        if (dev->type && dev->type->name)
		add_uevent_var(env, "DEVTYPE=%s", dev->type->name);

You broke ABI, it's no go.

...

> > > +/*
> > > + * Common structure between MFD parent and auxiliary child device.
> > > + * To be used by leaf drivers to access child device resources.
> > > + */
> > > +struct mfd_aux_device {
> > > +	struct auxiliary_device auxdev;
> > 
> > > +	struct resource	mem;
> > > +	struct resource	irq;
> > > +	/* Place holder for other types */
> > > +	struct resource	ext;
> > 
> > Why this can't be simply a VLA?
> 
> Because it requires resouce identification, and with that we're back to
> platform style get_resource() and friends.

Yes, and it can be done by calling resource_type() over each and checked
respectively. So, why do you need them to open code?

> > > +};

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-04-08  8:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07  7:46 [PATCH v2] mfd: core: Support auxiliary device Raag Jadav
2025-04-07  8:44 ` Andy Shevchenko
2025-04-07  8:45   ` Andy Shevchenko
2025-04-08  8:04     ` Raag Jadav
2025-04-08  8:48       ` Andy Shevchenko
2025-04-08  7:58   ` Raag Jadav
2025-04-08  8:46     ` Andy Shevchenko [this message]
2025-04-08 13:54       ` Raag Jadav
2025-04-07 11:32 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_Tig8ElS5e_UN6I@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=david.m.ertman@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ira.weiny@intel.com \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raag.jadav@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.