On Sun, 11 May 2014, Josh Triplett wrote: > > > > What if I attempt a four-byte read at 65535? That would access four > > > > out-of-bounds bytes, right? > > > > > > No, it would do an ind instruction on port 65535. > > > > Yes, on x86. What about other architectures? > > That's a good point; on architectures that map I/O to memory, this > device should check port+count rather than port. Is there a reliable > #define that identifies architectures with that property, other than > CONFIG_X86? FWIW, on x86 an IND from 65535 will be split into two separate bus read cycles, e.g. on a 32-bit data bus one at 0xfffc with only the MSB enabled and another one with the three LSB enabled (64-bit buses will address the first cycle at 0xfff8, etc.). Data obtained from these cycles is then merged appropriately before writing to the destination. The address put on the bus for the second cycle is implementation-specific as are all accesses beyond 0xffff so it might be 0x10000 or it might be 0. If implementing unaligned port I/O on non-x86 targets I think it would be most reasonable to wrap the out-of-range part around back to 0 before merging data obtained this way. The range supported can of course be different to what x86 supports and may be specific e.g. to the PCI host bridge (its port I/O space forwarding window size). Systems with peer bridges may have multiple port I/O spaces too, this is one reason to have the size of the port I/O space extended beyond 64kB; address bits from #16 up can then be used to select the intended host bridge to forward the access to. Also IIRC PCI-PCI bridges only forward port I/O space accesses within the low 64kB. Most easily unaligned port I/O may not be supported at all by our kernel device, even on x86. I think it would actually be reasonable to do, I have yet to hear of a piece of hardware that has any use for unaligned port I/O. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
