[lkml]   [2006]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 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:
    > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-13 18:18    [W:0.025 / U:2.628 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site