[U-Boot] [PATCH v9 12/16] regmap: Add endianness support

[Mario Six]

Hi Simon,
On Tue, Oct 2, 2018 at 1:21 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Mario,
>
> On 28 September 2018 at 00:27, Mario Six <mario.six at 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 at 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