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

This is a discussion on Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 14 of 14

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

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

    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/kern...h-2.6/patches/
    >
    >
    >>From stsp@aknet.ru Sat Apr 26 08:52:51 2008

    > From: Stas Sergeev
    > Date: Sat, 26 Apr 2008 19:52:35 +0400
    > Subject: driver core: warn about duplicate driver names on the same bus
    > To: Andrew Morton
    > Cc: Greg KH , Takashi Iwai
    > 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
    > Signed-off-by: Greg Kroah-Hartman
    >
    > ---
    > 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
    >


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

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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/lin...03.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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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/lin...03.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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread