Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

[Arnd Bergmann]

On Thursday 07 February 2013, Grant Likely wrote:
> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin

> Starting with register (non-data) access. The bus bindings are such
> that on both BE and LE systems a native 16 bit read results in the
> bits being in the correct order. On powerpc, you want to do a BE read
> because the device appears as a BE device, and on LE systems a LE read
> is wanted because that is how the device is wired. So far this makes
> sense and matches the driver.

Well, until you get a little-endian PowerPC system with this
device ;). I heard people are plannng to put those into
production systems. I would assume that the device would
still use big-endian registers, so the rule about PowerPC
using the BE accessors still holds, but it stops making
sense.

> The same is true for the data port. A BE read does the right thing on
> a BE platform, and LE read on a LE platform. (again, this is all about
> bus attachment). However, the difference is what is then done with the
> data.

Well, except that we cannot use the ioread16be_rep function,
which is made for the case where the bus does not swap.

Of course, as long as the driver is only ever used to access
the same non-removable block device and you don't change
the driver, it does not matter at all whether you swap bytes
on the data port or not, because they are swapped on both
read and write, and it's just storage. Only if you try to
read the device with a "correct" driver, you will see a problem
if it was written with a "wrong" driver.

> The ironic thing is that if the BE PPC/MB hardware engineers hadn't
> swapped the bytelanes then we would *still* have to do special thinks
> in the hardware; except it would be the data port accesses that would
> need extra work, instead of the other registers.

No, we would juse use the _rep() functions if they had done it right,
just like any other driver with this problem.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/