Re: [PATCH 3/3] iio: Add driver for Nicera D3-323-AA PIR sensor

[Waqar Hameed]

On Fri, May 16, 2025 at 19:16 +0200 Waqar Hameed <waqar.hameed@xxxxxxxx> wrote:

> On Sun, May 11, 2025 at 13:14 +0100 Jonathan Cameron <jic23@xxxxxxxxxx> wrote:

[...]

>>> +
>>> +/*
>>> + * Register bitmap.
>>> + * For some reason the first bit is denoted as F37 in the datasheet, the second
>>> + * as F38 and so on. Note the gap between F60 and F64.
>>> + */
>>> +#define D3323AA_REG_BIT_SLAVEA1		0	/* F37. */
>>> +#define D3323AA_REG_BIT_SLAVEA2		1	/* F38. */
>>> +#define D3323AA_REG_BIT_SLAVEA3		2	/* F39. */
>>> +#define D3323AA_REG_BIT_SLAVEA4		3	/* F40. */
>>> +#define D3323AA_REG_BIT_SLAVEA5		4	/* F41. */
>>> +#define D3323AA_REG_BIT_SLAVEA6		5	/* F42. */
>>> +#define D3323AA_REG_BIT_SLAVEA7		6	/* F43. */
>>> +#define D3323AA_REG_BIT_SLAVEA8		7	/* F44. */
>>> +#define D3323AA_REG_BIT_SLAVEA9		8	/* F45. */
>> Perhaps these can be represented as masks using GENMASK() rather than
>> bits.  A lot of this will be hidden away if you follow suggesting to
>> only expose that you are using a bitmap to bitbang in the read/write
>> functions.
>
> Yes, that would be the natural thing to do when moving the bitmap stuff
> to the read/write functions (as answered below).

Since `bitmap_write()` needs an offset (and size), I didn't use
`GENMASK()` in v2 and thought it would be more clear this way. I'm still
open for suggestions though.