Messages in this thread | | | Date | Thu, 15 Jul 1999 15:42:52 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New kernel/resource.c |
| |
On Thu, 15 Jul 1999, David Hinds wrote: > > The names "pci_io_resource" and "pci_mem_resource" should really be > changed to be non-bus-specific, because they are not just PCI > resources.
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/
| |