1. 18 12月, 2017 1 次提交
    • A
      Add primitives for manipulating bitfields both in host- and fixed-endian. · 00b0c9b8
      Al Viro 提交于
      The following primitives are defined in linux/bitfield.h:
      
      * u32 le32_get_bits(__le32 val, u32 field) extracts the contents of the
        bitfield specified by @field in little-endian 32bit object @val and
        converts it to host-endian.
      
      * void le32p_replace_bits(__le32 *p, u32 v, u32 field) replaces
        the contents of the bitfield specified by @field in little-endian
        32bit object pointed to by @p with the value of @v.  New value is
        given in host-endian and stored as little-endian.
      
      * __le32 le32_replace_bits(__le32 old, u32 v, u32 field) is equivalent to
        ({__le32 tmp = old; le32p_replace_bits(&tmp, v, field); tmp;})
        In other words, instead of modifying an object in memory, it takes
        the initial value and returns the modified one.
      
      * __le32 le32_encode_bits(u32 v, u32 field) is equivalent to
        le32_replace_bits(0, v, field).  In other words, it returns a little-endian
        32bit object with the bitfield specified by @field containing the
        value of @v and all bits outside that bitfield being zero.
      
      Such set of helpers is defined for each of little-, big- and host-endian
      types; e.g. u64_get_bits(val, field) will return the contents of the bitfield
      specified by @field in host-endian 64bit object @val, etc.  Of course, for
      host-endian no conversion is involved.
      
      Fields to access are specified as GENMASK() values - an N-bit field
      starting at bit #M is encoded as GENMASK(M + N - 1, M).  Note that
      bit numbers refer to endianness of the object we are working with -
      e.g. GENMASK(11, 0) in __be16 refers to the second byte and the lower
      4 bits of the first byte.  In __le16 it would refer to the first byte
      and the lower 4 bits of the second byte, etc.
      
      Field specification must be a constant; __builtin_constant_p() doesn't
      have to be true for it, but compiler must be able to evaluate it at
      build time.  If it cannot or if the value does not encode any bitfield,
      the build will fail.
      
      If the value being stored in a bitfield is a constant that does not fit
      into that bitfield, a warning will be generated at compile time.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      00b0c9b8
  2. 18 11月, 2017 1 次提交
  3. 04 10月, 2017 1 次提交
  4. 11 2月, 2017 1 次提交
  5. 09 9月, 2016 1 次提交
    • J
      add basic register-field manipulation macros · 3e9b3112
      Jakub Kicinski 提交于
      Common approach to accessing register fields is to define
      structures or sets of macros containing mask and shift pair.
      Operations on the register are then performed as follows:
      
       field = (reg >> shift) & mask;
      
       reg &= ~(mask << shift);
       reg |= (field & mask) << shift;
      
      Defining shift and mask separately is tedious.  Ivo van Doorn
      came up with an idea of computing them at compilation time
      based on a single shifted mask (later refined by Felix) which
      can be used like this:
      
       #define REG_FIELD 0x000ff000
      
       field = FIELD_GET(REG_FIELD, reg);
      
       reg &= ~REG_FIELD;
       reg |= FIELD_PREP(REG_FIELD, field);
      
      FIELD_{GET,PREP} macros take care of finding out what the
      appropriate shift is based on compilation time ffs operation.
      
      GENMASK can be used to define registers (which is usually
      less error-prone and easier to match with datasheets).
      
      This approach is the most convenient I've seen so to limit code
      multiplication let's move the macros to a global header file.
      Attempts to use static inlines instead of macros failed due
      to false positive triggering of BUILD_BUG_ON()s, especially with
      GCC < 6.0.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDinan Gunawardena <dinan.gunawardena@netronome.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      3e9b3112