[PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Andy Shevchenko]

There are few places when GENMASK() or BIT() macro is suitable and makes code
easier to understand.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/vt/keyboard.c | 48 +++++++++++++++++++--------------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 56b5e8f8fe88..bfe54b9822af 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -53,7 +53,7 @@
  * Exported functions/variables
  */
 
-#define KBD_DEFMODE ((1 << VC_REPEAT) | (1 << VC_META))
+#define KBD_DEFMODE (BIT(VC_REPEAT) | BIT(VC_META))
 
 #if defined(CONFIG_X86) || defined(CONFIG_PARISC)
 #include <asm/kbdleds.h>
@@ -423,8 +423,8 @@ static unsigned int handle_diacr(struct vc_data *vc, unsigned int ch)
 
 	diacr = 0;
 
-	if ((d & ~0xff) == BRL_UC_ROW) {
-		if ((ch & ~0xff) == BRL_UC_ROW)
+	if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
+		if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
 			return d | ch;
 	} else {
 		for (i = 0; i < accent_table_size; i++)
@@ -857,16 +857,16 @@ static void k_shift(struct vc_data *vc, unsigned char value, char up_flag)
 		shift_down[value]++;
 
 	if (shift_down[value])
-		shift_state |= (1 << value);
+		shift_state |= BIT(value);
 	else
-		shift_state &= ~(1 << value);
+		shift_state &= ~BIT(value);
 
 	/* kludge */
 	if (up_flag && shift_state != old_state && npadch_active) {
 		if (kbd->kbdmode == VC_UNICODE)
 			to_utf8(vc, npadch_value);
 		else
-			put_queue(vc, npadch_value & 0xff);
+			put_queue(vc, npadch_value & GENMASK(7, 0));
 		npadch_active = false;
 	}
 }
@@ -880,7 +880,7 @@ static void k_meta(struct vc_data *vc, unsigned char value, char up_flag)
 		put_queue(vc, '\033');
 		put_queue(vc, value);
 	} else
-		put_queue(vc, value | 0x80);
+		put_queue(vc, value | BIT(7));
 }
 
 static void k_ascii(struct vc_data *vc, unsigned char value, char up_flag)
@@ -976,7 +976,7 @@ static void k_brl(struct vc_data *vc, unsigned char value, char up_flag)
 		return;
 
 	if (!up_flag) {
-		pressed |= 1 << (value - 1);
+		pressed |= BIT(value - 1);
 		if (!brl_timeout)
 			committing = pressed;
 	} else if (brl_timeout) {
@@ -986,7 +986,7 @@ static void k_brl(struct vc_data *vc, unsigned char value, char up_flag)
 			committing = pressed;
 			releasestart = jiffies;
 		}
-		pressed &= ~(1 << (value - 1));
+		pressed &= ~BIT(value - 1);
 		if (!pressed && committing) {
 			k_brlcommit(vc, committing, 0);
 			committing = 0;
@@ -996,7 +996,7 @@ static void k_brl(struct vc_data *vc, unsigned char value, char up_flag)
 			k_brlcommit(vc, committing, 0);
 			committing = 0;
 		}
-		pressed &= ~(1 << (value - 1));
+		pressed &= ~BIT(value - 1);
 	}
 }
 
@@ -1096,9 +1096,9 @@ static int kbd_update_leds_helper(struct input_handle *handle, void *data)
 	unsigned int leds = *(unsigned int *)data;
 
 	if (test_bit(EV_LED, handle->dev->evbit)) {
-		input_inject_event(handle, EV_LED, LED_SCROLLL, !!(leds & 0x01));
-		input_inject_event(handle, EV_LED, LED_NUML,    !!(leds & 0x02));
-		input_inject_event(handle, EV_LED, LED_CAPSL,   !!(leds & 0x04));
+		input_inject_event(handle, EV_LED, LED_SCROLLL, !!(leds & BIT(0)));
+		input_inject_event(handle, EV_LED, LED_NUML,    !!(leds & BIT(1)));
+		input_inject_event(handle, EV_LED, LED_CAPSL,   !!(leds & BIT(2)));
 		input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
 	}
 
@@ -1125,14 +1125,14 @@ static void kbd_init_leds(void)
  */
 static unsigned char getledstate(void)
 {
-	return ledstate & 0xff;
+	return ledstate & GENMASK(7, 0);
 }
 
 void setledstate(struct kbd_struct *kb, unsigned int led)
 {
         unsigned long flags;
         spin_lock_irqsave(&led_lock, flags);
-	if (!(led & ~7)) {
+	if (!(led & ~GENMASK(2, 0))) {
 		ledioctl = led;
 		kb->ledmode = LED_SHOW_IOCTL;
 	} else
@@ -1338,7 +1338,7 @@ static int emulate_raw(struct vc_data *vc, unsigned int keycode,
 
 		if (code & 0x100)
 			put_queue(vc, 0xe0);
-		put_queue(vc, (code & 0x7f) | up_flag);
+		put_queue(vc, (code & GENMASK(6, 0)) | up_flag);
 
 		break;
 	}
@@ -1355,7 +1355,7 @@ static inline bool kbd_is_hw_raw(const struct input_dev *dev)
 
 static int emulate_raw(struct vc_data *vc, unsigned int keycode, unsigned char up_flag)
 {
-	if (keycode > 127)
+	if (keycode >= BIT(7))
 		return -1;
 
 	put_queue(vc, keycode | up_flag);
@@ -1423,12 +1423,12 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
 		 * applications. This allows for 16384 different keycodes,
 		 * which should be enough.
 		 */
-		if (keycode < 128) {
+		if (keycode < BIT(7)) {
 			put_queue(vc, keycode | (!down << 7));
 		} else {
 			put_queue(vc, !down << 7);
-			put_queue(vc, (keycode >> 7) | 0x80);
-			put_queue(vc, keycode | 0x80);
+			put_queue(vc, (keycode >> 7) | BIT(7));
+			put_queue(vc, keycode | BIT(7));
 		}
 		raw_mode = true;
 	}
@@ -1487,7 +1487,7 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
 	if (type == KT_LETTER) {
 		type = KT_LATIN;
 		if (vc_kbd_led(kbd, VC_CAPSLOCK)) {
-			key_map = key_maps[shift_final ^ (1 << KG_SHIFT)];
+			key_map = key_maps[shift_final ^ BIT(KG_SHIFT)];
 			if (key_map)
 				keysym = key_map[keycode];
 		}
@@ -2108,11 +2108,11 @@ int vt_do_kdskled(int console, int cmd, unsigned long arg, int perm)
 	case KDSKBLED:
 		if (!perm)
 			return -EPERM;
-		if (arg & ~0x77)
+		if (arg & ~(GENMASK(6, 4) | GENMASK(2, 0)))
 			return -EINVAL;
                 spin_lock_irqsave(&led_lock, flags);
-		kb->ledflagstate = (arg & 7);
-		kb->default_ledflagstate = ((arg >> 4) & 7);
+		kb->ledflagstate = arg & GENMASK(2, 0);
+		kb->default_ledflagstate = (arg & GENMASK(6, 4)) >> 4;
 		set_leds();
                 spin_unlock_irqrestore(&led_lock, flags);
 		return 0;
-- 
2.28.0

[PATCH v1 2/3] vt: keyboard, replace numbers with \r, \n where appropriate

[Andy Shevchenko]

Instead of 10, 13 use \n, \r respectively.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/vt/keyboard.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index bfe54b9822af..647c343f61fb 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -462,9 +462,9 @@ static void fn_enter(struct vc_data *vc)
 		diacr = 0;
 	}
 
-	put_queue(vc, 13);
+	put_queue(vc, '\r');
 	if (vc_kbd_mode(kbd, VC_CRLF))
-		put_queue(vc, 10);
+		put_queue(vc, '\n');
 }
 
 static void fn_caps_toggle(struct vc_data *vc)
@@ -827,7 +827,7 @@ static void k_pad(struct vc_data *vc, unsigned char value, char up_flag)
 
 	put_queue(vc, pad_chars[value]);
 	if (value == KVAL(K_PENTER) && vc_kbd_mode(kbd, VC_CRLF))
-		put_queue(vc, 10);
+		put_queue(vc, '\n');
 }
 
 static void k_shift(struct vc_data *vc, unsigned char value, char up_flag)
-- 
2.28.0

[PATCH v1 3/3] vt: keyboard, make use of assign_bit() API

[Andy Shevchenko]

We have for some time the assign_bit() API to replace open coded

	if (foo)
		set_bit(n, bar);
	else
		clear_bit(n, bar);

Use this API in VT keyboard library code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/vt/keyboard.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 647c343f61fb..b5132191b0ad 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1433,10 +1433,7 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
 		raw_mode = true;
 	}
 
-	if (down)
-		set_bit(keycode, key_down);
-	else
-		clear_bit(keycode, key_down);
+	assign_bit(keycode, key_down, down);
 
 	if (rep &&
 	    (!vc_kbd_mode(kbd, VC_REPEAT) ||
-- 
2.28.0

RE: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[David Laight]

From: Andy Shevchenko
> Sent: 06 November 2020 14:36
> 
> There are few places when GENMASK() or BIT() macro is suitable and makes code
> easier to understand.
> 
...
> -	if ((d & ~0xff) == BRL_UC_ROW) {
> -		if ((ch & ~0xff) == BRL_UC_ROW)
> +	if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
> +		if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
>  			return d | ch;

Do you really think that makes it more readable?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Andy Shevchenko]

On Fri, Nov 6, 2020 at 5:35 PM David Laight <David.Laight@aculab.com> wrote:
>
> From: Andy Shevchenko
> > Sent: 06 November 2020 14:36
> >
> > There are few places when GENMASK() or BIT() macro is suitable and makes code
> > easier to understand.
> >
> ...
> > -     if ((d & ~0xff) == BRL_UC_ROW) {
> > -             if ((ch & ~0xff) == BRL_UC_ROW)
> > +     if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
> > +             if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
> >                       return d | ch;
>
> Do you really think that makes it more readable?

Yes. Because this tells explicitly how many bits are used for metadata
vs. data.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Jiri Slaby]

On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> On Fri, Nov 6, 2020 at 5:35 PM David Laight <David.Laight@aculab.com> wrote:
>>
>> From: Andy Shevchenko
>>> Sent: 06 November 2020 14:36
>>>
>>> There are few places when GENMASK() or BIT() macro is suitable and makes code
>>> easier to understand.
>>>
>> ...
>>> -     if ((d & ~0xff) == BRL_UC_ROW) {
>>> -             if ((ch & ~0xff) == BRL_UC_ROW)
>>> +     if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
>>> +             if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
>>>                        return d | ch;
>>
>> Do you really think that makes it more readable?
> 
> Yes. Because this tells explicitly how many bits are used for metadata
> vs. data.

No, because ~0xff is clearly what it is. GENMASK(7, 0) is:
1) longer to read & parse by brain with result: "GENMASK undefined"
2) terrible in this particular use case

Another instance of an even worse switch:
-		if (arg & ~0x77)
+		if (arg & ~(GENMASK(6, 4) | GENMASK(2, 0)))

OTOH, the switch to BIT is legit in all cases except the comparisons 
with keycode:
-	if (keycode > 127)
+	if (keycode >= BIT(7))
-		if (keycode < 128) {
+		if (keycode < BIT(7)) {

That's horrid and non-sense too.

sorry,
-- 
js
suse labs

Re: [PATCH v1 2/3] vt: keyboard, replace numbers with \r, \n where appropriate

[Jiri Slaby]

On 06. 11. 20, 15:35, Andy Shevchenko wrote:
> Instead of 10, 13 use \n, \r respectively.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Acked-by: Jiri Slaby <jirislaby@kernel.org>

> ---
>   drivers/tty/vt/keyboard.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index bfe54b9822af..647c343f61fb 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -462,9 +462,9 @@ static void fn_enter(struct vc_data *vc)
>   		diacr = 0;
>   	}
>   
> -	put_queue(vc, 13);
> +	put_queue(vc, '\r');
>   	if (vc_kbd_mode(kbd, VC_CRLF))
> -		put_queue(vc, 10);
> +		put_queue(vc, '\n');
>   }
>   
>   static void fn_caps_toggle(struct vc_data *vc)
> @@ -827,7 +827,7 @@ static void k_pad(struct vc_data *vc, unsigned char value, char up_flag)
>   
>   	put_queue(vc, pad_chars[value]);
>   	if (value == KVAL(K_PENTER) && vc_kbd_mode(kbd, VC_CRLF))
> -		put_queue(vc, 10);
> +		put_queue(vc, '\n');
>   }
>   
>   static void k_shift(struct vc_data *vc, unsigned char value, char up_flag)
> 


-- 
js
suse labs

Re: [PATCH v1 3/3] vt: keyboard, make use of assign_bit() API

[Jiri Slaby]

On 06. 11. 20, 15:35, Andy Shevchenko wrote:
> We have for some time the assign_bit() API to replace open coded
> 
> 	if (foo)
> 		set_bit(n, bar);
> 	else
> 		clear_bit(n, bar);
> 
> Use this API in VT keyboard library code.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Acked-by: Jiri Slaby <jirislaby@kernel.org>

> ---
>   drivers/tty/vt/keyboard.c | 5 +----
>   1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index 647c343f61fb..b5132191b0ad 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -1433,10 +1433,7 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
>   		raw_mode = true;
>   	}
>   
> -	if (down)
> -		set_bit(keycode, key_down);
> -	else
> -		clear_bit(keycode, key_down);
> +	assign_bit(keycode, key_down, down);
>   
>   	if (rep &&
>   	    (!vc_kbd_mode(kbd, VC_REPEAT) ||
> 


-- 
js
suse labs

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Andy Shevchenko]

On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> > On Fri, Nov 6, 2020 at 5:35 PM David Laight <David.Laight@aculab.com> wrote:
> >> From: Andy Shevchenko
> >>> Sent: 06 November 2020 14:36
> >>>
> >>> There are few places when GENMASK() or BIT() macro is suitable and makes code
> >>> easier to understand.

Thanks for the review, my answers below.

> >> ...
> >>> -     if ((d & ~0xff) == BRL_UC_ROW) {
> >>> -             if ((ch & ~0xff) == BRL_UC_ROW)
> >>> +     if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
> >>> +             if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
> >>>                        return d | ch;
> >>
> >> Do you really think that makes it more readable?
> >
> > Yes. Because this tells explicitly how many bits are used for metadata
> > vs. data.
>
> No, because ~0xff is clearly what it is. GENMASK(7, 0) is:
> 1) longer to read & parse by brain with result: "GENMASK undefined"
> 2) terrible in this particular use case

Maybe #define with a proper name can bring some shed of light here?

> Another instance of an even worse switch:
> -               if (arg & ~0x77)
> +               if (arg & ~(GENMASK(6, 4) | GENMASK(2, 0)))

It exactly shows what bits we are accepting and what are not. 0x77 you
need to translate to the bitmap and then figure out the bit numbers.
This is error prone as shown in some cases.

> OTOH, the switch to BIT is legit in all cases except the comparisons
> with keycode:
> -       if (keycode > 127)
> +       if (keycode >= BIT(7))
> -               if (keycode < 128) {
> +               if (keycode < BIT(7)) {
>
> That's horrid and non-sense too.

Isn't it the exact threshold about keycodes that we only use 7-bit value?

> sorry,

Consider this then as RFC.
What about the rest of the series?


-- 
With Best Regards,
Andy Shevchenko

RE: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[David Laight]

From: Andy Shevchenko 
> Sent: 09 November 2020 10:10
> 
> On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> > > On Fri, Nov 6, 2020 at 5:35 PM David Laight <David.Laight@aculab.com> wrote:
> > >> From: Andy Shevchenko
> > >>> Sent: 06 November 2020 14:36
> > >>>
> > >>> There are few places when GENMASK() or BIT() macro is suitable and makes code
> > >>> easier to understand.
> 
> Thanks for the review, my answers below.
> 
> > >> ...
> > >>> -     if ((d & ~0xff) == BRL_UC_ROW) {
> > >>> -             if ((ch & ~0xff) == BRL_UC_ROW)
> > >>> +     if ((d & ~GENMASK(7, 0)) == BRL_UC_ROW) {
> > >>> +             if ((ch & ~GENMASK(7, 0)) == BRL_UC_ROW)
> > >>>                        return d | ch;
> > >>
> > >> Do you really think that makes it more readable?
> > >
> > > Yes. Because this tells explicitly how many bits are used for metadata
> > > vs. data.
> >
> > No, because ~0xff is clearly what it is. GENMASK(7, 0) is:
> > 1) longer to read & parse by brain with result: "GENMASK undefined"
> > 2) terrible in this particular use case
> 
> Maybe #define with a proper name can bring some shed of light here?

Possibly.

> > Another instance of an even worse switch:
> > -               if (arg & ~0x77)
> > +               if (arg & ~(GENMASK(6, 4) | GENMASK(2, 0)))
> 
> It exactly shows what bits we are accepting and what are not. 0x77 you
> need to translate to the bitmap and then figure out the bit numbers.
> This is error prone as shown in some cases.

We all know what 0xff and 0x77 mean.
It is ingrained from years of writing software.

Now it may be that the 0x77 is related to masking off
some other bit values.
In that case you could have a named constant based on the
names of the other bit values.
But if you are putting in simple constants there is nothing
wrong with hex.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Andy Shevchenko]

On Mon, Nov 09, 2020 at 12:10:27PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > On 06. 11. 20, 17:06, Andy Shevchenko wrote:

...

> > sorry,
> 
> Consider this then as RFC.
> What about the rest of the series?

I got the answer, thanks!
So, I will drop the first patch and resend the rest with your Ack.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Jiri Slaby]

On 09. 11. 20, 11:27, Andy Shevchenko wrote:
> On Mon, Nov 09, 2020 at 12:10:27PM +0200, Andy Shevchenko wrote:
>> On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>> On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> 
> ...
> 
>>> sorry,
>>
>> Consider this then as RFC.
>> What about the rest of the series?
> 
> I got the answer, thanks!
> So, I will drop the first patch and resend the rest with your Ack.

As I wrote the BIT pieces are mostly fine too…

-- 
js
suse labs

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

['Andy Shevchenko']

On Mon, Nov 09, 2020 at 10:20:42AM +0000, David Laight wrote:
> > On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > > On 06. 11. 20, 17:06, Andy Shevchenko wrote:

...

> > > Another instance of an even worse switch:
> > > -               if (arg & ~0x77)
> > > +               if (arg & ~(GENMASK(6, 4) | GENMASK(2, 0)))
> > 
> > It exactly shows what bits we are accepting and what are not. 0x77 you
> > need to translate to the bitmap and then figure out the bit numbers.
> > This is error prone as shown in some cases.
> 
> We all know what 0xff and 0x77 mean.

Oh, do you expect one with curiosity and absence of C/Linux kernel experience
may not try to understand the code easily? We have real examples of such
curious people, and honestly I admire them much more than people who knows what
0x77 or 0xff means in every case by heart (yes, at some point of time I used to
program Z80 directly from my mind in assembly, but does it really a must for
a curious reader / contributor?).

> It is ingrained from years of writing software.
> 
> Now it may be that the 0x77 is related to masking off
> some other bit values.
> In that case you could have a named constant based on the
> names of the other bit values.
> But if you are putting in simple constants there is nothing
> wrong with hex.

It makes code harder to understand. Besides that GENMASK() and BIT() avoids UB
which is often happen when programmers doesn't think about (yes, we may discuss
about poorness of C standard etc, but this what we have now).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] vt: keyboard, use GENMAASK()/BIT() macros instead of open coded variants

[Andy Shevchenko]

On Mon, Nov 09, 2020 at 11:41:31AM +0100, Jiri Slaby wrote:
> On 09. 11. 20, 11:27, Andy Shevchenko wrote:
> > On Mon, Nov 09, 2020 at 12:10:27PM +0200, Andy Shevchenko wrote:
> > > On Mon, Nov 9, 2020 at 11:57 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > > > On 06. 11. 20, 17:06, Andy Shevchenko wrote:
> > 
> > ...
> > 
> > > > sorry,
> > > 
> > > Consider this then as RFC.
> > > What about the rest of the series?
> > 
> > I got the answer, thanks!
> > So, I will drop the first patch and resend the rest with your Ack.
> 
> As I wrote the BIT pieces are mostly fine too…

Okay, I will try again with BIT() conversion only.

-- 
With Best Regards,
Andy Shevchenko