Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Stas Sergeev]

Hello.

gregkh@suse.de wrote:
> This is a note to let you know that I've just added the patch titled
>      Subject: driver core: warn about duplicate driver names on the same bus
> to my gregkh-2.6 tree.  Its filename is
Thanks.

Takashi, do you think this fixes the
pcspkr/snd-pcsp conflict sufficienly
well? I think the Kconfig protection
is no longer needed. For the better
convinience the modprobe rule can be
created that will remove one driver
before inserting another. But this is
optional.
What do you think? Can we now remove
the Kconfig protection?


>      driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch
> 
> This tree can be found at 
>     http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
> 
> 
>>From stsp@aknet.ru Sat Apr 26 08:52:51 2008
> From: Stas Sergeev <stsp@aknet.ru>
> Date: Sat, 26 Apr 2008 19:52:35 +0400
> Subject: driver core: warn about duplicate driver names on the same bus
> To: Andrew Morton <akpm@linux-foundation.org>
> Cc: Greg KH <greg@kroah.com>, Takashi Iwai <tiwai@suse.de>
> Message-ID: <48134FC3.6040002@aknet.ru>
> 
> 
> Currently an attempt to register multiple
> drivers with the same name causes the
> stack trace with some cryptic error message.
> The attached patch adds the necessary check
> and the clear error message.
> 
> Signed-off-by: Stas Sergeev <stsp@aknet.ru>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  drivers/base/driver.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -217,12 +217,22 @@ static void driver_remove_groups(struct 
>  int driver_register(struct device_driver *drv)
>  {
>  	int ret;
> +	struct device_driver *other;
>  
>  	if ((drv->bus->probe && drv->probe) ||
>  	    (drv->bus->remove && drv->remove) ||
>  	    (drv->bus->shutdown && drv->shutdown))
>  		printk(KERN_WARNING "Driver '%s' needs updating - please use "
>  			"bus_type methods\n", drv->name);
> +
> +	other = driver_find(drv->name, drv->bus);
> +	if (other) {
> +		put_driver(other);
> +		printk(KERN_ERR "Error: Driver '%s' is already registered, "
> +			"aborting...\n", drv->name);
> +		return -EEXIST;
> +	}
> +
>  	ret = bus_add_driver(drv);
>  	if (ret)
>  		return ret;
> 
> 
> Patches currently in gregkh-2.6 which might be from stsp@aknet.ru are
> 
> driver-core/driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch
> 

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Greg KH]

On Tue, Apr 29, 2008 at 08:48:08AM +0400, Stas Sergeev wrote:
> Hello.
> 
> gregkh@suse.de wrote:
> > This is a note to let you know that I've just added the patch titled
> >      Subject: driver core: warn about duplicate driver names on the same bus
> > to my gregkh-2.6 tree.  Its filename is
> Thanks.
> 
> Takashi, do you think this fixes the
> pcspkr/snd-pcsp conflict sufficienly
> well? I think the Kconfig protection
> is no longer needed. For the better
> convinience the modprobe rule can be
> created that will remove one driver
> before inserting another. But this is
> optional.

No, don't rely on the driver core warning and catching code errors like
this, that's not a good idea at all.  I like the warning and your patch,
but don't assume it's always going to be there.

thanks,

greg k-h

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Mon, 28 Apr 2008 21:58:49 -0700,
Greg KH wrote:
> 
> On Tue, Apr 29, 2008 at 08:48:08AM +0400, Stas Sergeev wrote:
> > Hello.
> > 
> > gregkh@suse.de wrote:
> > > This is a note to let you know that I've just added the patch titled
> > >      Subject: driver core: warn about duplicate driver names on the same bus
> > > to my gregkh-2.6 tree.  Its filename is
> > Thanks.
> > 
> > Takashi, do you think this fixes the
> > pcspkr/snd-pcsp conflict sufficienly
> > well? I think the Kconfig protection
> > is no longer needed. For the better
> > convinience the modprobe rule can be
> > created that will remove one driver
> > before inserting another. But this is
> > optional.
> 
> No, don't rely on the driver core warning and catching code errors like
> this, that's not a good idea at all.  I like the warning and your patch,
> but don't assume it's always going to be there.

But multiple drivers for the same device are allowed on other buses
like PCI.  I think this is no reason to prohibit the multiple platform
drivers for the same platform device.

Though, I think the snd-pcsp driver could be better built on the top
of input pcspkr driver, or coexist with it.  Then we'll have no more
conflict about platform name space.

When you compare input pcspkr.c and sound pcsp_input.c, you can find
that most of codes are identical.  What we'd need is a hook on
pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
is running.


thanks,

Takashi

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Greg KH]

On Tue, Apr 29, 2008 at 12:41:56PM +0200, Takashi Iwai wrote:
> At Mon, 28 Apr 2008 21:58:49 -0700,
> Greg KH wrote:
> > 
> > On Tue, Apr 29, 2008 at 08:48:08AM +0400, Stas Sergeev wrote:
> > > Hello.
> > > 
> > > gregkh@suse.de wrote:
> > > > This is a note to let you know that I've just added the patch titled
> > > >      Subject: driver core: warn about duplicate driver names on the same bus
> > > > to my gregkh-2.6 tree.  Its filename is
> > > Thanks.
> > > 
> > > Takashi, do you think this fixes the
> > > pcspkr/snd-pcsp conflict sufficienly
> > > well? I think the Kconfig protection
> > > is no longer needed. For the better
> > > convinience the modprobe rule can be
> > > created that will remove one driver
> > > before inserting another. But this is
> > > optional.
> > 
> > No, don't rely on the driver core warning and catching code errors like
> > this, that's not a good idea at all.  I like the warning and your patch,
> > but don't assume it's always going to be there.
> 
> But multiple drivers for the same device are allowed on other buses
> like PCI.  I think this is no reason to prohibit the multiple platform
> drivers for the same platform device.

No, the driver core doesn't allow that at all right now (I'm working on
fixing that though...)

What this patch did is just not allow you to have the same "name" for
the driver on the same bus, which is reasonable as without the check,
sysfs complains about trying to create a duplicate name in the same
directory.

Different names is fine, and I'll continue to work on the ability to
allow multiple drivers for the same device at the same time...

thanks,

greg k-h

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Tue, 29 Apr 2008 08:14:36 -0700,
Greg KH wrote:
> 
> On Tue, Apr 29, 2008 at 12:41:56PM +0200, Takashi Iwai wrote:
> > At Mon, 28 Apr 2008 21:58:49 -0700,
> > Greg KH wrote:
> > > 
> > > On Tue, Apr 29, 2008 at 08:48:08AM +0400, Stas Sergeev wrote:
> > > > Hello.
> > > > 
> > > > gregkh@suse.de wrote:
> > > > > This is a note to let you know that I've just added the patch titled
> > > > >      Subject: driver core: warn about duplicate driver names on the same bus
> > > > > to my gregkh-2.6 tree.  Its filename is
> > > > Thanks.
> > > > 
> > > > Takashi, do you think this fixes the
> > > > pcspkr/snd-pcsp conflict sufficienly
> > > > well? I think the Kconfig protection
> > > > is no longer needed. For the better
> > > > convinience the modprobe rule can be
> > > > created that will remove one driver
> > > > before inserting another. But this is
> > > > optional.
> > > 
> > > No, don't rely on the driver core warning and catching code errors like
> > > this, that's not a good idea at all.  I like the warning and your patch,
> > > but don't assume it's always going to be there.
> > 
> > But multiple drivers for the same device are allowed on other buses
> > like PCI.  I think this is no reason to prohibit the multiple platform
> > drivers for the same platform device.
> 
> No, the driver core doesn't allow that at all right now (I'm working on
> fixing that though...)
> 
> What this patch did is just not allow you to have the same "name" for
> the driver on the same bus, which is reasonable as without the check,
> sysfs complains about trying to create a duplicate name in the same
> directory.
> 
> Different names is fine, and I'll continue to work on the ability to
> allow multiple drivers for the same device at the same time...

Well, I wasn't clear enough -- currently we prohibit the *build* of
snd-pcsp driver when input pcspkr driver is built, regardless whether
module or built-in.  The reason is that sysfs spews an error with a
stack trace when the platform name conflicts, and this appears to be a
serious error.  Disabling the build is the simplest solution in such a
case (when considering built-in driver).

Now, with this patch, the platform name conflict appears non-critical,
and the driver should handle properly for the returned error code.
Thus, there shouldn't be a big obstacle to *build* both drivers.


Takashi

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Greg KH]

On Tue, Apr 29, 2008 at 06:41:20PM +0200, Takashi Iwai wrote:
> At Tue, 29 Apr 2008 08:14:36 -0700,
> Greg KH wrote:
> > 
> > On Tue, Apr 29, 2008 at 12:41:56PM +0200, Takashi Iwai wrote:
> > > At Mon, 28 Apr 2008 21:58:49 -0700,
> > > Greg KH wrote:
> > > > 
> > > > On Tue, Apr 29, 2008 at 08:48:08AM +0400, Stas Sergeev wrote:
> > > > > Hello.
> > > > > 
> > > > > gregkh@suse.de wrote:
> > > > > > This is a note to let you know that I've just added the patch titled
> > > > > >      Subject: driver core: warn about duplicate driver names on the same bus
> > > > > > to my gregkh-2.6 tree.  Its filename is
> > > > > Thanks.
> > > > > 
> > > > > Takashi, do you think this fixes the
> > > > > pcspkr/snd-pcsp conflict sufficienly
> > > > > well? I think the Kconfig protection
> > > > > is no longer needed. For the better
> > > > > convinience the modprobe rule can be
> > > > > created that will remove one driver
> > > > > before inserting another. But this is
> > > > > optional.
> > > > 
> > > > No, don't rely on the driver core warning and catching code errors like
> > > > this, that's not a good idea at all.  I like the warning and your patch,
> > > > but don't assume it's always going to be there.
> > > 
> > > But multiple drivers for the same device are allowed on other buses
> > > like PCI.  I think this is no reason to prohibit the multiple platform
> > > drivers for the same platform device.
> > 
> > No, the driver core doesn't allow that at all right now (I'm working on
> > fixing that though...)
> > 
> > What this patch did is just not allow you to have the same "name" for
> > the driver on the same bus, which is reasonable as without the check,
> > sysfs complains about trying to create a duplicate name in the same
> > directory.
> > 
> > Different names is fine, and I'll continue to work on the ability to
> > allow multiple drivers for the same device at the same time...
> 
> Well, I wasn't clear enough -- currently we prohibit the *build* of
> snd-pcsp driver when input pcspkr driver is built, regardless whether
> module or built-in.  The reason is that sysfs spews an error with a
> stack trace when the platform name conflicts, and this appears to be a
> serious error.  Disabling the build is the simplest solution in such a
> case (when considering built-in driver).
> 
> Now, with this patch, the platform name conflict appears non-critical,
> and the driver should handle properly for the returned error code.
> Thus, there shouldn't be a big obstacle to *build* both drivers.

Ah, ok, that makes more sense :)

thanks,

greg k-h

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
> Though, I think the snd-pcsp driver could be better built on the top
> of input pcspkr driver, or coexist with it.  Then we'll have no more
> conflict about platform name space.
I was trying this in the past.
This never worked out very well.
I disliked the dependancies.
Either snd-pcsp was loading pcspkr,
or there had to be the global variable
to prevent the concurrent access, and
that hurts modularity.

> When you compare input pcspkr.c and sound pcsp_input.c, you can find
> that most of codes are identical.
Yep, its a copy/paste mainly.
I wanted a complete replacement.
Back then, I've been told that multiple
drivers controlling the same device is
never a good idea. But I won't be surprised
if that have changed since. :)

> What we'd need is a hook on
> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
> is running.
How?
And also, with snd-pcsp you have a
mixer control to disable the beeps,
which I find sometimes even more
usefull than the pcm sound itself. :)

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Tue, 29 Apr 2008 23:28:42 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> > Though, I think the snd-pcsp driver could be better built on the top
> > of input pcspkr driver, or coexist with it.  Then we'll have no more
> > conflict about platform name space.
> I was trying this in the past.
> This never worked out very well.

Why?

> I disliked the dependancies.
> Either snd-pcsp was loading pcspkr,
> or there had to be the global variable
> to prevent the concurrent access, and
> that hurts modularity.

But you anyway enable the input pcspkr feature in your snd-pcsp code.
So, basically you depend on (or build on) it.

> > When you compare input pcspkr.c and sound pcsp_input.c, you can find
> > that most of codes are identical.
> Yep, its a copy/paste mainly.
> I wanted a complete replacement.
> Back then, I've been told that multiple
> drivers controlling the same device is
> never a good idea. But I won't be surprised
> if that have changed since. :)
> 
> > What we'd need is a hook on
> > pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
> > is running.
> How?

What you need is a way to check whether input pcspkr can be usable or
not.  You can add a function pointer, for example.

> And also, with snd-pcsp you have a
> mixer control to disable the beeps,
> which I find sometimes even more
> usefull than the pcm sound itself. :)

Yes, that seems useful.


Takashi

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
>> I was trying this in the past.
>> This never worked out very well.
> Why?
Mainly because I was not able to
come up with the good hooks for the
pcspkr driver, and those I tried,
were not applied.
There was a lengthy thread about that.
Now I can't find its beginning and its
end, but some is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html
I also think you were CCed, but maybe
not.

>> I disliked the dependancies.
>> Either snd-pcsp was loading pcspkr,
>> or there had to be the global variable
>> to prevent the concurrent access, and
>> that hurts modularity.
> But you anyway enable the input pcspkr feature in your snd-pcsp code.
> So, basically you depend on (or build on) it.
If they are separate, then "rmmod pcspkr"
should disable the beeps. I don't want
to fuzzy that logic up to something like
- Check if snd-pcsp is loaded
- Use alsamixer to disable beeps, if
it is.
- Use rmmod pcspkr if it is not.
I think there should be always a single
way for the user to disable the beeps.
Now he can choose it by chosing the driver.

>>> What we'd need is a hook on
>>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
>>> is running.
>> How?
> What you need is a way to check whether input pcspkr can be usable or
> not.  You can add a function pointer, for example.
Could you please clarify?
- Should snd-pcsp then forcibly select
pcspkr.c to compile?
- What exactly function pointer, and
where to add?

>> And also, with snd-pcsp you have a
>> mixer control to disable the beeps,
>> which I find sometimes even more
>> usefull than the pcm sound itself. :)
> Yes, that seems useful.
Yes, but problematic when they are separate.
I was trying to add an input event to shut
up pcspkr.c, but that was rejected. Everything
else will introduce the dependancy. The
dependancy will block rmmod, obfuscating the
logic of disabling the beeps.
Just for the record, what problems do you
see with the current solution, where only
one driver drives the device? That looks
rather logical to me. And I also can remember
the complains about pcspkr driver being in
an input drivers section. Some people had
problems finding it there and were asking
to move it to sound menu.

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Wed, 30 Apr 2008 21:45:59 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> >> I was trying this in the past.
> >> This never worked out very well.
> > Why?
> Mainly because I was not able to
> come up with the good hooks for the
> pcspkr driver, and those I tried,
> were not applied.
> There was a lengthy thread about that.
> Now I can't find its beginning and its
> end, but some is here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html
> I also think you were CCed, but maybe
> not.
> 
> >> I disliked the dependancies.
> >> Either snd-pcsp was loading pcspkr,
> >> or there had to be the global variable
> >> to prevent the concurrent access, and
> >> that hurts modularity.
> > But you anyway enable the input pcspkr feature in your snd-pcsp code.
> > So, basically you depend on (or build on) it.
> If they are separate, then "rmmod pcspkr"
> should disable the beeps.

But, they are *not* seperate right now.  snd-pcsp contains pcspkr
functionality.

> I don't want
> to fuzzy that logic up to something like
> - Check if snd-pcsp is loaded
> - Use alsamixer to disable beeps, if
> it is.
> - Use rmmod pcspkr if it is not.
> I think there should be always a single
> way for the user to disable the beeps.
> Now he can choose it by chosing the driver.

And this won't work in most cases.  People don't want to replace the
existing pcspkr driver with snd-pcsp.  They don't want to load the
sound subsystem on their systems just because of beep.

> >>> What we'd need is a hook on
> >>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
> >>> is running.
> >> How?
> > What you need is a way to check whether input pcspkr can be usable or
> > not.  You can add a function pointer, for example.
> Could you please clarify?
> - Should snd-pcsp then forcibly select
> pcspkr.c to compile?
> - What exactly function pointer, and
> where to add?

If you compare pcspkr.c and pcsp_input.c, it's found that the only
essential difference is the additional check at the head of the event
handler:

	if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr)
		return 0;

If this can be added dynamically to input pcspkr.c, no big point to
have duped codes.

> >> And also, with snd-pcsp you have a
> >> mixer control to disable the beeps,
> >> which I find sometimes even more
> >> usefull than the pcm sound itself. :)
> > Yes, that seems useful.
> Yes, but problematic when they are separate.
> I was trying to add an input event to shut
> up pcspkr.c, but that was rejected. Everything
> else will introduce the dependancy. The
> dependancy will block rmmod, obfuscating the
> logic of disabling the beeps.
> Just for the record, what problems do you
> see with the current solution, where only
> one driver drives the device? That looks
> rather logical to me. And I also can remember
> the complains about pcspkr driver being in
> an input drivers section. Some people had
> problems finding it there and were asking
> to move it to sound menu.

Distros usually make input-pcspkr as built-in, not as module.
So, snd-pcsp is practically unusable on standard kernels of major
distros as is, unfortunately...


Takashi

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
> And this won't work in most cases.  People don't want to replace the
> existing pcspkr driver with snd-pcsp.  They don't want to load the
> sound subsystem on their systems just because of beep.
Why should they? They may just stick with
pcspkr driver if they want.

> If you compare pcspkr.c and pcsp_input.c, it's found that the only
> essential difference is the additional check at the head of the event
> handler:
> 	if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr)
> 		return 0;
> If this can be added dynamically to input pcspkr.c, no big point to
> have duped codes.
Another point is PM callbacks. Somehow
snd-pcsp will have to register them with
pcspkr.

> Distros usually make input-pcspkr as built-in, not as module.
> So, snd-pcsp is practically unusable on standard kernels of major
> distros as is, unfortunately...
Oh, that's really bad, I didn't know
they do. For what reason? And how then
people disable the beeps?
Btw, could you please name a few? At
least Fedora has it as a module.

OK, I'll see about using pcspkr.c. But
it looks like the needed hooks won't be
too small (call to disable the beeps and
a call to register the PM callbacks) and
unlikely to be accepted upstream...

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Fri, 02 May 2008 19:38:03 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> > And this won't work in most cases.  People don't want to replace the
> > existing pcspkr driver with snd-pcsp.  They don't want to load the
> > sound subsystem on their systems just because of beep.
> Why should they? They may just stick with
> pcspkr driver if they want.

... if it's not built-in.  And you'd need extra to manage selectively
loading the driver for the very same platform name.

> > If you compare pcspkr.c and pcsp_input.c, it's found that the only
> > essential difference is the additional check at the head of the event
> > handler:
> > 	if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr)
> > 		return 0;
> > If this can be added dynamically to input pcspkr.c, no big point to
> > have duped codes.
> Another point is PM callbacks. Somehow
> snd-pcsp will have to register them with
> pcspkr.

Hmm, isn't platform PM hook enough?
pcspkr.c just sends an event at suspend or shutdown to the event
handler.  So, if the event was shut up at the beginning in the
handler, nothing would be needed.

> > Distros usually make input-pcspkr as built-in, not as module.
> > So, snd-pcsp is practically unusable on standard kernels of major
> > distros as is, unfortunately...
> Oh, that's really bad, I didn't know
> they do. For what reason? And how then
> people disable the beeps?

Why real men need to disable beep? :)

> Btw, could you please name a few? At
> least Fedora has it as a module.

Well, then I remember wrongly or an old information...


Takashi

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
>> Another point is PM callbacks. Somehow
>> snd-pcsp will have to register them with
>> pcspkr.
> Hmm, isn't platform PM hook enough?
> pcspkr.c just sends an event at suspend or shutdown to the event
> handler.  So, if the event was shut up at the beginning in the
> handler, nothing would be needed.
I don't think I understand what you mean...
Currently, pcspkr.c just stops the timer
counter to shut up the beep.
snd-pcsp needs more. snd_pcm_suspend_all()
for instance. Since it doesn't register
itself as a platform driver any more, he
have to register itself into pcspkr.c.
Or?
I mean, sending a "shut up" event to the
pcspkr's handler is not what snd-pcsp
needs to do.

Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

[Takashi Iwai]

At Fri, 02 May 2008 20:22:23 +0400,
Stas Sergeev wrote:
> 
> Hello.
> 
> Takashi Iwai wrote:
> >> Another point is PM callbacks. Somehow
> >> snd-pcsp will have to register them with
> >> pcspkr.
> > Hmm, isn't platform PM hook enough?
> > pcspkr.c just sends an event at suspend or shutdown to the event
> > handler.  So, if the event was shut up at the beginning in the
> > handler, nothing would be needed.
> I don't think I understand what you mean...
> Currently, pcspkr.c just stops the timer
> counter to shut up the beep.
> snd-pcsp needs more. snd_pcm_suspend_all()
> for instance. Since it doesn't register
> itself as a platform driver any more, he
> have to register itself into pcspkr.c.
> Or?

If snd-pcsp can hook up input pcspkr dynamically, you can (should)
register snd-pcsp as a different name, as an individual platform
driver.  Then the whole PM stuff would still belong to snd-pcsp.


Takashi