Wrong. They are.
If somebody has a system with both sbus and PCI, he'd better create the
sbus version of the resources.
That wasn't how it used to be, but that is how it is now.
> I'd also disagree with your logic, because there is one
> set of resources from the perspective of hardware (i.e., a tree that
> represents how transactions are propagated after they leave the CPU),
> and one from the perspective of software (i.e., a tree describing how
> drivers interact with regions of CPU address space). The two can
> largely be superimposed, but you're representing two fundamentally
> different kinds of information.
No. There is one kind of resource - the one from the perspective of a
driver. Anything else is irrelevant.
The Linux way of accessing PCI is though inb/outb() and readb/writeb()
interfaces. The "pci_io_resource" and "pci_mem_resource" protect those
interfaces, and nothing else. There's a well-defined 1:1 mapping, and NO
confusion between the two. (Well, there's some limited confusion because
of the "ioremap()" interface, and to make things clear I should mention
that the pci memory resource is the area BEFORE the remapping - the
remapped values are only to be seen as a "window" into the real resource).
I certainly agree that the Linux way of looking at the PCI resources is
not the only way. Some people want to change it so that it's not a flat
32-bit resource any more - with different PCI buses showing up explicitly.
I personally disagree about the complexity, but I see why people might
like that.
IF we ever do that, then the PCI resources will be split up to be per-bus
resources, but I don't see that happening in the near future.
> To give one example (there must be others), for some PCMCIA devices,
> the PCMCIA bus driver constructs an IO region by concatenating several
> bridge IO windows with different functional properties. From the
> hardware perspective, there are several IO resources in play:
Irrelevant. You access it with a well-defined and simple flat address
space, and that is the only one that actually matters to a driver.
If you have code that reliably fully enumerates the hardware, then we'll
look at that code and start changing drivers. Backwards compatibility is
evil if it results in things that do not make sense.
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/