Re: [PATCH v8 1/9] mfd: madera: Add register definitions for Cirrus Logic Madera codecs

[Richard Fitzgerald]

On 26/02/18 13:46, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 3:05 PM, Richard Fitzgerald
> <rf@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > This patch adds a header file of register definitions for Cirrus
> > Logic "Madera" class codecs. These codecs are all based off a common
> > set of hardware IP so have a common register map (with a few minor
> > device-to-device variations).
> >
> > The registers.h file is tool-generated directly from the hardware design
> > but has been manually stripped down to reduce size (full register
> > map is >44000 lines). All names are kept the same as datasheet names
> > so that they can be cross-referenced between source and datasheet without
> > confusion.
> >
> > The register map layout is kept fully-defined rather than factored into
> > macros and/or block-indexing code. The major reasons for this are:
> >
> >   - #1 is that it makes the source highly greppable, which is important.
> >     "What does the driver do with register bits XYZ" or "Where does it use
> >     register bits XYZ" are commonly types of questions. These can be quickly
> >     answered by a grep. Squashing definitions into generator macros or block-
> >     indexing code is a way of defeating grep.
> >
> >   - most of the register definitions are used in tables, so a constant value
> >     is required. Using generator macros make the table definition clunky and
> >     obscure.
> >
> >   - the code is clearer when it's there in the source exactly what register
> >     and field it is using
> >
> >   - it is easier to diff the register map of a new (unsupported) codec against
> >     what is already supported and merge in differences
> >
> >   - it makes the register map available in source for maintenance/debugging
> >     instead of having to refer back to the datasheet for a register map
>
> ...
>
> > +#define MADERA_OTP_HPDET_GRADIENT_1X_MASK          0x0000FF00
>
> > +#define MADERA_OTP_HPDET_GRADIENT_0X_MASK          0x000000FF
>
> GENMASK() for all masks?

I'm an un-fan of GENMASK(). It seems to me to make it less readable.
Unless it's important I'd rather leave the masks as they are because
this is all auto-generated from the hardware design. Also keeping it
in plain form like this makes it easier for people converting
settings from the output of codec tuning tools.