[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
system.
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 <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/