Re: [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver

From: jayakumar alsa
Date: Wed Sep 21 2005 - 02:09:16 EST


> > +static int __devinit snd_cs5535audio_probe(struct pci_dev *pci,
> > + const struct pci_device_id *pci_id)
> > +{
> > + static int dev;
> > + snd_card_t *card;
> > + cs5535audio_t *cs5535au;
> > + int err;
> > +
> > + if (dev >= SNDRV_CARDS)
> > + return -ENODEV;
> > + if (!enable[dev]) {
> > + dev++;
> > + return -ENOENT;
> > + }
> > +
> > + card = snd_card_new(index[dev], id[dev], THIS_MODULE, 0);
> > + if (card == NULL)
> > + return -ENOMEM;
> > +
> > + if ((err = snd_cs5535audio_create(card, pci, &cs5535au)) < 0) {
> > + snd_card_free(card);
> > + return err;
> > + }
> > +
> > + if ((err = snd_cs5535audio_mixer(cs5535au)) < 0) {
> > + snd_card_free(card);
> > + return err;
> > + }
> > +
> > + if ((err = snd_cs5535audio_pcm(cs5535au)) < 0) {
> > + snd_card_free(card);
> > + return err;
> > + }
> > +
> > + strcpy(card->driver, DRIVER_NAME);
> > +
> > + strcpy(card->shortname, "CS5535 Audio");
> > + sprintf(card->longname, "%s %s at 0x%lx, irq %i",
> > + card->shortname, card->driver,
> > + cs5535au->port, cs5535au->irq);
> > +
> > + if ((err = snd_card_register(card)) < 0) {
> > + snd_card_free(card);
> > + return err;
> > + }
> > +
> > + pci_set_drvdata(pci, card);
> > + dev++;
> > + return 0;
> > +}
>
> Ditto.
>
> The handling of `dev' is racy ;)

I took a quick look at the dev handling.

% egrep -B20 "dev\+\+" $lintree/sound/pci/*.c
<snip>
--
../azt3328.c- return -ENODEV;
../azt3328.c- if (!enable[dev]) {
../azt3328.c: dev++;
--
../azt3328.c-
../azt3328.c- pci_set_drvdata(pci, card);
../azt3328.c: dev++;
--
../cmipci.c- return -ENODEV;
../cmipci.c- if (! enable[dev]) {
../cmipci.c: dev++;
--
../cmipci.c- }
../cmipci.c- pci_set_drvdata(pci, card);
../cmipci.c: dev++;
--
<snip>

So I think everyone is doing the same thing. I think probe is called
from driver_probe_device through device_add and in this case that's
from pci_bus_add_device/s from pci_do_scan_bus. I think the device
probe functions are therefore called serially and there is no risk of
a race condition. I hope that's right.

Thanks,
jk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/