Why?
We have IO regions, and that's really all the driver cares about. The
"struct pci_dev" is useful for device identification, but it is not the
device. The device is really the IO port accesses you make in the driver,
and as such it makes sense to just allocate those resources.
Marking the actual "struct pci_dev" busy buys you nothing over marking the
IO range busy, and as has been shown it has problems.
> > Think of PCI super-IO devices, for example.
>
> BTW have you ever seen such a chip? I never had...
Oh, they are there. They just don't announce their PCI IO ranges, exactly
because they implement legacy stuff that doesn't expect them to be
announced.
For example, take the PIIX4 which exists in probably 90% of modern PCI
machines. It has _tons_ of devices on it, and some are announced as PCI IO
regions while others are not. Even when it announces that it has a IDE
subfunction, it doesn't actually announce the IO range it listens on (it
announces the extended IO range, but not the traditional one).
Now, imagine that you have a modularized system, and you by mistake load a
PIIX4-aware IDE module after you already loaded a "classical" IDE module.
The PIIX4-aware IDE module _should_ notice that the IO range is already in
use, and should abort.
Your "let's mark the PCI device busy" approach does not take those very
reasonable concerns into account. In short, it's not a very good approach.
Face it, Martin.
Linus
-
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/