[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New resources - pls, explain :-(

    [I was out of town for a week, hence the delay]

    > I want to have a common driver interface, at least conceptually.

    > And while you don't seem to believe it, there are buses where you CANNOT
    > initialize the device generically. It happens with PCI too, with devices
    > with extended registers etc,

    If `extended registers' == `hard-wired legacy ISA compatibility stuff',
    the driver must do everything manually since the generic code doesn't know
    about these ports at all. No enable_device function helps in this case.

    > but on other buses it is sometimes the _only_
    > way to do things.

    > So I want drivers to be conceptually
    > for_each_device() {
    > io = enable_device(); /* or whatever is approapriate */
    > .. run with it ..
    > }
    > because that is the kind of "common" ground for all different bus types.

    Okay, giving up :)

    The only remaining question is whether we want to have the driver enable
    each region separately or just call a single function which enables the
    whole device and allocates its regions. I would like the single function
    solution much more, but if you feel regions should be enabled/disabled
    separately, I can live with that.

    > I'm talking to the ISA PnP guy, and we'll try to get rid of "struct
    > pci_dev" completely - because most of the issues with PCI have similar
    > equivalents in ISA PnP. So there would be a "struct device" (except the
    > name has already been stolen by the networking layer, so..), which can ge
    > used in generic PC drivers, and then the only difference between PCI and
    > ISA PnP is going to be which function you use to find the device, and
    > which function you use to initialize it.

    > In short, this is not about just PCI. There are certainly many cases where
    > the same driver has PCI, ISA PnP, and old ISA interfaces - and the
    > _driver_ is often exactly the same with just small differences in how
    > cards are found and initialized.

    This is exactly what I have been speaking of during the last year, sent
    a couple of RFC mails to the kernel list and what you've rejected some
    weeks ago when I proposed a unification of devices.

    Can you CC this discussion to me, please?

    A brief summary of my previous ideas:

    Ad ISA PnP: The kernel should enumerate all ISA PnP devices and provide
    some interface for accessing PnP registers. All configuration of PnP
    devices should be done in user space, the kernel should just be
    notified about new devices having been configured and tell this to
    the drivers.

    Ad ISA: We can handle at least some ISA cards in a similar way -- again,
    they should have their device nodes created either by probing inside
    the drivers or explicitly by the user (who could say `there is a NE2000
    card at address 0x300 IRQ 7, handle it').

    To get this (and PCI hotplug) working, we need to be able to pass information
    about newly discovered devices to all drivers, preferably by each driver
    exporting a table of device ID's it's willing to handle along with a
    pointer to a function to call, similarly to the current init function

    Does this look reasonably? Should I write some more detailed description
    or some code?

    I'd also like to know your opinion on the PCI patches I've sent you a week
    ago -- please tell me what you'd like me to fix and I'll change it and update
    the whole thing to the most recent kernel.

    Have a nice fortnight
    Martin `MJ' Mares <>
    Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
    "Windows Error: 004 - Operator fell asleep while waiting."

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

     \ /
      Last update: 2005-03-22 13:53    [W:2.637 / U:0.776 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site