On Friday 27 April 2012 16:52:34 Arnd Bergmann wrote:
> On Friday 27 April 2012, H. Peter Anvin wrote:
> > On 04/27/2012 10:14 AM, Will Deacon wrote:
> > > If you remove the architecture-specific drivers, there's really not a
> > > lot left and, even then, we only need to convert those drivers which
> > > are intended to be portable between architectures where the string
> > > functions are not consistently available.
> > > 
> > > By overheads, I assume you're referring to the IO_COND check on the
> > > address space? I wouldn't expect this to be noticeable compared to the
> > > cost of the I/O access and I'm not sure it's worth worrying about for
> > > the sake of the small number of drivers affected.
> > 
> > It's not in time, but it adds bulk to the code.  The point is that what
> > is the benefit of not making these part of the general API?  For
> > architectures where the address space doesn't matter they could just
> > alias it to the same functions, or use the generic versions.
> 
> The main reasons I can see for not making it a general purpose API are:
> 
> * It's a very confusing interface, because the endianess rules are
> different from the non-string variants and counterintuitive.
> 
> * Almost all the users are ancient ARM specific drivers, the others are
>   either new ARM specific drivers or drivers that started out as ARM-only
>   and were ported later to other architectures (sh, avr32, mips, mn10300
>   and blackfin)
> 
> * On all these architectures, the PCI I/O space is memory mapped (or
>   non-existent), so the ioread* functions are trivial wrappers without
>   additional overhead.
> 
> * Most architectures don't implement them today, but all architectures
>   that support MMIO also implement the ioread string operations.

i'm ambivalent with keeping or tossing these funcs.  Blackfin (afaik) picked 
them up really only for the reasons Arnd cited -- drivers using memory mapped 
registers originally for ARM (or m68k/coldfire i think) used this API, and it 
was easier for us to implement these defines in our asm/io.h and get the 
drivers "for free".

i am strongly in favor though of agreeing on & documenting the baseline API 
first before attempting to clean anything up.  sorry to keep harping on this.
-mike