public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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...


  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