[RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading

[RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading

[Dave Martin]

There's no special reason why AMBA device drivers should not be
auto-loadable via udev, but udev currently has no way to map AMBA
device IDs to drivers.

As part of the effort to help enable the building of multiple
platforms into a single kernel image in the future, it's desirable
to be able to build any non-critical platform-specific drivers as
modules.


A straightforward solution is to use modaliases to allow udev to
identify the correct driver module to load.

This series adds the needed MODALIAS uevent property when sending
events concerning amba bus devices, and adds appropriate
MODULE_ALIAS() declarations to a couple of modules.

Briefly tested on Versatile Express.

Any comments and feedback are welcome.


Issues:

  * Do new module alises need to be globally agreed/registered
    somewhere?

  * Because a driver's ID table is in match-and-mask format whereas
    udev uses string pattern matching, we effectively have to
    maintain two ID tables per driver, containing the same
    information in different formats.  The patch to mmci.c gives an
    example.

    I predict that maintenance of those duplicated tables will be
    somewhat painful and error-prone.  However, the necessary
    transformations, while simple, are beyond the scope of the C
    preprocessor.

    In order to avoid this duplication of information, an extra
    (but simple) bit of build-time infrastructure would be needed.

    I think this effort would be worth it -- does anyone have
    strong views on this?

Dave Martin (3):
  ARM: amba: pass a suitable modalias to udev
  ARM: sound/arm/aaci.c: Define amba module alias
  ARM: drivers/mmc/host/mmci.c: Define amba module alias

 drivers/amba/bus.c      |    9 ++++++++-
 drivers/mmc/host/mmci.c |    8 ++++++++
 sound/arm/aaci.c        |    2 ++
 3 files changed, 18 insertions(+), 1 deletions(-)

--
1.7.4.1

[RFC PATCH 1/3] ARM: amba: pass a suitable modalias to udev

[Dave Martin]

This patch defines and imlpements a new modalias for AMBA devices:

        MODALIAS=amba:xxxxxxxx

where 'x' is a hex digit in lower case.

This enables udev to auto-load modules transparently for AMBA
devices, provided that each driver makes suitable MODULE_ALIAS()
declarations based on the supported AMBA device IDs.

Without this, drivers built as modules never get loaded, unless
they are loaded manually.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 drivers/amba/bus.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index d74926e..7d2ba0b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -52,7 +52,14 @@ static int amba_uevent(struct device *dev, struct kobj_uevent_env *env)
 	int retval = 0;
 
 	retval = add_uevent_var(env, "AMBA_ID=%08x", pcdev->periphid);
-	return retval;
+	if (retval)
+		return retval;
+
+	retval = add_uevent_var(env, "MODALIAS=amba:%08x", pcdev->periphid);
+	if (retval)
+		return retval;
+
+	return 0;
 }
 #else
 #define amba_uevent NULL
-- 
1.7.4.1

[RFC PATCH 2/3] ARM: sound/arm/aaci.c: Define amba module alias

[Dave Martin]

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 sound/arm/aaci.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/sound/arm/aaci.c b/sound/arm/aaci.c
index d0cead3..2e68bfd 100644
--- a/sound/arm/aaci.c
+++ b/sound/arm/aaci.c
@@ -1097,6 +1097,8 @@ static struct amba_id aaci_ids[] = {
 	{ 0, 0 },
 };
 
+MODULE_ALIAS("amba:???41041");
+
 static struct amba_driver aaci_driver = {
 	.drv		= {
 		.name	= DRIVER_NAME,
-- 
1.7.4.1

[RFC PATCH 3/3] ARM: drivers/mmc/host/mmci.c: Define amba module alias

[Dave Martin]

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 drivers/mmc/host/mmci.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 56e9a41..ea2a72c 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1477,6 +1477,14 @@ static struct amba_id mmci_ids[] = {
 	{ 0, 0 },
 };
 
+MODULE_ALIAS("amba:00?41180");
+MODULE_ALIAS("amba:01?41180");
+MODULE_ALIAS("amba:???41181");
+MODULE_ALIAS("amba:??180180");
+MODULE_ALIAS("amba:??280180");
+MODULE_ALIAS("amba:0?480180");
+MODULE_ALIAS("amba:1?480180");
+
 static struct amba_driver mmci_driver = {
 	.drv		= {
 		.name	= DRIVER_NAME,
-- 
1.7.4.1

[RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading

[Russell King - ARM Linux]

On Fri, Sep 30, 2011 at 05:56:39PM +0100, Dave Martin wrote:
> Issues:
> 
>   * Do new module alises need to be globally agreed/registered
>     somewhere?

I don't think there is.  Having the bus prefix in there is definitely a
good thing.

>   * Because a driver's ID table is in match-and-mask format whereas
>     udev uses string pattern matching, we effectively have to
>     maintain two ID tables per driver, containing the same
>     information in different formats.  The patch to mmci.c gives an
>     example.
> 
>     I predict that maintenance of those duplicated tables will be
>     somewhat painful and error-prone.  However, the necessary
>     transformations, while simple, are beyond the scope of the C
>     preprocessor.
> 
>     In order to avoid this duplication of information, an extra
>     (but simple) bit of build-time infrastructure would be needed.
> 
>     I think this effort would be worth it -- does anyone have
>     strong views on this?

I think there is some support for udev to use PCI ID tables directly.
I don't know how that works - I suspect it requires module tools
support though.  Might be worth investigating.

[RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading

[Dave Martin]

On Sat, Oct 01, 2011 at 05:46:55PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2011 at 05:56:39PM +0100, Dave Martin wrote:
> > Issues:
> > 
> >   * Do new module alises need to be globally agreed/registered
> >     somewhere?
> 
> I don't think there is.  Having the bus prefix in there is definitely a
> good thing.

OK, I'll stick with "amba:" for now, then.

> >   * Because a driver's ID table is in match-and-mask format whereas
> >     udev uses string pattern matching, we effectively have to
> >     maintain two ID tables per driver, containing the same
> >     information in different formats.  The patch to mmci.c gives an
> >     example.
> > 
> >     I predict that maintenance of those duplicated tables will be
> >     somewhat painful and error-prone.  However, the necessary
> >     transformations, while simple, are beyond the scope of the C
> >     preprocessor.
> > 
> >     In order to avoid this duplication of information, an extra
> >     (but simple) bit of build-time infrastructure would be needed.
> > 
> >     I think this effort would be worth it -- does anyone have
> >     strong views on this?
> 
> I think there is some support for udev to use PCI ID tables directly.
> I don't know how that works - I suspect it requires module tools
> support though.  Might be worth investigating.

Hmmm, it looks like there's some magic for other bus types like PCI and
USB, where some scripting generates appropriate module aliases from
drivers' device tables (see scripts/mod/file2alias.c)

I'll see whether we can hook into that.  This would allow us to avoid
having to describe the aliases explicitly.

Thanks for the feedback.

Cheers
---Dave