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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: puc(4) man page update?
    ... bunch of bus attachments you don't want. ... ISA devices enumerated by ACPI on acpi0, but instead of an ACPI- aware ISA bus ... but excludes the isabus driver. ...
    (freebsd-current)
  • mse reorg
    ... I've reorganized the mse driver. ... I've split it up into cbus and isa ... bus front ends, and a core back end and moved it to dev/mse. ... both isa and cbus is flawed, ...
    (freebsd-hackers)
  • Re: PC104 Bus support
    ... PC/104 is generally not 'enumerated' in the same way PCI is; it's just ISA ... You'll need a driver of some sort for your A/D card, but, assuming it's not ... > If I have a PC104 bus on my CEPC, do I need a driver to support it? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Simple ADS5273 -> Xilinx Interconnect Model
    ... Is the ADS5273 a non-standard LVDS "style" of driver? ... If there are excessive reflections from the ... reduced-amplitude probe point. ...
    (comp.arch.fpga)
  • Re: patch bus_add_device-losing-an-error-return-from-the-probe-metho
    ... How do you feel about the flag that I've been proposing that a driver that needs to probe for its hardware could set and that says "if we return an error the hardware's reallyreally not present and the device should not register"? ... adding a .discover method to struct device_driver that noone other than drivers for this old non generically discoverable hardware would set but which would make a registration fail if set and returning < 0? ... struct snd_card *card; ...
    (Linux-Kernel)