drivers/base/auxiliary.c | 23 ++++++ drivers/mfd/mfd-core.c | 137 +++++++++++++++++++++++++++++++--- include/linux/auxiliary_bus.h | 7 ++ 3 files changed, 156 insertions(+), 11 deletions(-)
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. Current support is limited to just PCI
devices, but this can be further extended to support other types like USB
in the future.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
I've been cooking this on my spare time during merge window. I'm not
very confident about this but thought I'd share it. It might be
controversial since I stole quite a bit from platform infrastructure,
so please consider this an RFC and let's discuss how to approach this.
More discussion at [*].
[*] https://lore.kernel.org/r/2025032609-query-limit-491b@gregkh
A few things that are still open,
1. Since we're doing it for PCI devices (Greg's recommendation), how do
we force the existing ones to use their original platform path?
2. Should we allow auxiliary drivers to manage their own resources
(MEM, IO, IRQ etc)?
drivers/base/auxiliary.c | 23 ++++++
drivers/mfd/mfd-core.c | 137 +++++++++++++++++++++++++++++++---
include/linux/auxiliary_bus.h | 7 ++
3 files changed, 156 insertions(+), 11 deletions(-)
diff --git a/drivers/base/auxiliary.c b/drivers/base/auxiliary.c
index afa4df4c5a3f..16cfb615ac2b 100644
--- a/drivers/base/auxiliary.c
+++ b/drivers/base/auxiliary.c
@@ -335,6 +335,29 @@ int __auxiliary_device_add(struct auxiliary_device *auxdev, const char *modname)
}
EXPORT_SYMBOL_GPL(__auxiliary_device_add);
+/**
+ * auxiliary_get_resource - get a resource for a device
+ * @auxdev: auxiliary device
+ * @type: resource type
+ * @num: resource index
+ *
+ * Return: a pointer to the resource or NULL on failure.
+ */
+struct resource *auxiliary_get_resource(struct auxiliary_device *auxdev, unsigned int type,
+ unsigned int num)
+{
+ u32 i;
+
+ for (i = 0; i < auxdev->num_resources; i++) {
+ struct resource *r = &auxdev->resource[i];
+
+ if (type == resource_type(r) && num-- == 0)
+ return r;
+ }
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(auxiliary_get_resource);
+
/**
* __auxiliary_driver_register - register a driver for auxiliary bus devices
* @auxdrv: auxiliary_driver structure
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 76bd316a50af..414ef086ea1d 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -10,6 +10,8 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/acpi.h>
+#include <linux/auxiliary_bus.h>
+#include <linux/pci.h>
#include <linux/list.h>
#include <linux/property.h>
#include <linux/mfd/core.h>
@@ -29,8 +31,15 @@ struct mfd_of_node_entry {
struct device_node *np;
};
-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" },
};
#if IS_ENABLED(CONFIG_ACPI)
@@ -136,10 +145,91 @@ static int mfd_match_of_node_to_dev(struct platform_device *pdev,
return 0;
}
-static int mfd_add_device(struct device *parent, int id,
- const struct mfd_cell *cell,
- struct resource *mem_base,
- int irq_base, struct irq_domain *domain)
+static void mfd_release_auxiliary_device(struct device *dev)
+{
+ struct auxiliary_device *auxdev = to_auxiliary_dev(dev);
+
+ kfree(auxdev);
+}
+
+static int mfd_add_auxiliary_device(struct device *parent, int id, const struct mfd_cell *cell,
+ struct resource *mem_base, int irq_base,
+ struct irq_domain *domain)
+{
+ struct auxiliary_device *auxdev;
+ struct resource *res;
+ int r, ret = -ENOMEM;
+
+ auxdev = kzalloc(sizeof(*auxdev), GFP_KERNEL);
+ if (!auxdev)
+ return ret;
+
+ res = kcalloc(cell->num_resources, sizeof(*res), GFP_KERNEL);
+ if (!res)
+ goto fail_alloc;
+
+ for (r = 0; r < cell->num_resources; r++) {
+ res[r].name = cell->resources[r].name;
+ res[r].flags = cell->resources[r].flags;
+
+ /* Find out base to use */
+ if ((cell->resources[r].flags & IORESOURCE_MEM) && mem_base) {
+ res[r].parent = mem_base;
+ res[r].start = mem_base->start +
+ cell->resources[r].start;
+ res[r].end = mem_base->start +
+ cell->resources[r].end;
+ } else if (cell->resources[r].flags & IORESOURCE_IRQ) {
+ if (domain) {
+ /* Unable to create mappings for IRQ ranges. */
+ WARN_ON(cell->resources[r].start !=
+ cell->resources[r].end);
+ res[r].start = res[r].end = irq_create_mapping(
+ domain, cell->resources[r].start);
+ } else {
+ res[r].start = irq_base +
+ cell->resources[r].start;
+ res[r].end = irq_base +
+ cell->resources[r].end;
+ }
+ } else {
+ res[r].parent = cell->resources[r].parent;
+ res[r].start = cell->resources[r].start;
+ res[r].end = cell->resources[r].end;
+ }
+ }
+
+ auxdev->name = cell->name;
+ auxdev->id = cell->id;
+ auxdev->resource = res;
+ auxdev->num_resources = cell->num_resources;
+ auxdev->dev.parent = parent;
+ auxdev->dev.type = &mfd_dev_type[MFD_AUX_DEV];
+ auxdev->dev.release = mfd_release_auxiliary_device;
+
+ ret = auxiliary_device_init(auxdev);
+ if (ret)
+ goto fail_aux_init;
+
+ ret = auxiliary_device_add(auxdev);
+ if (ret)
+ goto fail_aux_add;
+
+ return 0;
+
+fail_aux_add:
+ /* auxdev will be freed with the put_device() and .release sequence */
+ auxiliary_device_uninit(auxdev);
+fail_aux_init:
+ kfree(res);
+fail_alloc:
+ kfree(auxdev);
+ return ret;
+}
+
+static int mfd_add_platform_device(struct device *parent, int id, const struct mfd_cell *cell,
+ struct resource *mem_base, int irq_base,
+ struct irq_domain *domain)
{
struct resource *res;
struct platform_device *pdev;
@@ -168,7 +258,7 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_device;
pdev->dev.parent = parent;
- pdev->dev.type = &mfd_dev_type;
+ pdev->dev.type = &mfd_dev_type[MFD_PLAT_DEV];
pdev->dev.dma_mask = parent->dma_mask;
pdev->dev.dma_parms = parent->dma_parms;
pdev->dev.coherent_dma_mask = parent->coherent_dma_mask;
@@ -302,6 +392,15 @@ static int mfd_add_device(struct device *parent, int id,
return ret;
}
+static int mfd_add_device(struct device *parent, int id, const struct mfd_cell *cells,
+ struct resource *mem_base, int irq_base, struct irq_domain *domain)
+{
+ if (dev_is_pci(parent))
+ return mfd_add_auxiliary_device(parent, id, cells, mem_base, irq_base, domain);
+ else
+ return mfd_add_platform_device(parent, id, cells, mem_base, irq_base, domain);
+}
+
/**
* mfd_add_devices - register child devices
*
@@ -340,16 +439,22 @@ int mfd_add_devices(struct device *parent, int id,
}
EXPORT_SYMBOL(mfd_add_devices);
-static int mfd_remove_devices_fn(struct device *dev, void *data)
+static int mfd_remove_auxiliary_device(struct device *dev)
+{
+ struct auxiliary_device *auxdev = to_auxiliary_dev(dev);
+
+ auxiliary_device_delete(auxdev);
+ auxiliary_device_uninit(auxdev);
+ return 0;
+}
+
+static int mfd_remove_platform_device(struct device *dev, void *data)
{
struct platform_device *pdev;
const struct mfd_cell *cell;
struct mfd_of_node_entry *of_entry, *tmp;
int *level = data;
- if (dev->type != &mfd_dev_type)
- return 0;
-
pdev = to_platform_device(dev);
cell = mfd_get_cell(pdev);
@@ -372,6 +477,16 @@ static int mfd_remove_devices_fn(struct device *dev, void *data)
return 0;
}
+static int mfd_remove_devices_fn(struct device *dev, void *data)
+{
+ if (dev->type == &mfd_dev_type[MFD_AUX_DEV])
+ return mfd_remove_auxiliary_device(dev);
+ else if (dev->type == &mfd_dev_type[MFD_PLAT_DEV])
+ return mfd_remove_platform_device(dev, data);
+ else
+ return 0;
+}
+
void mfd_remove_devices_late(struct device *parent)
{
int level = MFD_DEP_LEVEL_HIGH;
diff --git a/include/linux/auxiliary_bus.h b/include/linux/auxiliary_bus.h
index 65dd7f154374..11c058e49a3c 100644
--- a/include/linux/auxiliary_bus.h
+++ b/include/linux/auxiliary_bus.h
@@ -148,6 +148,8 @@ struct auxiliary_device {
struct mutex lock; /* Synchronize irq sysfs creation */
bool irq_dir_exists;
} sysfs;
+ u32 num_resources;
+ struct resource *resource;
};
/**
@@ -220,6 +222,8 @@ static inline const struct auxiliary_driver *to_auxiliary_drv(const struct devic
int auxiliary_device_init(struct auxiliary_device *auxdev);
int __auxiliary_device_add(struct auxiliary_device *auxdev, const char *modname);
#define auxiliary_device_add(auxdev) __auxiliary_device_add(auxdev, KBUILD_MODNAME)
+struct resource *auxiliary_get_resource(struct auxiliary_device *auxdev, unsigned int type,
+ unsigned int num);
#ifdef CONFIG_SYSFS
int auxiliary_device_sysfs_irq_add(struct auxiliary_device *auxdev, int irq);
@@ -238,6 +242,9 @@ auxiliary_device_sysfs_irq_remove(struct auxiliary_device *auxdev, int irq) {}
static inline void auxiliary_device_uninit(struct auxiliary_device *auxdev)
{
+ if (auxdev->resource)
+ kfree(auxdev->resource);
+
mutex_destroy(&auxdev->sysfs.lock);
put_device(&auxdev->dev);
}
--
2.34.1Hi Raag, kernel test robot noticed the following build errors: [auto build test ERROR on driver-core/driver-core-testing] [also build test ERROR on driver-core/driver-core-next driver-core/driver-core-linus lee-mfd/for-mfd-next lee-leds/for-leds-next linus/master v6.14 next-20250403] [cannot apply to lee-mfd/for-mfd-fixes] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Raag-Jadav/mfd-core-Support-auxiliary-device/20250403-190322 base: driver-core/driver-core-testing patch link: https://lore.kernel.org/r/20250403110053.1274521-1-raag.jadav%40intel.com patch subject: [PATCH v1] mfd: core: Support auxiliary device config: arm64-randconfig-003-20250403 (https://download.01.org/0day-ci/archive/20250404/202504040556.gg5BerTZ-lkp@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250404/202504040556.gg5BerTZ-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202504040556.gg5BerTZ-lkp@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: auxiliary_device_init >>> referenced by mfd-core.c >>> drivers/mfd/mfd-core.o:(mfd_add_devices) in archive vmlinux.a -- >> ld.lld: error: undefined symbol: __auxiliary_device_add >>> referenced by mfd-core.c >>> drivers/mfd/mfd-core.o:(mfd_add_devices) in archive vmlinux.a -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Hi Raag,
kernel test robot noticed the following build errors:
[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on driver-core/driver-core-next driver-core/driver-core-linus lee-mfd/for-mfd-next lee-leds/for-leds-next linus/master v6.14 next-20250403]
[cannot apply to lee-mfd/for-mfd-fixes]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Raag-Jadav/mfd-core-Support-auxiliary-device/20250403-190322
base: driver-core/driver-core-testing
patch link: https://lore.kernel.org/r/20250403110053.1274521-1-raag.jadav%40intel.com
patch subject: [PATCH v1] mfd: core: Support auxiliary device
config: csky-randconfig-001-20250403 (https://download.01.org/0day-ci/archive/20250403/202504032243.j5qqE6VB-lkp@intel.com/config)
compiler: csky-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250403/202504032243.j5qqE6VB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504032243.j5qqE6VB-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
In file included from drivers/base/auxiliary_sysfs.c:6:
include/linux/auxiliary_bus.h: In function 'auxiliary_device_uninit':
>> include/linux/auxiliary_bus.h:246:17: error: implicit declaration of function 'kfree' [-Wimplicit-function-declaration]
246 | kfree(auxdev->resource);
| ^~~~~
In file included from drivers/base/auxiliary_sysfs.c:7:
include/linux/slab.h: At top level:
>> include/linux/slab.h:472:6: warning: conflicting types for 'kfree'; have 'void(const void *)'
472 | void kfree(const void *objp);
| ^~~~~
include/linux/auxiliary_bus.h:246:17: note: previous implicit declaration of 'kfree' with type 'void(const void *)'
246 | kfree(auxdev->resource);
| ^~~~~
vim +/kfree +246 include/linux/auxiliary_bus.h
242
243 static inline void auxiliary_device_uninit(struct auxiliary_device *auxdev)
244 {
245 if (auxdev->resource)
> 246 kfree(auxdev->resource);
247
248 mutex_destroy(&auxdev->sysfs.lock);
249 put_device(&auxdev->dev);
250 }
251
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Raag,
kernel test robot noticed the following build warnings:
[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on driver-core/driver-core-next driver-core/driver-core-linus lee-mfd/for-mfd-next lee-leds/for-leds-next linus/master v6.14 next-20250403]
[cannot apply to lee-mfd/for-mfd-fixes]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Raag-Jadav/mfd-core-Support-auxiliary-device/20250403-190322
base: driver-core/driver-core-testing
patch link: https://lore.kernel.org/r/20250403110053.1274521-1-raag.jadav%40intel.com
patch subject: [PATCH v1] mfd: core: Support auxiliary device
config: arm-randconfig-002-20250403 (https://download.01.org/0day-ci/archive/20250403/202504032326.2F62UbVV-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250403/202504032326.2F62UbVV-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202504032326.2F62UbVV-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/peci/cpu.c:4:
include/linux/auxiliary_bus.h: In function 'auxiliary_device_uninit':
include/linux/auxiliary_bus.h:246:3: error: implicit declaration of function 'kfree'; did you mean 'ida_free'? [-Werror=implicit-function-declaration]
kfree(auxdev->resource);
^~~~~
ida_free
In file included from drivers/peci/cpu.c:8:
include/linux/slab.h: At top level:
>> include/linux/slab.h:472:6: warning: conflicting types for 'kfree'
void kfree(const void *objp);
^~~~~
In file included from drivers/peci/cpu.c:4:
include/linux/auxiliary_bus.h:246:3: note: previous implicit declaration of 'kfree' was here
kfree(auxdev->resource);
^~~~~
cc1: some warnings being treated as errors
vim +/kfree +472 include/linux/slab.h
7bd230a26648ac Suren Baghdasaryan 2024-03-21 471
72d67229f522e3 Kees Cook 2021-11-05 @472 void kfree(const void *objp);
72d67229f522e3 Kees Cook 2021-11-05 473 void kfree_sensitive(const void *objp);
72d67229f522e3 Kees Cook 2021-11-05 474 size_t __ksize(const void *objp);
05a940656e1eb2 Kees Cook 2022-09-23 475
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Thu, Apr 03, 2025 at 04:30:53PM +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. Current support is limited to just PCI > devices, but this can be further extended to support other types like USB > in the future. > > Signed-off-by: Raag Jadav <raag.jadav@intel.com> > --- > > I've been cooking this on my spare time during merge window. I'm not > very confident about this but thought I'd share it. It might be > controversial since I stole quite a bit from platform infrastructure, > so please consider this an RFC and let's discuss how to approach this. > > More discussion at [*]. > [*] https://lore.kernel.org/r/2025032609-query-limit-491b@gregkh > > A few things that are still open, > > 1. Since we're doing it for PCI devices (Greg's recommendation), how do > we force the existing ones to use their original platform path? That's up to you all, but I wouldn't recommend forcing everything to change for existing drivers. So make it "opt-in" somehow? I would love to make it change for existing drivers, but I don't know what that might break (it _should_ not break anything, but we've already found breakages when moving some platform devices over to other busses like faux due to bugs in userspace scripts.) > 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. thanks, greg k-h
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. I think we should simply enforce the requirement that MFD on AUX bus must use regmap. This will solve the serialisation and common access to the resources. -- With Best Regards, Andy Shevchenko
On Thu, Apr 03, 2025 at 05:16:51PM +0300, Andy Shevchenko 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. > > I think we should simply enforce the requirement that MFD on AUX bus must use > regmap. This will solve the serialisation and common access to the resources. That said, make an additional API call like dev_mfd_add_aux_devices() which should enforce new infrastructure and convert drivers one by one. Also with that you may add a warning to the existing (PCI) drivers that are using old API if (dev_is_pci(parent)) dev_warn(parent, "Uses old API, please switch to ...\n"); -- With Best Regards, Andy Shevchenko
On Thu, Apr 03, 2025 at 05:19:22PM +0300, Andy Shevchenko wrote: > On Thu, Apr 03, 2025 at 05:16:51PM +0300, Andy Shevchenko 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. > > > > I think we should simply enforce the requirement that MFD on AUX bus must use > > regmap. This will solve the serialisation and common access to the resources. > > That said, make an additional API call like > > dev_mfd_add_aux_devices() which should enforce new infrastructure and convert > drivers one by one. Also with that you may add a warning to the existing (PCI) > drivers that are using old API > > if (dev_is_pci(parent)) > dev_warn(parent, "Uses old API, please switch to ...\n"); Don't add "warnings" like this if you aren't also going to actually convert the code. Just convert it, otherwise you pester users with problems that they have no idea how to fix. thanks, greg k-h
On Thu, Apr 03, 2025 at 03:23:22PM +0100, Greg KH wrote: > On Thu, Apr 03, 2025 at 05:19:22PM +0300, Andy Shevchenko wrote: > > On Thu, Apr 03, 2025 at 05:16:51PM +0300, Andy Shevchenko 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. > > > > > > I think we should simply enforce the requirement that MFD on AUX bus must use > > > regmap. This will solve the serialisation and common access to the resources. > > > > That said, make an additional API call like > > > > dev_mfd_add_aux_devices() which should enforce new infrastructure and convert > > drivers one by one. Also with that you may add a warning to the existing (PCI) > > drivers that are using old API > > > > if (dev_is_pci(parent)) > > dev_warn(parent, "Uses old API, please switch to ...\n"); > > Don't add "warnings" like this if you aren't also going to actually > convert the code. Just convert it, otherwise you pester users with > problems that they have no idea how to fix. Good point. I'm wondering how many actually we have PCI MFD (ab)users right now? 30? 100? More? -- With Best Regards, Andy Shevchenko
On Thu, Apr 03, 2025 at 05:26:34PM +0300, Andy Shevchenko wrote: > On Thu, Apr 03, 2025 at 03:23:22PM +0100, Greg KH wrote: > > On Thu, Apr 03, 2025 at 05:19:22PM +0300, Andy Shevchenko wrote: > > > On Thu, Apr 03, 2025 at 05:16:51PM +0300, Andy Shevchenko 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. > > > > > > > > I think we should simply enforce the requirement that MFD on AUX bus must use > > > > regmap. This will solve the serialisation and common access to the resources. > > > > > > That said, make an additional API call like > > > > > > dev_mfd_add_aux_devices() which should enforce new infrastructure and convert > > > drivers one by one. Also with that you may add a warning to the existing (PCI) > > > drivers that are using old API > > > > > > if (dev_is_pci(parent)) > > > dev_warn(parent, "Uses old API, please switch to ...\n"); > > > > Don't add "warnings" like this if you aren't also going to actually > > convert the code. Just convert it, otherwise you pester users with > > problems that they have no idea how to fix. > > Good point. I'm wondering how many actually we have PCI MFD (ab)users right > now? 30? 100? More? $ git grep "struct pci_driver" drivers/mfd/ | wc -l 12 Raag
© 2016 - 2025 Red Hat, Inc.