All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, ambx1@neo.rr.com
Subject: Re: Linux v2.6.16-rc5
Date: Tue, 28 Feb 2006 02:05:17 +0100	[thread overview]
Message-ID: <4403A1CD.6030203@keyaccess.nl> (raw)
In-Reply-To: <44038BFE.6090907@keyaccess.nl>

Rene Herman wrote:

> All ALSA ISA card drivers, not just CS4236, use the same interface to 
> PnP (the pnp_card_driver struct) meaning they would all appear to be 
> broken in that exact same way as well. Or rather, _any_ ISA-PnP driver 
> using that pnp_card_driver interface (there's also drivers using the 
> pnp_driver interface -- those appear to be okay). CS4236 isn't doing 
> anything special...

If it helps any, I can at least confirm that it's nothing ALSA or CS4236 
specific. This is a minimal, skeleton, pnp_card driver:

=== foo.c

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pnp.h>

MODULE_LICENSE("GPL");

static struct pnp_card_device_id foo_pnp_card_device_id_table[] = {
         { .id = "CSCa836", .devs = { { "CSCa800" } } },
         /* --- */
         { .id = "" }
};

MODULE_DEVICE_TABLE(pnp_card, foo_pnp_card_device_id_table);

static int foo_pnp_probe(struct pnp_card_link *pcard,
	const struct pnp_card_device_id *pid)
{
         struct pnp_dev *pdev;

         printk(KERN_INFO "%s\n", __FUNCTION__);

         pdev = pnp_request_card_device(pcard, pid->devs[0].id, NULL);
         if (!pdev || pnp_activate_dev(pdev) < 0)
                 return -ENODEV;

         // allocate, enable.

         return 0;
}

static void foo_pnp_remove(struct pnp_card_link *pcard)
{
         printk(KERN_INFO "%s\n", __FUNCTION__);

         // disable, deallocate.
}

static struct pnp_card_driver foo_pnp_card_driver = {
         .name           = "foo",
         .id_table       = foo_pnp_card_device_id_table,
         .flags          = PNP_DRIVER_RES_DISABLE,
         .probe          = foo_pnp_probe,
         .remove         = foo_pnp_remove
};

int __init foo_init(void)
{
         return pnp_register_card_driver(&foo_pnp_card_driver);
}

void __exit foo_exit(void)
{
         pnp_unregister_card_driver(&foo_pnp_card_driver);
}

module_init(foo_init);
module_exit(foo_exit);

===

compile with

=== Makefile

ifneq ($(KERNELRELEASE),)

obj-m   := foo.o

else

default:
         $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(shell pwd)

clean:
         $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(shell pwd) 
clean

endif

===

This ofcourse needs ISA-PnP support in the kernel, and actually loading 
it requires replacing the PnP IDs with IDs actually present (these are 
from my CS4236 soundcard).

With 2.6.15.4 and with 2.6.16-rc with Adam's fix applied, an "insmod 
foo.ko && rmmod foo" shows the following in dmesg (this needs the PnP 
debug messages selectable in menuconfig):

   pnp: the driver 'foo' has been registered
   foo_pnp_probe
   pnp: match found with the PnP device '01:01.00' and the driver 'foo'
   pnp: Device 01:01.00 activated.
   foo_pnp_remove
   pnp: Device 01:01.00 disabled.
   pnp: the driver 'foo' has been unregistered

which is as it should be. On 2.6.16-rc without Adam's fix, both the 
"pnp: match found with" and the "foo_pnp_remove" lines are missing:

   pnp: the driver 'foo' has been registered
   foo_pnp_probe
   pnp: Device 01:01.00 activated.
   pnp: Device 01:01.00 disabled.
   pnp: the driver 'foo' has been unregistered

Of course, with this skeleton driver that's not much of a problem, but 
in real drivers it certainly is; in pnp_remove you'd deactivate and 
deallocate anything that was allocated and activated in/through the 
pnp_probe method -- all things associated with this instance of the 
card, normally.

I can also confirm that a driver using the "pnp_driver" interface isn't 
affected by the bug. Same skeleton-type driver:

=== bar.c

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pnp.h>

MODULE_LICENSE("GPL");

static struct pnp_device_id bar_pnp_device_id_table[] = {
         { .id = "CSCa800" },
         /* --- */
         { .id = "" }
};

MODULE_DEVICE_TABLE(pnp, bar_pnp_device_id_table);

static int bar_pnp_probe(struct pnp_dev *pdev,
	const struct pnp_device_id *pid)
{
         printk(KERN_INFO "%s\n", __FUNCTION__);

         if (pnp_activate_dev(pdev) < 0)
                 return -ENODEV;

         // allocate, enable.

         return 0;
}

static void bar_pnp_remove(struct pnp_dev *pdev)
{
         printk(KERN_INFO "%s\n", __FUNCTION__);

         // disable, deallocate.
}

static struct pnp_driver bar_pnp_driver = {
         .name           = "bar",
         .id_table       = bar_pnp_device_id_table,
         .flags          = PNP_DRIVER_RES_DISABLE,
         .probe          = bar_pnp_probe,
         .remove         = bar_pnp_remove
};

int __init bar_init(void)
{
         return pnp_register_driver(&bar_pnp_driver);
}

void __exit bar_exit(void)
{
         pnp_unregister_driver(&bar_pnp_driver);
}

module_init(bar_init);
module_exit(bar_exit);

===

2.6.15.4, 2.6.16-rc with or without Adam's fix:

   pnp: the driver 'bar' has been registered
   pnp: match found with the PnP device '01:01.00' and the driver 'bar'
   bar_pnp_probe
   pnp: Device 01:01.00 activated.
   bar_pnp_remove
   pnp: Device 01:01.00 disabled.
   pnp: the driver 'bar' has been unregistered

So that's all fine. As said though, all ALSA drivers for one are using 
the card_driver interface, and are therefore all broken currently.

Rene.


  reply	other threads:[~2006-02-28  1:04 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27  5:27 Linux v2.6.16-rc5 Linus Torvalds
2006-02-27  5:51 ` Jeff Garzik
2006-02-27  6:21   ` Randy.Dunlap
2006-02-27  6:52     ` Jeff Garzik
2006-02-27  8:13   ` Paul Rolland
2006-02-27 18:04   ` Francois Romieu
2006-02-27 18:38     ` Jeff Garzik
2006-02-27 22:24       ` Pull request for 'for-jeff' branch Francois Romieu
2006-02-27  6:13 ` 2.6.16-rc5: known regressions Adrian Bunk
2006-02-27  6:26   ` Ryan Phillips
2006-02-27  6:39     ` Vojtech Pavlik
2006-02-27  9:14       ` 2.6.16-rc5: known regressions (ps2 mouse/keyboard issues) Duncan
2006-02-27  6:54   ` 2.6.16-rc5: known regressions Jeff Garzik
2006-02-27  7:08     ` Adrian Bunk
2006-02-28  9:40       ` Jens Axboe
2006-03-01  0:17         ` Randy.Dunlap
2006-03-04 13:18           ` Adrian Bunk
2006-02-27 13:36   ` Mark Lord
2006-02-27 14:09   ` Pavel Machek
2006-03-02 14:00   ` [v4l-dvb-maintainer] " Mauro Carvalho Chehab
2006-03-04 13:27     ` Adrian Bunk
2006-03-04 13:39       ` Mauro Carvalho Chehab
2006-03-08 11:13     ` Brian Marete
2006-03-08 20:29       ` Mauro Carvalho Chehab
2006-03-08 22:52         ` Hartmut Hackmann
2006-02-27  7:28 ` Linux v2.6.16-rc5 Dave Jones
2006-02-27 11:20   ` Jens Axboe
2006-02-27 22:42     ` Neil Brown
2006-02-27  7:42 ` Dave Jones
2006-02-27  9:28   ` Nick Piggin
2006-02-27 19:52 ` Rene Herman
2006-02-27 22:51   ` Andrew Morton
2006-02-27 23:32     ` Rene Herman
2006-02-28  1:05       ` Rene Herman [this message]
2006-02-28  1:12         ` Andrew Morton
2006-02-28  9:38 ` Linux v2.6.16-rc5 - regression Peter Hagervall
2006-02-28 10:03   ` Andrew Morton
2006-02-28 11:41     ` Peter Hagervall
2006-02-28 11:49       ` Peter Hagervall
2006-02-28 12:43 ` Linux v2.6.16-rc5 Christoph Hellwig
2006-03-03 16:00 ` Mark Rosenstand
2006-03-03 23:01 ` 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken Adrian Bunk
2006-03-03 23:22   ` Linus Torvalds
2006-03-03 23:43     ` Adrian Bunk
2006-03-03 23:59     ` Andrew Morton
2006-03-04 14:01       ` Roman Zippel
2006-03-04 14:12         ` Nick Piggin
2006-03-04 20:28           ` Andrew Morton
2006-03-08 11:24             ` [2.6 patch] m68k: fix cmpxchg compile errors if CONFIG_RMW_INSNS=n Adrian Bunk
2006-03-05 14:09 ` Linux v2.6.16-rc5 Olaf Hering
2006-03-05 18:59   ` Olaf Hering
2006-03-05 20:02     ` Linus Torvalds
2006-03-05 20:42       ` Olaf Hering
2006-03-05 21:50         ` Paul Mackerras
2006-03-05 21:50           ` Paul Mackerras
2006-03-05 22:22           ` Olaf Hering
2006-03-05 22:22             ` Olaf Hering
2006-03-05 22:44             ` Olaf Hering
2006-03-05 22:44               ` Olaf Hering
2006-03-06  7:48               ` Olaf Hering
2006-03-06 16:48           ` Olaf Hering
2006-03-06 16:48             ` Olaf Hering
2006-03-06 22:20             ` Olaf Hering
2006-03-06 22:20               ` Olaf Hering
2006-03-06 23:02               ` Olaf Hering
2006-03-06 23:02                 ` Olaf Hering
2006-03-11 21:59                 ` Olaf Hering
2006-03-11 21:59                   ` Olaf Hering
2006-03-05 22:03 ` Mathieu Chouquet-Stringer
2006-03-06  2:12   ` Linus Torvalds

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=4403A1CD.6030203@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=akpm@osdl.org \
    --cc=ambx1@neo.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 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.