On Thu, Feb 02, 2006 at 07:37:01AM -0700, Matt Porter wrote:
> I mentioned the BE iomap variants that are being used on some non-pci
> parisc devices already. I'll give a partial example of something that
> is non-pci yet "arch-independent".
>
> Take a non-pci EHCI core (yes, I know it's little endian by definition
> but suspend reality for a second). You can create an arch-independent
> EHCI driver that uses the platform bus by using the iomap accessors.
> Since these cores are licensed every day by XYZ startups for their
> latest "gee-whiz" SoC, it reasons that you'll see the same core on
> multiple licensable SoC architectures. I've seen one such thing
> on MIPS.
>
> We also know that major semiconductor companies do the same thing
> for their peripherals in some cases. They're just as willing to
> buy somebody else's USB core, for example. So, having a BE
> non-pci device cross platform isn't a stretch.
>
> Take a look at drivers/scsi/53c700.{c,h}. That generic driver
> is why BE iomap accessors were added. It's in the process of
> being shared between parisc and m68k.
>
Matt, my problem with this approach is that it repeats the same
old mistakes but in "BE-mode", e.g. _assuming_ some access mode and
hard-coding it into the driver. I fail to see how assuming big-endian
is any better than assuming little-endian in this case. And this is
not _portable_ in my book, no matter what some people want me to
believe.
This fails miserably when for example you have a bus which does byte
swaps in every half-word. And yes, I have such device on my table and
I have to port PCMCIA/PCI drivers to this SoC :).
Here is how inb looks like:
static inline u8 fpi_inb(unsigned long port)
{
port ^= 1;
return inb(port);
}
IMO, truly portable and driver independent I/O accessors should be
implemented as a function pointers on per-bus (at least) basis which
can be overridden by arch or board code. In this case we can get rid
of "ugly" ifdefs in driver code :).
--
Eugene
