public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Linux kernel <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: patch	driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree
Date: Fri, 02 May 2008 18:00:24 +0200	[thread overview]
Message-ID: <s5h63tw3dd3.wl%tiwai@suse.de> (raw)
In-Reply-To: <481B355B.9040200@aknet.ru>

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

  reply	other threads:[~2008-05-02 16:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <12094266793898@kroah.org>
2008-04-29  4:48 ` patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree Stas Sergeev
2008-04-29  4:58   ` Greg KH
2008-04-29 10:41     ` Takashi Iwai
2008-04-29 15:14       ` Greg KH
2008-04-29 16:41         ` Takashi Iwai
2008-04-29 16:56           ` Greg KH
2008-04-29 19:28       ` Stas Sergeev
2008-04-30  6:34         ` Takashi Iwai
2008-04-30 17:45           ` Stas Sergeev
2008-05-02 14:07             ` Takashi Iwai
2008-05-02 15:38               ` Stas Sergeev
2008-05-02 16:00                 ` Takashi Iwai [this message]
2008-05-02 16:22                   ` Stas Sergeev
2008-05-02 16:35                     ` Takashi Iwai

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=s5h63tw3dd3.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp@aknet.ru \
    /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