lkml.org 
[lkml]   [2006]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ALSA STABLE 3/3] a few more -- unregister platform device again if probe was unsuccessful
Russell King wrote:

> On Thu, Apr 13, 2006 at 06:17:49PM +0200, Rene Herman wrote:

>> Okay, thanks, that's relevant information. Please explain though
>> what's incorrect about the fact that for these ISA devices on the
>> plain old PC, with nothing other than the driver available to probe
>> for them, just keeping them registered after failing a probe turns
>> /sys/devices/platform into a view of "what drivers did we load".
>
> If a driver for an ISA device only wants to register a device and
> driver if the hardware exists, it needs to handle behaviour itself
> and not force such behaviour on the upper layers (which is what
> you're arguing for.)

Nono, please note I'm arguing for nothing of the sort. The original
patch to bus_add_device() to pass up the probe() return was submitted
with just a "if I do this, things work as I expect. is it correct?"
question attached. Given that everything uses that same code, it wasn't
correct. What I am arguing for is that it would be good if the driver
model provided me the _option_ to fail a registration if the driver
tells it there are no devices. ie, the flag that I could set that would
make the driver model interpret an ENODEV from probe() to really mean NODEV.

The current work-around of using drvdata() as a success flag is exactly
what you say -- ALSA doing it all by itself. This thread specifically
only started due to Ingo Oeser suggesting that work-around would go into
platform_device_register_simple()...

>> M'kay. I believe there's one clean way out of this. We could add an "isa
>> bus", where the _user_ would first need to setup the hardware from
>> userspace by echoing values into sysfs. Say, something like:
>
> Maybe this is the best solution for ISA devices - they do appear to
> have differing semantics at the probe level from platform devices.
> Maybe this "discovery" should be part of the bus matching method, prior
> to the driver probe method being called? With an ISA bus type, you can
> certainly arrange for that to happen without changing existing driver
> model behaviour.

I can try and see if I can come up with something sensible I guess. Will
need time though...

Takashi: anyways, these patches are good to go. Already saw the ISA
driver ones present in 1.0.11-rc5. I by the way do not see them in the
ALSA CVS at http://cvs.sourceforge.net/viewcvs.py/alsa/. How's that?

Rene.

-
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/

\
 
 \ /
  Last update: 2006-04-13 20:47    [W:0.657 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site