linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading
Date: Mon, 3 Oct 2011 13:19:15 +0100	[thread overview]
Message-ID: <20111003121915.GA2117@arm.com> (raw)
In-Reply-To: <20111001164655.GL11710@n2100.arm.linux.org.uk>

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

      reply	other threads:[~2011-10-03 12:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 16:56 [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading Dave Martin
2011-09-30 16:56 ` [RFC PATCH 1/3] ARM: amba: pass a suitable modalias to udev Dave Martin
2011-09-30 16:56 ` [RFC PATCH 2/3] ARM: sound/arm/aaci.c: Define amba module alias Dave Martin
2011-09-30 16:56 ` [RFC PATCH 3/3] ARM: drivers/mmc/host/mmci.c: " Dave Martin
2011-10-01 16:46 ` [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading Russell King - ARM Linux
2011-10-03 12:19   ` Dave Martin [this message]

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=20111003121915.GA2117@arm.com \
    --to=dave.martin@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).