Re: ioremap return type

[Jamie Lokier]

David S. Miller wrote:
> 1) It is returned from ioremap()
> 2) It can be passed to iounmap()
> 3) It can be passed to {read,write,in,out}{b,w,l}() with an optional
>    byte offset added to it.
> 
> Otherwise, the thing is to be completely opaque.  If you expose the
> "sane type" underneath, driver developers will never get this right.
> 
> You can document the three points I made above in 100 different
> places, driver authors are still going to get it wrong unless you make
> it such that their driver does not compile unless they follow the
> rules above.  See?
> 
> This is why the typedefs are necessary to solve the problem properly.

Unfortunately a typedef alone won't even issue a warning for code which
uses the "sane type" directly.

IMO nice would be a really opaque cookie, s.t. readl is passed the
cookie _and_ offset.  That also leaves the way open for lots of
different implementation methods for readl et al., including debugging
checks, range and I/O tracing.  (E.g. I've seen drivers access ports
outside their allocated range, due to typos).

Many drivers use a struct to define the offsets in their I/O or iomem
space.  E.g. acenic.c: readl(&regs->CpuCtrl).  We know that's not
portable in the sense that struct layout is not guaranteed.  However,
provided all the fields are suitably padded & aligned, it works in
practice.  (So far..)

Those drivers will compile with the simplest void * -> unsigned long
change, but it will be lots of work to get rid of all the warnings.

-- Jamie