Hi Simon, On Tue, Oct 2, 2018 at 1:21 PM Simon Glass sjg@chromium.org wrote:
Hi Mario,
On 28 September 2018 at 00:27, Mario Six mario.six@gdsys.cc wrote:
Add support for switching the endianness of regmap accesses via the "little-endian", "big-endian", and "native-endian" boolean properties in the device tree.
The default endianness is native endianness.
Signed-off-by: Mario Six mario.six@gdsys.cc
v8 -> v9: New in v9
drivers/core/regmap.c | 130 ++++++++++++++++++++++++++++++++++++++++++++++---- include/regmap.h | 14 ++++++ 2 files changed, 136 insertions(+), 8 deletions(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c index 761dc535ed8..da2a1d0b883 100644 --- a/drivers/core/regmap.c +++ b/drivers/core/regmap.c
[...]
int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset, void *valp, size_t val_len) { @@ -210,17 +268,17 @@ int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset,
switch (val_len) { case REGMAP_SIZE_8:
*((u8 *)valp) = in_8((u8 *)ptr);
*((u8 *)valp) = __read_8(ptr, map->endianness);How come this is changing from in to read? They are not equivalent on x86. I think it should be using read, so this is correct, but I'm not sure why it what apparently previously changed to 'in'?
I never changed the v8-and-before version of the "regmap: Add raw read/write functions" patch, so it still had the in_* functions (since this place would replace them later anyway). But I don't mind changing that patch around in a v10 (like I said, for my use case is literally doesn't matter what's used).
Regards, Simon
Best regards, Mario