[coreboot] Unifying IO accessor macros

[Julius Werner]

> I think nobody disagrees that type checking is a bad idea here.

I ain't not unsure that you failed to not make no mistake with the
missing lack of double negatives there... ;)

> I don't think this argument makes sense for code that is being actively
> developed in other code bases and imported into coreboot. Of course, if
> you're importing stable code and don't expect much churn, tidying things up
> is a fine idea. But increasing deltas while a project is still under active
> development only serves to make integration and maintenance efforts more
> troublesome and prone to error. It's not a productive use of anyone's time
> when there are real bugs to solve.
>
> Vendors often have code which they have already qualified and are
> understandably reluctant to make any changes to it, even trivial aesthetic
> ones. I'd like to make it easier for them to contribute directly to
> coreboot, and throwing up artificial barriers does not help them gain
> traction.

Do we really want to facilitate more of these wholesale imports of
untouched, existing code dumps from other sources into coreboot? It
seems to me that those always end up bad for us... code is hard to
read and follow because of switched conventions, it could have
depended on different requirements for the environment than what
coreboot provides, it often includes a lot of hacky and
overcomplicated code that the original use case might have needed but
we don't, people will end up making changes after the import that
desync it with the source, etc. I think for small stuff like
individual drivers we're better off just rewriting them with a sound
design from the ground up tailored to our use case (at least that
guarantees that someone really understood and thought through how it
all works within the coreboot context). How often have we pulled in
updates for something like that anyway? For really large scale
external imports (like AMD Agesa), we can stow it away in vendorcode/
with translator headers to allow it to keep its own conventions
completely unchanged, without risk of it leaking out into the rest of
coreboot.