Thread (56 messages) flat view 56 messages, 6 authors, 2012-08-22

Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations

From: Ben Hutchings <hidden>
Date: 2012-08-22 17:27:30

On Wed, 2012-08-22 at 10:12 -0700, H. Peter Anvin wrote:
On 08/22/2012 10:09 AM, Ben Hutchings wrote:
quoted
Well, sure, I'm assuming that the driver is responsible for checking
that the device and its bus interface support an MMIO of the requested
width.

But the architecture code must be responsible for reporting whether the
host supports it, right?
No, the architecture code *can't*.
So, let me check that I understand this right:
- To support 32-bit architectures, a driver should include one of two
different definitions of readq/writeq depending on which order the
device needs to receive 32-bit operations.
- On 64-bit architectures (or at least x86_64), the system might split
up readq/writeq into 32-bit operations in unspecified order, and the
driver can't control this.

If this is right, how can it be safe to use readq/writeq at all?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help