Messages in this thread | | | Date | Thu, 13 Apr 2006 18:17:49 +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 04:05:33PM +0200, Rene Herman wrote:
>> Not honouring/passing up probe() method error returns, not even -ENODEV, >> makes some sense for discoverable busses such as PCI where you at least >> have a driver independent bus_id sitting in /sys/devices/pci* that you >> can later echo into /sys/bus/pci/drivers/*/bind to make the driver bind >> to a device, but not much sense for the platform bus. Platform devices >> only "exist" (in /sys/devices/platform) due to the driver creating them >> itself and keeping them after failing a probe means that directory >> becomes an enumeration of the drivers we loaded, rather than a view of >> what's present in the system. > > Incorrect. In some circumstances, they may be created by architecture > support code, and might be created and destroyed dynamically by > architecture support code.
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".
>> The driver model crowd did not seem exceedingly interested in the >> problem though: >> >> http://marc.theaimsgroup.com/?l=linux-kernel&m=114417829014332&w=2 > > Incorrect summary. The ALSA use model of the driver model doesn't fit > with the driver model use model. It's not that we're not interested > in it - it's that it's perverted to the way driver model folk intend > the subsystem to work, and the way that platform devices are used on > some architectures.
And I take it that interest is reflected in getting a grand total of 0 comments from anyone on my own feeble attempts to suggest things in that thread such as the settable flag that would make the driver model pass up the error return from probe when set, or having an additional .discover method, or ..
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:
echo -n foo >/sys/devices/isa0/new echo -n "io 0x220" >/sys/devices/isa0/foo/resources echo -n "irq 5" >/sys/devices/isa0/foo/resources echo -n "dma 1" >/sys/devices/isa0/foo/resources
and so on. The type of resources would be modelled after ISA-PnP (and to make them more equal, you could do multiple device id's per bus id, card id's, in PNP lingo, but this principle at least)
The driver would them request id "foo" as an agreed upon ID (snd-sb8 would request "sb8", say) or we could pass in the id as a module parameter.
I actually think this would be Great. Comments? Pitchforks?
From the driver's standpoint, there would not be a difference with ISA-PnP anymore other than ISA-PnP also providing for the possibilty to change them -- something which ALSA also uses, but which it should probably not; has annoyed me for some time. We could then in fact also integrate this into ISA-PnP itself, using PnP-like device IDs and all, so that from the driver's standpoint, it _is_ always speaking to an ISA-PnP device.
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/
| |