From: Rene Herman <rene.herman@keyaccess.nl>
To: Greg KH <gregkh@suse.de>
Cc: Ingo Oeser <ioe-lkml@rameria.de>,
linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>,
ALSA devel <alsa-devel@alsa-project.org>
Subject: Re: [ALSA STABLE 3/3] a few more -- unregister platform device again if probe was unsuccessful
Date: Fri, 14 Apr 2006 01:12:17 +0200 [thread overview]
Message-ID: <443EDAD1.8090406@keyaccess.nl> (raw)
In-Reply-To: <20060413220205.GA1770@suse.de>
Greg KH wrote:
> I still really don't understand why these ALSA drivers are so unlike
> any of the zillion other drivers we have in the kernel that work just
> fine today.
It's nothing to do with ALSA, only with ISA -- ALSA is just one of the
few remaining serious ISA users. Have said this a number of times now,
so apologies to anyone who _is_ following this. I promise it's going to
be the last time. The issue:
Historically, ALSA ISA drivers failed to load upon not finding their
hardware at load time, same as most ISA drivers. When 2.6.16 switched
them to use of the platform driver interface this behaviour was
inadvertently changed due to the platform driver interface not passing
up the probe() return. Things such as the "alsaconf" configuration
script actualy rely on the non-load behaviour and current submissions to
-stable simply use drvdata() being !NULL as a private success flag to
restore that behaviour. This is okay.
Longer term (than -stable) it could ofcourse be better to follow the
model from saner busses such as PCI more closely -- we could just load
whether or not a device was bound to. The difference though is that a
PCI device has a life all by itself by virtue of its _bus_ knowing that
it's present (it has an entry in /sys/devices/pci*, without any device
specific driver loaded) while these old ISA devices only exist in the
driver model by virtue of a driver creating them as a platform device
because it might want to drive them. If we keep them registered even
after failing a probe, then /sys/devices/platform turns into an
enumeration of the drivers we loaded, not a view of what's present in
the system.
(and there is no point in keeping the driver loaded when we don't keep
the devices registered as well -- you couldn't do anything with that
driver, it would just be sitting there taking up memory)
Problem therefore: /sys/devices pollution. Note that ALSA supports some
20 (non-pnp-only) ISA drivers and imagine loading them all, with all of
them creating one or more devices in /sys/devices/platform, with none of
the actual hardware present. I consider this not nice, not from the view
of ALSA, but because I've been told that one of the reasons for /sys was
this nice view of "what's in this system" that /sys/devices would provide.
The answer needed -- if you _do_ think it's okay to just have those
devices present in /sys/devices/platform without the hardware existing,
then I do not have a problem. I'll just suggest to keep them registered
and be done with it (*).
If on the other hand you agree it's not nice, I'll try and look into
what a seperate isa_bus could provide.
Rene.
(*) Note by the way I do not necesarily qualify as an ALSA person. I
only ran into this when I submitted a new ALSA ISA driver for 2.6.16+.
Takashi Iwai is being CCed on all these messages though, and he hasn't
yet protested anything I've been saying, so I assume he's okay with my
worries at least...
next prev parent reply other threads:[~2006-04-13 23:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 1:46 [ALSA STABLE 3/3] a few more -- unregister platform device again if probe was unsuccessful Rene Herman
2006-04-13 9:26 ` Ingo Oeser
2006-04-13 9:31 ` Russell King
2006-04-13 14:05 ` Rene Herman
2006-04-13 14:57 ` Russell King
2006-04-13 16:17 ` Rene Herman
2006-04-13 17:05 ` Russell King
2006-04-13 18:47 ` Rene Herman
2006-04-13 22:02 ` Greg KH
2006-04-13 23:12 ` Rene Herman [this message]
2006-04-15 13:16 ` 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=443EDAD1.8090406@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=alsa-devel@alsa-project.org \
--cc=gregkh@suse.de \
--cc=ioe-lkml@rameria.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/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