On 25/02/2016 15:24, Peter Maydell wrote:
> Probably what happened
> was that when the API was being designed it started off with an
> 'unaligned' field, and then later the field name and semantics
> were changed but the docs weren't updated to match. My point was
> that just changing the name without looking at the behaviour we're
> actually implementing isn't correct.
Peter, are you okay with adding your S-o-b and authorship to
this patch?
I'll add a Reported-by for Cao jin, too.
Paolo
diff --git a/docs/memory.txt b/docs/memory.txt
index d0aca05..e44d081 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -297,8 +297,9 @@ various constraints can be supplied to control how these
callbacks are called:
- .valid.min_access_size, .valid.max_access_size define the access sizes
(in bytes) which the device accepts; accesses outside this range will
have device and bus specific behaviour (ignored, or machine check)
- - .valid.aligned specifies that the device only accepts naturally aligned
- accesses. Unaligned accesses invoke device and bus specific behaviour.
+ - .valid.unaligned specifies that the *device being modelled* supports
+ unaligned accesses; if false, unaligned accesses will invoke the
+ appropriate bus or CPU specific behaviour.
- .impl.min_access_size, .impl.max_access_size define the access sizes
(in bytes) supported by the *implementation*; other access sizes will be
emulated using the ones available. For example a 4-byte write will be
@@ -307,4 +308,4 @@ various constraints can be supplied to control how these
callbacks are called:
accesses; if false, unaligned accesses will be emulated by two aligned
accesses.
- .old_mmio can be used to ease porting from code using
- cpu_register_io_memory(). It should not be used in new code.
+ cpu_register_io_memory() and the like. It should not be used in new code.
