Messages in this thread | | | Date | Thu, 13 Apr 2006 20:47:14 +0200 | From | Rene Herman <> | Subject | Re: [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/
| |