On Sat, Apr 28, 2012 at 12:26:11AM +0100, Mike Frysinger wrote:
> On Friday 27 April 2012 16:52:34 Arnd Bergmann wrote:
> > 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".
Makes sense and there's no compelling reason to convert drivers if they're
not being used by architectures without these functions.
> 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.
It would be nice if we could just use asm-generic/io.h as the documention,
i.e. if you want to write a portable driver, just stick to the functions
implemented there. Apart from the string accessors, I think it's already
fairly accurate. The __raw_* functions seem to be missing on s390 but I
don't think driver portability is a huge concern for that architecture.
Will
On Tuesday 01 May 2012, Will Deacon wrote:
> It would be nice if we could just use asm-generic/io.h as the documention,
> i.e. if you want to write a portable driver, just stick to the functions
> implemented there. Apart from the string accessors, I think it's already
> fairly accurate. The __raw_* functions seem to be missing on s390 but I
> don't think driver portability is a huge concern for that architecture.
Actually, s390 has none of the mmio accessors right now, because there
is no PCI or other memory mapped hardware.
Arnd
On Tuesday 01 May 2012 09:34:29 Will Deacon wrote:
> On Sat, Apr 28, 2012 at 12:26:11AM +0100, Mike Frysinger wrote:
> > 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.
>
> It would be nice if we could just use asm-generic/io.h as the documention,
> i.e. if you want to write a portable driver, just stick to the functions
> implemented there.
we have Documentation/DocBook/deviceiobook.tmpl where we can document what
should be used in device drivers for portability, and what should be avoided.
then we can refer to asm-generic/io.h for just the API level stuff (i.e.
inputs/outputs/return values).
then we update asm-generic/io.h to:
- refer device driver authors to deviceiobook for the higher level
documentation
- explicitly state that the API here is the baseline and any new functions
should be discussed first on linux-arch/lkml
- explicitly state what API functions have been omitted, and what should be
used instead of those
how's that sound as a plan ?
> It would be nice if we could just use asm-generic/io.h as the documention,
> i.e. if you want to write a portable driver, just stick to the functions
> implemented there. Apart from the string accessors, I think it's already
> fairly accurate. The __raw_* functions seem to be missing on s390 but I
> don't think driver portability is a huge concern for that architecture.
as long as we document expectations at the top of the file, that's fine. this
implicit assumption doesn't fly in general for asm-generic/ because it's been a
constantly increasing code base as it merges more arches. there were a bunch
of files/apis i extended in asm-generic/ as i converted Blackfin over to it.
this is what we wanted from the beginning (afaik; i'm sure Arnd can correct
me).
-mike