lkml.org 
[lkml]   [2008]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MMIO and gcc re-ordering issue


On Mon, 2 Jun 2008, Haavard Skinnemoen wrote:
>
> > So what happened to the old idea of putting the accessor function pointers
> > in the device/bus structure?
>
> Don't know. I think it sounds like overkill to replace a simple load or
> store with an indirect function call.

Indeed. *Especially* as the driver in practice tends to always know which
one it is statically.

Yes, sometimes the same RTL may end up being used behind two differnt
buses, and with some broken byte-conversion hardware in the middle, but
that's pretty damn rare in the end. It happens, but it happens mostly with
the odd broken kind of embedded setups where somebody took a standard part
and then did something _strange_ to it - and in the process they may well
have introduced other issues as well.

I suspect you find this kind of thing mostly with things like stupid
integrated IDE controllers, and things like byte order tends to be the
_least_ of the issues (specialized register accesses with odd offsets etc
will happen).

So most of the time the byte order is simply decided by the hardware
itself (and LE is the common one, due to ISA/PCI). Sometimes you can set
it dynamically (at which point it's irrelevant - just pick the one you
want).

So I definitely argue against complex IO accessor functions with things
like dynamic support for byte order depending on bus. 99.9% of all
hardware simply do not need them, and the small percentage that might need
it will need special drivers anyway, so they might as well do the
complexity on their own rather than make everybody else care.

See for example the input driver for the i8042 chip: not only do those
things sometimes need native order (probably exactly because it's
integrated on a chip over some special "native bus", or just wired up to
be big-endian on a BE platform by some moron), but you'll also find that
they just need odd accesses anyway exactly because it's oddly wired up
(eg it's some special serial protocol that emulates ISA accesses).

So having some "byte-order correcting function" still wouldn't make any
sense, because it's not just about byte order.

Will that mean that you might occasionally have a "normal" driver and an
"odd" driver that actually drives what is basically the same HW block,
just wired up differently? Sure. But that's still a smaller price to pay
than it would be to try to make everything be "generic" when there is no
point to it.

Linus


\
 
 \ /
  Last update: 2008-06-04 17:35    [W:0.162 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site