public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: arvidjaar@mail.ru
Cc: linux-kernel@vger.kernel.org, rusty@rustcorp.com.au, ambx1@neo.rr.com
Subject: Re: modules.pnpmap output support
Date: Mon, 17 Nov 2003 16:37:50 +0100	[thread overview]
Message-ID: <s5had6vj99t.wl@alsa2.suse.de> (raw)
In-Reply-To: <E1ALky0-000N9I-00.arvidjaar-mail-ru@f25.mail.ru>

At Mon, 17 Nov 2003 18:07:04 +0300,
Andrey Borzenkov wrote:
> 
> > > 
> > > Oh, BTW, it reminds me - file2alias prints hex in upper
> > > case while both sysfs and hotplug present them in lower case
> > > (for sure for USB and PCI, and for PNP entries detected by 
> > > PNP BIOS). Should not we unify representation?
> > 
> > hmm, file2alias uses lower letters as the identifier (seprator?), so i
> > think simply using lower hex letter will be confusing.  wouldn't it be
> > better to have an  explicit delimter character like ':' (or '/' or
> > whatever) ?
> > 
> 
> those are not meant to be end-user visible anyway so no I do not
> expect any confustion. Nor do I suggest making them lower case -
> we could fix all occurences in kernel instead :)
> 
> if you want to use separator, = is probably better. v=XXXp=YYY

well, parsing pnp would be easiser because the id is always 7
letters, so no need for that...

> > at first i'll try to add the support of old isapnp format for
> > compatibility, so that old programs can work as they are.
> >
> 
> ??? old programs do not know about modules.alias at all. Or I
> do not understand what you mean.
 
no, not modules.alias but the old modules.isapnpmap, which depmod
should generate, too.


> > the file2alias format of (isa) pnp devices will need variable number
> > of items, since a driver may require multiple ids.
> > for example, snd-cs4236 driver supports the cards with three ids like
> > 	CSCe825:CSC0100:CSC0110
> > and four ids like
> > 	CSCd937:CSC0000:CSC0010:CSC0003
> > in each case, a matching card must include all ids listed there.
> > 
> 
> do you mean that card will have to have all of these IDs to match? 
> 
> I can't get it reading sources. When driver matches card against
> card driver it is apparently using only main IDs, not logical
> device IDs:
> 
> driver/pnp/card.c:match_card()
> 
> static const struct pnp_card_device_id * match_card(struct pnp_card_driver * drv, struct pnp_card * card)
> {
>  	const struct pnp_card_device_id * drv_id = drv->id_table;
>  	while (*drv_id->id){
>  		if (compare_pnp_id(card->id,drv_id->id))
>  			return drv_id;
>  		drv_id++;
>  	}
>  	return NULL;
>  }
> 
> where are drv_id->devs used?

hmm, i thought it checks the device ids but apparently it's not.
IMO, this is a bug, because there are cards with the same card id but
different device ids. (e.g. sound/isa/cs423x/cs4236.c)
in the logic above, only the first matching entry is checked and it
results in the failure of probing.

Adam, what do you think?


> because the point of modules.alias is to follow the same logic (to
> determine which driver to load), where do ->devs fit in?

> > well, i'm not sure which identifier (separator) letter in which style
> > should be used.  something like
> > 	pnp:idXXXxxxxd0XXXxxxxd1XXXXxxxx
> 
> leave it as is, it is just fine actually. Assuming you really need
> those extra IDs at all.
> 
> What application do you have in mind? I aim at hotplug, i.e.
> (isa|bios)pnp after getting list of devices would call hotplug to load
> drivers. So i need the same logic as in driver matching and this
> does not need extra IDs.

yes, sure, the alias stuff should reflect to the driver's probing logic.

well, in the case of hotplug, the device ids aren't meaningful,
because (so far) there is no confliction between drivers with the same
card id.  i mean, in theory, it's possible that the driver A supports
only ids X:Y while the driver B X:Z (where X is the card id, Y and Z
are device ids).


--
Takashi Iwai <tiwai@suse.de>		ALSA Developer - www.alsa-project.org

  reply	other threads:[~2003-11-17 15:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-17 12:37 modules.pnpmap output support "Andrey Borzenkov" 
2003-11-17 13:34 ` Takashi Iwai
2003-11-17 14:05   ` Takashi Iwai
2003-11-20  4:35     ` Rusty Russell
2003-11-20  9:40       ` Takashi Iwai
2003-11-17 15:07   ` "Andrey Borzenkov" 
2003-11-17 15:37     ` Takashi Iwai [this message]
2003-11-20 21:23       ` Adam Belay
2003-11-21 11:44         ` Takashi Iwai
2003-11-23 22:07           ` Adam Belay
2003-11-25 10:29             ` Takashi Iwai
2003-11-27 14:41         ` file2alias for pnp (Re: modules.pnpmap output support) Takashi Iwai
2003-11-27 18:58           ` Andrey Borzenkov
2003-11-28 12:11             ` Takashi Iwai
2003-12-02 22:31               ` Adam Belay
2003-12-03 11:31                 ` Takashi Iwai
2003-11-18  3:07 ` modules.pnpmap output support Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2003-11-14 14:07 Takashi Iwai
2003-11-17  3:46 ` Rusty Russell
2003-11-17 11:19   ` Takashi Iwai
2003-11-18  3:01     ` 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=s5had6vj99t.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=ambx1@neo.rr.com \
    --cc=arvidjaar@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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