>Its cute but if you think harder the implementation would suck
>
>> right thing" for that bus. One could add "bigendian_writel()" and
>> "littleendian_writel()" to satisfy the Linus constraint of making
>> unusual usage of writel() obvious.
>
>So every I/O has an if in it. Nothing like stalling the pipeline before we
>probably stall on I/O writes to make things twice as painful.
And what about simply having a struct io_bus containing function pointers
to read/write and ioremap routines ? This way, we could hide all the i/o
range offset issues when using several busses (we do have such problems
with the ppc, especially with IDE, see recent discussion of linuxppc-dev
mailing list). Each driver would have an bus structure associated with
the device, eventually provided by the resource tree, and the only
overhead of i/os could be the indirect function call.
For the endian issue (which I think is a non-issue) , most of the time,
the endian is known at compile time and could get be resolved by macros.
If it's not the case, then just add two sets of i/o function pointers in
the bus structure.
Also, each bus stucture (let's call this a bus driver) can have it's own
alloc/dealloc range functions associated, and eventually generic
notifiers for hotswap.
I beleive we can build some kind of "device-tree" which would be made of
a virtual root, containing busses, containing resources trees. Looks a
bit like Open Firmware ;-)
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
-
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/