All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Zary <linux@rainbow-software.org>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Takashi Iwai <tiwai@suse.de>,
	linux-kernel@vger.kernel.org,
	Jon Masters <jonathan@jonmasters.org>,
	Jaroslav Kysela <perex@perex.cz>, Greg KH <gregkh@suse.de>
Subject: Re: MODULE_DEVICE_TABLE(isapnp, ...) does nothing
Date: Wed, 25 Nov 2009 18:17:45 +0100	[thread overview]
Message-ID: <200911251817.48965.linux@rainbow-software.org> (raw)
In-Reply-To: <ac3eb2510911240053n593317b0qe60043988d89810f@mail.gmail.com>

On Tuesday 24 November 2009 09:53:51 Kay Sievers wrote:
> On Mon, Nov 23, 2009 at 22:51, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Mon, 23 Nov 2009 07:10:22 pm Takashi Iwai wrote:
> >> At Mon, 23 Nov 2009 13:59:53 +1030, Rusty Russell wrote:
> >> > Two things are required:
> >> > 1) Modify file2alias to add aliases for isapnp.  This is pretty easy.
> >> > 2) Expose the isapnp devices in sysfs where udev will match them up
> >> >    (/sys/bus/isa/devices/<dev>/modalias I guess?)
> >>
> >> There is non-pnp ISA bus, so I'm afraid "isa" may conflict.
> >> I suppose "isapnp" would be a safer choice.
> >
> > Without pnp, I don't think you can enumerate the ISA bus. Hence I chose
> > "isa:" in the hope that udev would "just work" if isapnp created the
> > modalias under /sys/bus/isa...
> >
> > But Kay says there's a pnp bus (who knew?).  I don't know what he means
> > by unfixable aliases tho, since it's all in the kernel source so we can
> > change it at any time?
>
> Here's a bit of the background:
>
> The aliases in the modules can only match a single value, but PNP
> devices often have vendor specific IDs and usual IDs describing the
> function.
>
> Like here, where the interesting ID is only the second one of the two
> for a single device:
>   $ grep . /sys/bus/pnp/devices/*/id
>   /sys/bus/pnp/devices/00:09/id:LEN0006
>   /sys/bus/pnp/devices/00:09/id:PNP0f13

It's the same for my RTL8019 card:
$ grep . /sys/bus/pnp/devices/*/id
/sys/bus/pnp/devices/01:01.00/id:RTL8019
/sys/bus/pnp/devices/01:01.00/id:PNP80d6

and it works with this (which could be easily generated from the current ne 
module, I think):
alias pnp:dPNP80d6* ne

This works fine too:
alias pnp:dRTL8019* ne
alias pnp:dPNP80d6* ne

> So the kernel device would need to compose a "modalias" string with
> all IDs in a single line. But the in-module aliases can unfortunately
> match only on a single value, like:
>   alias pnp:dPNP0700* floppy
>
> For that reason, a while ago udev switched to acpi aliases entirely,
> and dropped all pnp: usage. The acpi aliases can handle multi-values
> just fine with single strings like:
>   $ cat /sys/bus/acpi/devices/LEN0006:00/modalias
>   acpi:LEN0006:PNP0F13:
>
>   alias acpi*:PNP0700:* floppy
>
> Udev does not use any pnp: or /sys/bus/pnp/ values since a while. But
> there might be still distros who use the (broken) pnp: aliases and
> ship the (also broken) shell scripts to iterate over the sysfs devices
> and call modprobe for all they find.
>
> Thanks,
> Kay



-- 
Ondrej Zary

  parent reply	other threads:[~2009-11-25 17:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-22 21:01 MODULE_DEVICE_TABLE(isapnp, ...) does nothing Ondrej Zary
2009-11-23  3:29 ` Rusty Russell
2009-11-23  8:40   ` Takashi Iwai
2009-11-23 14:13     ` Kay Sievers
2009-11-24  7:29       ` Ondrej Zary
2009-11-24  8:57         ` Kay Sievers
2009-11-24 21:23           ` Ondrej Zary
2009-11-25 12:05             ` Kay Sievers
2009-11-25 13:21               ` Ondrej Zary
2009-11-25 14:42       ` Matthieu CASTET
2009-11-25 15:23         ` Kay Sievers
2009-11-23 21:51     ` Rusty Russell
2009-11-24  8:53       ` Kay Sievers
2009-11-24 23:51         ` Rusty Russell
2009-11-25 11:39           ` Kay Sievers
2009-11-25 17:17         ` Ondrej Zary [this message]
2009-12-18 19:52   ` Ondrej Zary
2009-12-21 10:24     ` Rusty Russell
2010-03-22 13:44       ` Ondrej Zary
2010-03-31  3:50         ` Rusty Russell

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=200911251817.48965.linux@rainbow-software.org \
    --to=linux@rainbow-software.org \
    --cc=gregkh@suse.de \
    --cc=jonathan@jonmasters.org \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=rusty@rustcorp.com.au \
    --cc=tiwai@suse.de \
    /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.