On Sat, Mar 27, 2021 at 10:05 PM Andy Shevchenko
[off-list ref] wrote:

On Sat, Mar 27, 2021 at 2:02 PM William Breathitt Gray
[off-list ref] wrote:

quoted

On Sat, Mar 27, 2021 at 09:29:26AM +0200, Andy Shevchenko wrote:

quoted

On Saturday, March 27, 2021, Syed Nayyar Waris [off-list ref] wrote:

quoted

On Fri, Mar 26, 2021 at 11:32 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Sat, Mar 6, 2021 at 4:08 PM Syed Nayyar Waris [off-list ref]

wrote:

quoted

quoted

+       bitmap_set_value(old, 64, state[0], 32, 0);
+       bitmap_set_value(old, 64, state[1], 32, 32);

Isn't it effectively bitnap_from_arr32() ?

quoted

+       bitmap_set_value(new, 64, state[0], 32, 0);
+       bitmap_set_value(new, 64, state[1], 32, 32);

Ditto.

quoted

quoted

quoted

With bitmap_set_value() we are also specifying the offset (or start)
position too. so that the remainder of the array remains unaffected. I
think it would not be feasible to use bitmap_from/to_arr32()  here.

You have hard coded start and nbits parameters to 32. How is it not the
same?

Would these four lines become something like this:

        bitmap_from_arr32(old, state, 64);
        ...
        bitmap_from_arr32(new, state, 64);

This is my understanding, but I might miss something. I mean driver
specifics that make my proposal incorrect.

--
With Best Regards,
Andy Shevchenko

I initially (incorrectly) thought that all of the bitmap_set_value()
statements have to be replaced. But now I realised, only those
specific bitmap_set_value() calls containing 32 bits width have to
replaced.

I will incorporate the above review comments in my next v4 submission.

Regards
Syed Nayyar Waris

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel