From: Andy Shevchenko
There is no need to have a duplication of the generic library, i.e. hex2bin().
Replace the open coded variant.
Signed-off-by: Andy Shevchenko
---
drivers/md/dm-crypt.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a
ually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
turn lo;
> *dst++ = (hi << 4) | lo;
And on top of that it would be nice to understand if we need to
support half-bytes, but in any case it's not a scope of the patch
right now.
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Apr 26, 2022 at 08:07:44AM -0400, Mikulas Patocka wrote:
> On Tue, 26 Apr 2022, Andy Shevchenko wrote:
> > On Sun, Apr 24, 2022 at 10:48 PM Mikulas Patocka
> > wrote:
> > >
> > > If we pass too short string to "hex2bin" (and the string size wit
On Tue, Apr 26, 2022 at 08:07:44AM -0400, Mikulas Patocka wrote:
> On Tue, 26 Apr 2022, Andy Shevchenko wrote:
> > On Sun, Apr 24, 2022 at 10:48 PM Mikulas Patocka
> > wrote:
...
> > You need to provide a Fixes tag.
>
> OK. Here I resend it with the "Fixes&
On Wed, Apr 27, 2022 at 4:10 PM Mikulas Patocka wrote:
> On Wed, 27 Apr 2022, Andy Shevchenko wrote:
> > On Tue, Apr 26, 2022 at 5:29 PM Mikulas Patocka wrote:
> > > On Tue, 26 Apr 2022, Andy Shevchenko wrote:
> > > > On Tue, Apr 26, 2022 at 08:07:44AM -0400, Mikul
On Tue, Apr 26, 2022 at 5:29 PM Mikulas Patocka wrote:
> On Tue, 26 Apr 2022, Andy Shevchenko wrote:
> > On Tue, Apr 26, 2022 at 08:07:44AM -0400, Mikulas Patocka wrote:
> > > On Tue, 26 Apr 2022, Andy Shevchenko wrote:
> > > > On Sun, Apr 24, 2022 at 10:48 PM M
le that I can't imagine how could it break the
> curve25519 test. Are you sure that you bisected it correctly?
Can you provide a test cases for hex_to_bin()?
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
-1 +
> ((ch - '0' + 1) & (unsigned)((ch - '9' - 1) & ('0' - 1 - ch))
> >> 8) +
> ((cu - 'A' + 11) & (unsigned)((cu - 'F' - 1) & ('A' - 1 - cu))
> >> 8);
>
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Sat, Jul 02, 2022 at 09:24:24PM +0200, Christophe JAILLET wrote:
> Le 02/07/2022 à 20:54, Andy Shevchenko a écrit :
> > On Sat, Jul 02, 2022 at 08:29:09PM +0200, Christophe JAILLET wrote:
...
> > > - memset(set->bitmap, 0, bitmap_size(num_ssid, num_id));
>
he new function
> in bitmap.h automatically.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Christophe JAILLET
> ---
> drivers/md/dm-clone-metadata.c | 5 -
> include/linux/bitmap.h | 6 ++
> lib/math/prime_numbers.c | 2 --
> 3 files changed, 6 insertion
, set->num_id));
> + memset(set->bitmap, 0xff, idset_bitmap_size(set->num_ssid,
> set->num_id));
Why not to use bitmap_fill() ?
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
s)
> +static inline size_t ntfs3_bitmap_size(size_t bits)
> {
> return ALIGN((bits + 7) >> 3, 8);
It would be easier to understand in a way
return BITS_TO_BYTES(ALIGN(bits, 64));
> }
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.
ytes. Also argument for pure bitmap_size() would be
bitmap itself, but we have no way to detect the length of bitmap because we
are using POD and not a specific data structure for it.
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, May 11, 2016 at 2:24 AM, Andy Shevchenko
wrote:
> There is no need to have a duplication of the generic library, i.e. hex2bin().
> Replace the open coded variant.
>
Ping?
> Signed-off-by: Andy Shevchenko
> ---
> drivers/md/dm-crypt.c | 27 ++-
The nbits == 0 is safe to be supplied to the function body, so,
remove unnecessary checks in bitmap_to_arr32() and bitmap_from_arr32().
Acked-by: Yury Norov
Signed-off-by: Andy Shevchenko
---
lib/bitmap.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/lib/bitmap.c
subsystems and drivers.
Ideally it would go through Input subsystem, thus, needs an Ack from MD
maintainer(s).
Since v2:
- added namespace fix patch against MD bitmap API
- moved functions to lib/bitmap.c to avoid circular dependencies
- appended Dmitry's tags
Andy Shevchenko (5):
md:
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy Shevchenko
---
drivers/input/evdev.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy Shevchenko
---
drivers/input/keyboard/gpio_keys.c | 8
1 file changed, 4 insertions(+), 4 deletions
bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods.
On the other hand MD bitmap API is special case.
Adding 'md' prefix to it to avoid name space collision.
Signed-off-by: Andy Shevchenko
---
drivers/md/dm-raid.c | 6 +-
dr
On Sat, Jun 16, 2018 at 12:46 AM Yury Norov wrote:
> On Fri, Jun 15, 2018 at 04:20:17PM +0300, Andy Shevchenko wrote:
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
> > +
On Sat, Jun 16, 2018 at 1:24 AM Yury Norov wrote:
> On Fri, Jun 15, 2018 at 04:20:15PM +0300, Andy Shevchenko wrote:
> > A lot of code become ugly because of open coding allocations for bitmaps.
> >
> > Introduce three helpers to allow users be more clear of intention
> &g
On Sat, Jun 16, 2018 at 1:08 AM Yury Norov wrote:
>
> On Fri, Jun 15, 2018 at 04:20:16PM +0300, Andy Shevchenko wrote:
> > External Email
> >
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type ins
m: add persistent
> data library
>
> :: TO: Joe Thornber
> :: CC: Alasdair G Kergon
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
--
Andy Shevchenko
Intel Finland Oy
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
A lot of code become ugly because of open coding allocations for bitmaps.
Introduce three helpers to allow users be more clear of intention
and keep their code neat.
Signed-off-by: Andy Shevchenko
---
include/linux/bitmap.h | 8
lib/bitmap.c | 19 +++
2
from slab.h so we do not need to include workqueue.h...
>
> Or move the basic slab API stuff out of slab.h into a new header. Or
> create a new, standalone work_struct.h - that looks pretty simple.
Latter one seems requires least effort without potentially breaking things.
I take it as your suggestion, though I would still give a glance if it
is possible to split exactly memcg part out of slab.
--
With Best Regards,
Andy Shevchenko
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Switch to bitmap API, i.e. bitmap_alloc(), bitmap_zalloc(), to show
clearly what we are allocating. Besides that it returns pointer of
bitmap type instead of opaque void *.
While here, replace memcpy() with bitmap_copy() for sake of consistency.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy
On Sat, 2018-06-16 at 12:16 -0700, Joe Perches wrote:
> On Sat, 2018-06-16 at 21:45 +0300, Andy Shevchenko wrote:
> > On Sat, Jun 16, 2018 at 12:46 AM Yury Norov > om> wrote:
> > > On Fri, Jun 15, 2018 at 04:20:17PM +0300, Andy Shevchenko wrote:
> > > > Switc
On Mon, 2018-06-18 at 09:44 -0400, Mike Snitzer wrote:
> On Mon, Jun 18 2018 at 9:09am -0400,
> Andy Shevchenko wrote:
>
> > bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its
> > methods.
> >
> > On the other hand MD bitmap API is sp
On Tue, Jun 19, 2018 at 1:01 AM, Dmitry Torokhov
wrote:
> On Mon, Jun 18, 2018 at 2:14 PM Andrew Morton
> wrote:
>>
>> On Mon, 18 Jun 2018 16:10:01 +0300 Andy Shevchenko
>> wrote:
>>
>> > A lot of code become ugly because of open coding allocations
On Mon, Jun 18, 2018 at 6:49 PM, Joe Perches wrote:
> On Mon, 2018-06-18 at 15:02 +0300, Andy Shevchenko wrote:
>> On Sat, 2018-06-16 at 12:16 -0700, Joe Perches wrote:
>> > On Sat, 2018-06-16 at 21:45 +0300, Andy Shevchenko wrote:
>> > > On Sat, Jun 16, 2018 a
/bitmap.c to avoid circular dependencies
- appended Dmitry's tags
Andy Shevchenko (5):
md: Avoid namespace collision with bitmap API
bitmap: Drop unnecessary 0 check for u32 array operations
bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
Input: gpio-keys - Switch to bitmap_z
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy Shevchenko
---
drivers/input/keyboard/gpio_keys.c | 8
1 file changed, 4 insertions(+), 4 deletions
The nbits == 0 is safe to be supplied to the function body, so,
remove unnecessary checks in bitmap_to_arr32() and bitmap_from_arr32().
Acked-by: Yury Norov
Signed-off-by: Andy Shevchenko
---
lib/bitmap.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/lib/bitmap.c
bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods.
On the other hand MD bitmap API is special case.
Adding 'md' prefix to it to avoid name space collision.
No functional changes intended.
Signed-off-by: Andy Shevchenko
---
A lot of code become ugly because of open coding allocations for bitmaps.
Introduce three helpers to allow users be more clear of intention
and keep their code neat.
Signed-off-by: Andy Shevchenko
---
include/linux/bitmap.h | 8
lib/bitmap.c | 19 +++
2
On Wed, 2018-06-20 at 10:33 +0300, Yury Norov wrote:
> On Mon, Jun 18, 2018 at 04:09:58PM +0300, Andy Shevchenko wrote:
> > External Email
> >
> > A lot of code is using allocation of bitmaps using BITS_PER_LONG()
> > macro and
> > sizeof(unsigned long) operator
Splitting out kXalloc stuff to a separate header won't help, I think,
because of the above.
Splitting out struct work_struct is just a tip of an iceberg.
Splitting out memcg stuff won't help in the similar way.
I'm all ears for (a better) solution.
--
With Best Regards,
Andy Shevch
On Fri, 2018-06-22 at 11:46 -0700, Dmitry Torokhov wrote:
> On Thu, Jun 21, 2018 at 05:13:39AM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 19, 2018 at 2:10 AM, Andrew Morton
> > wrote:
> > > On Mon, 18 Jun 2018 15:01:43 -0700 Dmitry Torokhov > > v...@gmail.com&
bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods.
On the other hand DM bitmap API is special case.
Adding 'dm' prefix to it to avoid potential name space collision.
No functional changes intended.
Suggested-by: Mike Snitzer
Signed-off-by: Andy She
Switch to bitmap API, i.e. bitmap_alloc(), bitmap_zalloc(), to show
clearly what we are allocating. Besides that it returns pointer of
bitmap type instead of opaque void *.
While here, replace memcpy() with bitmap_copy() for sake of consistency.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy
,
at some point in the future we will sort out header inclusion and
inheritance.
Signed-off-by: Andy Shevchenko
---
include/linux/bitmap.h | 8
lib/bitmap.c | 19 +++
2 files changed, 27 insertions(+)
diff --git a/include/linux/bitmap.h b/include/linux
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Acked-by: Dmitry Torokhov
Signed-off-by: Andy Shevchenko
---
drivers/input/keyboard/gpio_keys.c | 8
1 file changed, 4 insertions(+), 4 deletions
try's tags
Andy Shevchenko (5):
dm: Avoid namespace collision with bitmap API
md: Avoid namespace collision with bitmap API
bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
Input: gpio-keys - Switch to bitmap_zalloc()
Input: evdev - Switch to bitmap API
drivers/inp
bitmap API (include/linux/bitmap.h) has 'bitmap' prefix for its methods.
On the other hand MD bitmap API is special case.
Adding 'md' prefix to it to avoid name space collision.
No functional changes intended.
Signed-off-by: Andy Shevchenko
---
drivers/md/dm-raid.c |
On Sat, Jun 30, 2018 at 11:17 PM, Andy Shevchenko
wrote:
> A lot of code is using allocation of bitmaps using BITS_PER_LONG() macro and
> sizeof(unsigned long) operator. The readability suffers because of this.
>
> The series introduces three helpers, i.e. bitmap_alloc(), bitmap_
On Thu, 2018-07-05 at 00:30 +0300, Andy Shevchenko wrote:
> On Sat, Jun 30, 2018 at 11:17 PM, Andy Shevchenko
> wrote:
> > A lot of code is using allocation of bitmaps using BITS_PER_LONG()
> > macro and
> > sizeof(unsigned long) operator. The readability suffers because o
On Wed, 2018-08-01 at 18:03 -0700, Dmitry Torokhov wrote:
> I put the first 3 patches into an immutable branch off 4.17:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/4.17-
> bitmap
Thank you!
--
Andy Shevchenko
Intel Finland Oy
--
dm-devel mailing l
There is no need to have a duplication of the generic library, i.e. hex2bin().
Replace the open coded variant.
Signed-off-by: Andy Shevchenko
---
drivers/md/dm-crypt.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/md/dm-crypt.c b
and the trailing space is always printed.
These are not a problem since it's a debug message. Also the IV dump
is limited by 64 bytes which seems fine.
Signed-off-by: Andy Shevchenko
---
drivers/md/dm-integrity.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
On Tue, Jun 13, 2023 at 01:13:54PM +, David Laight wrote:
> From: Andy Shevchenko
> > Sent: 12 June 2023 22:48
> >
> > The kernel already has a helper to print a hexdump of a small
> > buffer via pointer extension. Use that instead of open coded
> > variant.
od
> him correctly.
Just a disclaimer: The idea came before I saw the series by Alexander Potapenko.
> What do you think? I can provide some bloat-o-meter stats after
> rebasing. And either way, I see no issue in basing this series on top of
> Alex' one.
--
With Best Regards,
Andy Shevchenko
52 matches
Mail list logo
