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@xxxxxxxxxxxxxxxx> > > > --- > > > 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