All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Colin Foster <colin.foster@in-advantage.com>
Cc: linux-gpio@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	UNGLinuxDriver@microchip.com,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [RFC v5 net-next 08/13] mfd: add interface to check whether a device is mfd
Date: Thu, 30 Dec 2021 13:43:53 +0000	[thread overview]
Message-ID: <Yc23mTo6g1tBiMjT@google.com> (raw)
In-Reply-To: <20211230020443.GB1347882@euler>

On Wed, 29 Dec 2021, Colin Foster wrote:

> On Wed, Dec 29, 2021 at 03:25:55PM +0000, Lee Jones wrote:
> > On Sat, 18 Dec 2021, Colin Foster wrote:
> > 
> > > Some drivers will need to create regmaps differently based on whether they
> > > are a child of an MFD or a standalone device. An example of this would be
> > > if a regmap were directly memory-mapped or an external bus. In the
> > > memory-mapped case a call to devm_regmap_init_mmio would return the correct
> > > regmap. In the case of an MFD, the regmap would need to be requested from
> > > the parent device.
> > > 
> > > This addition allows the driver to correctly reason about these scenarios.
> > > 
> > > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > > ---
> > >  drivers/mfd/mfd-core.c   |  5 +++++
> > >  include/linux/mfd/core.h | 10 ++++++++++
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > > index 684a011a6396..905f508a31b4 100644
> > > --- a/drivers/mfd/mfd-core.c
> > > +++ b/drivers/mfd/mfd-core.c
> > > @@ -33,6 +33,11 @@ static struct device_type mfd_dev_type = {
> > >  	.name	= "mfd_device",
> > >  };
> > >  
> > > +int device_is_mfd(struct platform_device *pdev)
> > > +{
> > > +	return (!strcmp(pdev->dev.type->name, mfd_dev_type.name));
> > > +}
> > > +
> > 
> > Why is this device different to any other that has ever been
> > mainlined?
> 
> Hi Lee,
> 
> First, let me apologize for not responding to your response from the
> related RFC from earlier this month. It had been blocked by my spam
> filter and I had not seen it until just now. I'll have to check that
> more diligently now.
> 
> Moving on...
> 
> That's a question I keep asking myself. Either there's something I'm
> missing, or there's something new I'm doing.
> 
> This is taking existing drivers that work via MMIO regmaps and making
> them interface-independent. As Vladimir pointed out here:
> https://lore.kernel.org/all/20211204022037.dkipkk42qet4u7go@skbuf/T/
> device_is_mfd could be dropped in lieu of an mfd-specific probe
> function.
> 
> If there's something I'm missing, please let me know. But it feels like
> devm_get_regmap_from_resource at the end of the day would be the best
> solution to the design, and that doesn't exist. And implementing
> something like that is a task that I feel I'm not capable of tackling at
> this time.

I'm really not a fan of leaking any MFD API outside of drivers/mfd.
MFD isn't a tangible thing.  It's a Linuxiusm, something we made up, a
figment of your imagination.

What happens if you were to all dev_get_regmap() in the non-MFD case
or when you call devm_regmap_init_mmio() when the driver was
registered via the MFD framework?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2021-12-30 13:44 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-18 21:49 [RFC v5 net-next 00/13] add support for VSC75XX control over SPI Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 01/13] mfd: ocelot: add support for external mfd control over SPI for the VSC7512 Colin Foster
2021-12-19  1:55   ` kernel test robot
2021-12-29 15:22   ` Lee Jones
2021-12-30  1:43     ` Colin Foster
2022-01-10 12:16       ` Lee Jones
2022-01-11  0:33         ` Colin Foster
2022-01-11 10:13           ` Lee Jones
2022-01-11 13:44             ` Mark Brown
2022-01-11 16:53               ` Colin Foster
2022-01-11 17:00                 ` Lee Jones
2022-01-11 18:28                   ` Colin Foster
2022-01-11 18:41                     ` Alexandre Belloni
2022-01-15  2:07                     ` Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 02/13] mfd: ocelot: offer an interface for MFD children to get regmaps Colin Foster
2021-12-29 15:23   ` Lee Jones
2021-12-29 19:34     ` Alexandre Belloni
2021-12-29 20:12       ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 03/13] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 04/13] net: dsa: felix: add configurable device quirks Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 05/13] net: mdio: mscc-miim: add ability to externally register phy reset control Colin Foster
2021-12-19  0:33   ` kernel test robot
2021-12-18 21:49 ` [RFC v5 net-next 06/13] net: dsa: ocelot: add external ocelot switch control Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 07/13] mfd: ocelot: enable the external switch interface Colin Foster
2021-12-29 15:24   ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 08/13] mfd: add interface to check whether a device is mfd Colin Foster
2021-12-29 15:25   ` Lee Jones
2021-12-30  2:04     ` Colin Foster
2021-12-30 13:43       ` Lee Jones [this message]
2021-12-30 20:12         ` Colin Foster
2022-01-10 12:23           ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 09/13] net: mdio: mscc-miim: add local dev variable to cleanup probe function Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 10/13] net: mdio: mscc-miim: add MFD functionality through ocelot-core Colin Foster
2021-12-19  0:13   ` kernel test robot
2021-12-18 21:49 ` [RFC v5 net-next 11/13] mfd: ocelot-core: add control for the external mdio interface Colin Foster
2021-12-29 15:26   ` Lee Jones
2021-12-18 21:49 ` [RFC v5 net-next 12/13] pinctrl: ocelot: add MFD functionality through ocelot-core Colin Foster
2021-12-18 21:49 ` [RFC v5 net-next 13/13] mfd: ocelot: add ocelot-pinctrl as a supported child interface Colin Foster
2021-12-29 15:26   ` Lee Jones

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=Yc23mTo6g1tBiMjT@google.com \
    --to=lee.jones@linaro.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=colin.foster@in-advantage.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.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.