Re: [PATCH] add delay between port write and port read
From: Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx)
Date: Fri Mar 01 2019 - 19:09:24 EST
On Fri, Mar 1, 2019 at 1:52 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> Without that, using __raw_xyz() to copy between RAM and
> buffers in PCI memory space is broken, as you said, but the
> assumption would be broken on certain older machines that
> do a hardware endian swap by swizzling the address lines rather
> than swapping bytes on the data bus.
Honestly, there's no way we can ever fix that.
The fact is, __raw_readl/writel simply isn't portable. If a driver
uses them, the driver HAS TO KNOW what the situation is on the
hardware it runs on.
Because the "byte order" of the end result will basically be random on
And you know what? We absolutely do not care. Not one whit.
Because no new CPU's will ever be designed where the byte order isn't
little-endian, and nobody will ever make those broken "we'll do random
things in hardware to worfk around the fact that we're doing crazy
So it's all legacy anyway, and it's absolutely not worth
over-designing or over-thinking this issue.
If you have a random SoC that does insane things, that random SoC may
(a) need its own drivers that know exactly how it works
(b) not be able to use some drivers for IP that the SoC has, but the
SoC designers screwed up and did some random crazy byte lane swizzling
and that's all perfectly fine. We don't care. That SoC gets to do its
And 99% of truly generic drivers won't have any of these issues,
because they don't use __raw_readl/writel to begin with.
So don't make this any stranger than it is. Just accept that by
design, and by definition, __raw_readl/writel is a bit non-portable,
and won't work for everything.
The corollary of that is that __raw_readl/writel() may also then be
used _for_ that mis-designed piece of garbage SoC to implement the
special driver needed for just that SoC.
But as mentioned, this simply isn't a problem in practice. Sure,
people can do insane things if they really want to. Maybe some "stable
genius" decides to do a big-endian RISC-V core. We don't care, and we
don't make everybody else have to worry about that kind of insanity.