finally fix 53c700 to use the generic iomem infrastructure

This driver has had it's own different infrastructure for doing this for ages, but it's time it used the common one.

My thought on this is that we should encode the endianness of the registers in the ioremap cookie. Some architectures (sparc, I think?) can do this in their PTEs. The rest of us can do it in our ioread/writeN methods. I've planned for this in the parisc iomap implementation but not actually implemented it.

Quoted 5 lines

My thought on this is that we should encode the endianness of the registers in the ioremap cookie. Some architectures (sparc, I think?) can do this in their PTEs. The rest of us can do it in our ioread/writeN methods. I've planned for this in the parisc iomap implementation but not actually implemented it.

SPARC64 can do it in the PTEs, but we just use raw physical addresses in our I/O accessors, and in those load/store instructions we can specify the endianness.

Be careful though. Endianness can be dealt with on a hardware level. Consider a byte access to a 32-bit word sized config space datum, the PCI controller on a big-endian system will likely byte-twist the data lanes in order for this to work properly.

Quoted 3 lines

SPARC64 can do it in the PTEs, but we just use raw physical addresses in our I/O accessors, and in those load/store instructions we can specify the endianness.

Ah right. So you'd prefer an ioread8be() interface?

After all, the driver must know the card is BE, so the routines that make use of the feature are easily coded into the card, so there's no real need to add it to the iomem cookie.

Did anyone have a preference for the API? I was thinking ioread32_native, but ioread32be is fine too.

Quoted 2 lines

Did anyone have a preference for the API? I was thinking ioread32_native, but ioread32be is fine too.

I think doing foo{be,le}{8,16,32}() would be consistent with our byteorder.h interface names.

Quoted 5 lines · David S. Miller

Quoted 2 lines

Did anyone have a preference for the API? I was thinking ioread32_native, but ioread32be is fine too.

I think doing foo{be,le}{8,16,32}() would be consistent with our byteorder.h interface names.

Thinking about this some more, I know of no case of a BE bus connected to a LE system, nor do I think anyone would ever create such a beast, so our only missing interface is for a BE bus on a BE system.

Thus, I think io{read,write}{16,32}_native are better interfaces ...

they basically mean pass memory operations without byte swaps, so they're well defined on both BE and LE systems and correspond exactly to our existing _raw_{read,write}{w,l} calls (principle of least surprise).

I disagree. The driver will never "know" ...

I don't think it's sane. You know that your device is BE or LE and use the appropriate interface. "native" doesn't make sense to me in this context.

Well ... it's like this. Native means "pass through without swapping" and has an easy implementation on both BE and LE platforms. Logically io{read,write}{16,32}be would have to do byte swaps on LE platforms. Being lazy, I'm opposed to doing the work if there's no actual use for it, so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

The IOC4 device that provides IDE, serial ports and external interrupts on Altix systems has a big endian register layour, and the PCI-X bridge in those Altix systems can do the swapping if a special bit is set.

In older kernels that bit was set from the driver through a special API, but it seems the firmware does that automatically now.

Quoted 4 lines · Christoph Hellwig

The IOC4 device that provides IDE, serial ports and external interrupts on Altix systems has a big endian register layour, and the PCI-X bridge in those Altix systems can do the swapping if a special bit is set.

Quoted 2 lines

In older kernels that bit was set from the driver through a special API, but it seems the firmware does that automatically now.

We already have some unusual code in drivers to support other altix design ... features ... do you regard this as something that's likely to be replicated on other platforms, or is it more in the category of a one off mistake that can be corrected in firmware?

Quoted 1 line · Benjamin Herrenschmidt

I disagree. The driver will never "know" ...

? the driver has to know. Look at the 53c700 to see exactly how awful it is. This beast has byte and word registers. When used BE, all the byte registers alter their position (to both inb and readb).

Quoted 3 lines

I don't think it's sane. You know that your device is BE or LE and use the appropriate interface. "native" doesn't make sense to me in this context.

Well ... it's like this. Native means "pass through without swapping" and has an easy implementation on both BE and LE platforms. Logically io{read,write}{16,32}be would have to do byte swaps on LE platforms. Being lazy, I'm opposed to doing the work if there's no actual use for it, so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

Quoted 7 lines

Well ... it's like this. Native means "pass through without swapping" and has an easy implementation on both BE and LE platforms. Logically io{read,write}{16,32}be would have to do byte swaps on LE platforms. Being lazy, I'm opposed to doing the work if there's no actual use for it, so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

I would probably spell "native" as "noswap". "native" just doesn't convey enough specific meaning...

so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

Quoted 2 lines · James Bottomley

so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

The Network Processing Engines in the Intel IXP425 are big-endian and its XScale core may be run in little-endian mode. There's a bunch of gotchas related to running in little-endian mode so you typically run the IXP425 in big-endian mode, though.

David Vrabel

Signature · 4 lines

David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

But the Linux interface (on the CPU side of the PCI bus interface) doesn't care about the implimentation details in the XScale Core. That's why it's a complete subsystem, isolated from the ix86 by the PCI/Bus interface.

The Network Processing Engines in the Intel IXP425 are big-endian and its XScale core may be run in little-endian mode. There's a bunch of gotchas related to running in little-endian mode so you typically run the IXP425 in big-endian mode, though.

Quoted 4 lines · David Vrabel

The Network Processing Engines in the Intel IXP425 are big-endian and its XScale core may be run in little-endian mode. There's a bunch of gotchas related to running in little-endian mode so you typically run the IXP425 in big-endian mode, though.

Yes, based on feedback from Mips people and others pointing out the existence of the motorola rapidio bus, which is BE, I give in and agree that the io{read,write}{16,32}be are the way to go.

How does the attached look?

Quoted 1 line · Benjamin Herrenschmidt

I disagree. The driver will never "know" ...

? the driver has to know. Look at the 53c700 to see exactly how awful it is. This beast has byte and word registers. When used BE, all the byte registers alter their position (to both inb and readb).

Quoted 3 lines

I don't think it's sane. You know that your device is BE or LE and use the appropriate interface. "native" doesn't make sense to me in this context.

Well ... it's like this. Native means "pass through without swapping" and has an easy implementation on both BE and LE platforms. Logically io{read,write}{16,32}be would have to do byte swaps on LE platforms. Being lazy, I'm opposed to doing the work if there's no actual use for it, so can you provide an example of a BE bus (or device) used on a LE platform that would actually benefit from this abstraction?

Actually, ioread8be is unnecessary, but I was planning to add ioread16/ioread32 and iowritexx be on be variants (equivalent to _raw_readw et al.)

After all, the driver must know the card is BE, so the routines that make use of the feature are easily coded into the card, so there's no real need to add it to the iomem cookie.

Did anyone have a preference for the API? I was thinking ioread32_native, but ioread32be is fine too.

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines

SPARC64 can do it in the PTEs, but we just use raw physical addresses in our I/O accessors, and in those load/store instructions we can specify the endianness.

Ah right. So you'd prefer an ioread8be() interface?

Actually, ioread8be is unnecessary, but I was planning to add ioread16/ioread32 and iowritexx be on be variants (equivalent to _raw_readw et al.)

Not so. There are two different styles of big endian. (Lets just face it, BE is fucked in the head anyway...)

physical bus: 31...24 23...16 15...8 7...0

BE version 1 (word invariant)
byte access byte 0 byte 1 byte 2 byte 3
word access 31-24 23-16 15-8 7-0

BE version 2 (byte invariant)
byte access byte 3 byte 2 byte 1 byte 0
word access 7-0 15-8 23-16 31-24

And guess which architecture implements *both* of these... Grumble.

Quoted 9 lines · Russell King

Not so. There are two different styles of big endian. (Lets just face it, BE is fucked in the head anyway...)

physical bus: 31...24 23...16 15...8 7...0

BE version 1 (word invariant)
byte access byte 0 byte 1 byte 2 byte 3
word access 31-24 23-16 15-8 7-0

Quoted 3 lines

BE version 2 (byte invariant)
byte access byte 3 byte 2 byte 1 byte 0
word access 7-0 15-8 23-16 31-24

These are just representations of the same thing. However, I did deliberately elect not to try to solve this problem in the accessors. I know all about the register relayout, because 53c700 has to do that on parisc.

Quoted 10 lines

Quoted 9 lines

physical bus: 31...24 23...16 15...8 7...0

BE version 1 (word invariant)
byte access byte 0 byte 1 byte 2 byte 3
word access 31-24 23-16 15-8 7-0

BE version 2 (byte invariant)
byte access byte 3 byte 2 byte 1 byte 0
word access 7-0 15-8 23-16 31-24

Quoted 4 lines

These are just representations of the same thing. However, I did deliberately elect not to try to solve this problem in the accessors. I know all about the register relayout, because 53c700 has to do that on parisc.

They aren't. On some of our platforms, we have to exclusive-or the address for byte accesses with 3 to convert to the right endian-ness.

Sure, from the point of view of which byte each byte of a word represents, it's true that they're indentical. But as far as the hardware is concerned, they're definitely different.

OK, I sent the patch off to Andrew. To complete the original problem, the attached is the patch that uses it in the parisc lasi driver (although, actually, it sets up 53c700 to work everywhere including BE on a LE system).

I changed some of the flags around to reflect the fact that we now have generic BE support in the driver (rather than the more limited force_le_on_be flag).

What I really don't like is that you still need ifdefs and wrappers to support BE and LE wired chips in the same driver. Shouldn't you set the BE or LE flag at iomap() time and always use the same accessors?