[PATCH v9 0/4] Introduce the for_each_set_clump macro

[PATCH v9 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

Hello Linus,

Since this patchset primarily affects GPIO drivers, would you like
to pick it up through your GPIO tree?

This patchset introduces a new generic version of for_each_set_clump. 
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated a
for-loop syntax that iterates over a memory region entire groups of set
bits at a time.

For example, suppose you would like to iterate over a 32-bit integer 8
bits at a time, skipping over 8-bit groups with no set bit, where
XXXXXXXX represents the current 8-bit group:

    Example:        10111110 00000000 11111111 00110011
    First loop:     10111110 00000000 11111111 XXXXXXXX
    Second loop:    10111110 00000000 XXXXXXXX 00110011
    Third loop:     XXXXXXXX 00000000 11111111 00110011

Each iteration of the loop returns the next 8-bit group that has at
least one set bit.

But with the new for_each_set_clump the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word 
size is not multiple of clump size. Following are examples showing the working 
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x000000aa000000aa;
        0xbbbbabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_clump:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:        offset: 0 clump: 0xfedcba
Iteration second:       offset: 24 clump: 0xabcdef
Iteration third:        offset: 48 clump: 0xaabbbb
Iteration fourth:       offset: 96 clump: 0xaa
Iteration fifth:        offset: 144 clump: 0xff
Iteration sixth:        offset: 168 clump: 0xaaaaaa
Iteration seventh:      offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example 
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour). 

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x0f00000000000000;
        0x0000000000000ac0;  /* Least significant bits */

Different iterations of for_each_set_clump:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:        offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v9:
 - [Patch 4/4]: Remove looping of 'for_each_set_clump' and instead process two 
   halves of a 64-bit bitmap separately or individually. Use normal spin_lock 
   call for second inner lock. And take the spin_lock_init call outside the 'if'
   condition in the probe function of driver.

Changes in v8:
 - [Patch 2/4]: Minor change: Use '__initdata' for correct section mismatch
   in 'clump_test_data' array.

Changes in v7:
 - [Patch 2/4]: Minor changes: Use macro 'DECLARE_BITMAP()' and split 'struct'
   definition and test data.

Changes in v6:
 - [Patch 2/4]: Make 'for loop' inside test_for_each_set_clump more
   succinct.

Changes in v5:
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v4:
 - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
 - [Patch 3/4]: Minor change: Inline value for better code readability.
 - [Patch 4/4]: Minor change: Inline value for better code readability.

Changes in v3:
 - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

CHanges in v2:
 - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as
   function parameters.
 - [Patch 2/4]: Remove unnecessary bitmap_zero calls.

Syed Nayyar Waris (4):
  bitops: Introduce the for_each_set_clump macro
  lib/test_bitmap.c: Add for_each_set_clump test cases
  gpio: thunderx: Utilize for_each_set_clump macro
  gpio: xilinx: Utilize generic bitmap_get_value and _set_value.

 drivers/gpio/gpio-thunderx.c      |  11 ++-
 drivers/gpio/gpio-xilinx.c        |  66 +++++++-------
 include/asm-generic/bitops/find.h |  19 ++++
 include/linux/bitmap.h            |  61 +++++++++++++
 include/linux/bitops.h            |  13 +++
 lib/find_bit.c                    |  14 +++
 lib/test_bitmap.c                 | 145 ++++++++++++++++++++++++++++++
 7 files changed, 292 insertions(+), 37 deletions(-)


base-commit: b3a9e3b9622ae10064826dccb4f7a52bd88c7407
-- 
2.26.2


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

[PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value.

[Syed Nayyar Waris]

This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new generic functions:
bitmap_get_value and bitmap_set_value. The code is now simpler
to read and understand. Moreover, instead of looping for each bit
in xgpio_set_multiple function, now we can check each channel at
a time and save cycles.
---
Changes in v9:
 - Remove looping of 'for_each_set_clump' and instead process two
   halves of a 64-bit bitmap separately or individually. Use normal spin_lock 
   call for second inner lock. And take the spin_lock_init call outside the 'if'
   condition in the 'probe' function of driver.

Changes in v8:
 - No change.

Changes in v7:
 - No change.

Changes in v6:
 - No change.

Changes in v5:
 - Minor change: Inline values '32' and '64' in code for better
   code readability.

Changes in v4:
 - Minor change: Inline values '32' and '64' in code for better
   code readability.

Changes in v3:
 - No change.

Changes in v2:
 - No change

 drivers/gpio/gpio-xilinx.c | 66 +++++++++++++++++++-------------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..48393d06fb55 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,39 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 			       unsigned long *bits)
 {
-	unsigned long flags;
+	unsigned long flag;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
-
-	spin_lock_irqsave(&chip->gpio_lock[index], flags);
-
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock[index], flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
-	}
-
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
-	spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
+	u32 *const state = chip->gpio_state;
+	unsigned int *const width = chip->gpio_width;
+
+	DECLARE_BITMAP(old, 64);
+	DECLARE_BITMAP(new, 64);
+	DECLARE_BITMAP(changed, 64);
+
+	spin_lock_irqsave(&chip->gpio_lock[0], flag);
+	spin_lock(&chip->gpio_lock[1]);
+
+	bitmap_set_value(old, state[0], 0, width[0]);
+	bitmap_set_value(old, state[1], width[0], width[1]);
+	bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+	bitmap_set_value(old, state[0], 0, 32);
+	bitmap_set_value(old, state[1], 32, 32);
+	state[0] = bitmap_get_value(new, 0, width[0]);
+	state[1] = bitmap_get_value(new, width[0], width[1]);
+	bitmap_set_value(new, state[0], 0, 32);
+	bitmap_set_value(new, state[1], 32, 32);
+	bitmap_xor(changed, old, new, 64);
+
+	if (((u32 *)changed)[0])
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,
+				state[0]);
+	if (((u32 *)changed)[1])
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+				XGPIO_CHANNEL_OFFSET, state[1]);
+
+	spin_unlock(&chip->gpio_lock[1]);
+	spin_unlock_irqrestore(&chip->gpio_lock[0], flag);
 }
 
 /**
@@ -292,6 +292,7 @@ static int xgpio_probe(struct platform_device *pdev)
 		chip->gpio_width[0] = 32;
 
 	spin_lock_init(&chip->gpio_lock[0]);
+	spin_lock_init(&chip->gpio_lock[1]);
 
 	if (of_property_read_u32(np, "xlnx,is-dual", &is_dual))
 		is_dual = 0;
@@ -314,7 +315,6 @@ static int xgpio_probe(struct platform_device *pdev)
 					 &chip->gpio_width[1]))
 			chip->gpio_width[1] = 32;
 
-		spin_lock_init(&chip->gpio_lock[1]);
 	}
 
 	chip->gc.base = -1;
-- 
2.26.2


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

Re: [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value.

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 2549 bytes --]

On Sat, Jun 27, 2020 at 01:44:23PM +0530, Syed Nayyar Waris wrote:
> This patch reimplements the xgpio_set_multiple function in
> drivers/gpio/gpio-xilinx.c to use the new generic functions:
> bitmap_get_value and bitmap_set_value. The code is now simpler
> to read and understand. Moreover, instead of looping for each bit
> in xgpio_set_multiple function, now we can check each channel at
> a time and save cycles.
> ---
> Changes in v9:
>  - Remove looping of 'for_each_set_clump' and instead process two
>    halves of a 64-bit bitmap separately or individually. Use normal spin_lock 
>    call for second inner lock. And take the spin_lock_init call outside the 'if'
>    condition in the 'probe' function of driver.
> 
> Changes in v8:
>  - No change.
> 
> Changes in v7:
>  - No change.
> 
> Changes in v6:
>  - No change.
> 
> Changes in v5:
>  - Minor change: Inline values '32' and '64' in code for better
>    code readability.
> 
> Changes in v4:
>  - Minor change: Inline values '32' and '64' in code for better
>    code readability.
> 
> Changes in v3:
>  - No change.
> 
> Changes in v2:
>  - No change
> 
>  drivers/gpio/gpio-xilinx.c | 66 +++++++++++++++++++-------------------
>  1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 67f9f82e0db0..48393d06fb55 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -136,39 +136,39 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
>  static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
>  			       unsigned long *bits)
>  {
> -	unsigned long flags;
> +	unsigned long flag;

Hi Syed,

I have a couple minor suggestions in case you submit a version 10. Leave
this variable named "flags" because it refers to CPU flags which will
likely be more than one flag anyway.

> @@ -292,6 +292,7 @@ static int xgpio_probe(struct platform_device *pdev)
>  		chip->gpio_width[0] = 32;
>  
>  	spin_lock_init(&chip->gpio_lock[0]);
> +	spin_lock_init(&chip->gpio_lock[1]);
>  
>  	if (of_property_read_u32(np, "xlnx,is-dual", &is_dual))
>  		is_dual = 0;
> @@ -314,7 +315,6 @@ static int xgpio_probe(struct platform_device *pdev)
>  					 &chip->gpio_width[1]))
>  			chip->gpio_width[1] = 32;
>  

Remove this whitespace as well.

Thanks,

William Breathitt Gray

> -		spin_lock_init(&chip->gpio_lock[1]);
>  	}
>  
>  	chip->gc.base = -1;
> -- 
> 2.26.2
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

On Sat, Jun 27, 2020 at 1:40 PM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
>
> Hello Linus,
>
> Since this patchset primarily affects GPIO drivers, would you like
> to pick it up through your GPIO tree?
>
> This patchset introduces a new generic version of for_each_set_clump.
> The previous version of for_each_set_clump8 used a fixed size 8-bit
> clump, but the new generic version can work with clump of any size but
> less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
> in several GPIO drivers.
>
> The earlier 8-bit for_each_set_clump8 facilitated a
> for-loop syntax that iterates over a memory region entire groups of set
> bits at a time.
>
> For example, suppose you would like to iterate over a 32-bit integer 8
> bits at a time, skipping over 8-bit groups with no set bit, where
> XXXXXXXX represents the current 8-bit group:
>
>     Example:        10111110 00000000 11111111 00110011
>     First loop:     10111110 00000000 11111111 XXXXXXXX
>     Second loop:    10111110 00000000 XXXXXXXX 00110011
>     Third loop:     XXXXXXXX 00000000 11111111 00110011
>
> Each iteration of the loop returns the next 8-bit group that has at
> least one set bit.
>
> But with the new for_each_set_clump the clump size can be different from 8 bits.
> Moreover, the clump can be split at word boundary in situations where word
> size is not multiple of clump size. Following are examples showing the working
> of new macro for clump sizes of 24 bits and 6 bits.
>
> Example 1:
> clump size: 24 bits, Number of clumps (or ports): 10
> bitmap stores the bit information from where successive clumps are retrieved.
>
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x000000aa000000aa;
>         0xbbbbabcdeffedcba;  /* Least significant bits */
>
> Different iterations of for_each_set_clump:-
> 'offset' is the bit position and 'clump' is the 24 bit clump from the
> above bitmap.
> Iteration first:        offset: 0 clump: 0xfedcba
> Iteration second:       offset: 24 clump: 0xabcdef
> Iteration third:        offset: 48 clump: 0xaabbbb
> Iteration fourth:       offset: 96 clump: 0xaa
> Iteration fifth:        offset: 144 clump: 0xff
> Iteration sixth:        offset: 168 clump: 0xaaaaaa
> Iteration seventh:      offset: 216 clump: 0xff
> Loop breaks because in the end the remaining bits (0x00aa) size was less
> than clump size of 24 bits.
>
> In above example it can be seen that in iteration third, the 24 bit clump
> that was retrieved was split between bitmap[0] and bitmap[1]. This example
> also shows that 24 bit zeroes if present in between, were skipped (preserving
> the previous for_each_set_macro8 behaviour).
>
> Example 2:
> clump size = 6 bits, Number of clumps (or ports) = 3.
>
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x0f00000000000000;
>         0x0000000000000ac0;  /* Least significant bits */
>
> Different iterations of for_each_set_clump:
> 'offset' is the bit position and 'clump' is the 6 bit clump from the
> above bitmap.
> Iteration first:        offset: 6 clump: 0x2b
> Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> Here 6 * 3 is clump size * no. of clumps.
>
> Changes in v9:
>  - [Patch 4/4]: Remove looping of 'for_each_set_clump' and instead process two
>    halves of a 64-bit bitmap separately or individually. Use normal spin_lock
>    call for second inner lock. And take the spin_lock_init call outside the 'if'
>    condition in the probe function of driver.
>
> Changes in v8:
>  - [Patch 2/4]: Minor change: Use '__initdata' for correct section mismatch
>    in 'clump_test_data' array.
>
> Changes in v7:
>  - [Patch 2/4]: Minor changes: Use macro 'DECLARE_BITMAP()' and split 'struct'
>    definition and test data.
>
> Changes in v6:
>  - [Patch 2/4]: Make 'for loop' inside test_for_each_set_clump more
>    succinct.
>
> Changes in v5:
>  - [Patch 4/4]: Minor change: Hardcode value for better code readability.
>
> Changes in v4:
>  - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
>  - [Patch 3/4]: Minor change: Inline value for better code readability.
>  - [Patch 4/4]: Minor change: Inline value for better code readability.
>
> Changes in v3:
>  - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
>    in function thunderx_gpio_set_multiple.
>
> CHanges in v2:
>  - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as
>    function parameters.
>  - [Patch 2/4]: Remove unnecessary bitmap_zero calls.
>
> Syed Nayyar Waris (4):
>   bitops: Introduce the for_each_set_clump macro
>   lib/test_bitmap.c: Add for_each_set_clump test cases
>   gpio: thunderx: Utilize for_each_set_clump macro
>   gpio: xilinx: Utilize generic bitmap_get_value and _set_value.
>
>  drivers/gpio/gpio-thunderx.c      |  11 ++-
>  drivers/gpio/gpio-xilinx.c        |  66 +++++++-------
>  include/asm-generic/bitops/find.h |  19 ++++
>  include/linux/bitmap.h            |  61 +++++++++++++
>  include/linux/bitops.h            |  13 +++
>  lib/find_bit.c                    |  14 +++
>  lib/test_bitmap.c                 | 145 ++++++++++++++++++++++++++++++
>  7 files changed, 292 insertions(+), 37 deletions(-)
>
>
> base-commit: b3a9e3b9622ae10064826dccb4f7a52bd88c7407
> --
> 2.26.2
>


Hi Andrew, Linus

What do you think about this patchset on 'for_each_set_clump' ?

if there's anything else you think that should be changed in this, or if this
version looks good to you to pick up, kindly, let me know.

Regards
Syed Nayyar Waris

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Linus Walleij]

Hi Syed,

sorry for taking so long. I was on vacation and a bit snowed
under by work.

On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:

> Since this patchset primarily affects GPIO drivers, would you like
> to pick it up through your GPIO tree?

I have applied the patches to an immutable branch and pushed
to kernelorg for testing (autobuilders will play with it I hope).

If all works fine I will merge this into my devel branch for v5.9.

It would be desirable if Andrew gave his explicit ACK on it too.

Yours,
Linus Walleij

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

On Thu, Jul 16, 2020 at 6:19 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi Syed,
>
> sorry for taking so long. I was on vacation and a bit snowed
> under by work.
>
> On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
>
> > Since this patchset primarily affects GPIO drivers, would you like
> > to pick it up through your GPIO tree?
>
> I have applied the patches to an immutable branch and pushed
> to kernelorg for testing (autobuilders will play with it I hope).
>
> If all works fine I will merge this into my devel branch for v5.9.
>
> It would be desirable if Andrew gave his explicit ACK on it too.
>
> Yours,
> Linus Walleij

Hi Linus,

As a reminder, I would like to point out about the
'for_each_set_clump' patchset. If it's alright and if anything is
needed to take it further so that it is finally accepted.

Regards
Syed Nayyar Waris

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 943 bytes --]

On Thu, Jul 16, 2020 at 02:49:35PM +0200, Linus Walleij wrote:
> Hi Syed,
> 
> sorry for taking so long. I was on vacation and a bit snowed
> under by work.
> 
> On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
> 
> > Since this patchset primarily affects GPIO drivers, would you like
> > to pick it up through your GPIO tree?
> 
> I have applied the patches to an immutable branch and pushed
> to kernelorg for testing (autobuilders will play with it I hope).
> 
> If all works fine I will merge this into my devel branch for v5.9.
> 
> It would be desirable if Andrew gave his explicit ACK on it too.
> 
> Yours,
> Linus Walleij

Hi Linus,

What's the name of the branch with these patches on kernelorg; I'm
having trouble finding it?

Btw, I'm CCing Andrew as well here because I notice him missing from the
CC list earlier for this patchset.

Thanks,

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Linus Walleij]

On Sat, Sep 12, 2020 at 12:54 AM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
> On Thu, Jul 16, 2020 at 02:49:35PM +0200, Linus Walleij wrote:
> > Hi Syed,
> >
> > sorry for taking so long. I was on vacation and a bit snowed
> > under by work.
> >
> > On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
> >
> > > Since this patchset primarily affects GPIO drivers, would you like
> > > to pick it up through your GPIO tree?
> >
> > I have applied the patches to an immutable branch and pushed
> > to kernelorg for testing (autobuilders will play with it I hope).
> >
> > If all works fine I will merge this into my devel branch for v5.9.
> >
> > It would be desirable if Andrew gave his explicit ACK on it too.
> >
> > Yours,
> > Linus Walleij
>
> Hi Linus,
>
> What's the name of the branch with these patches on kernelorg; I'm
> having trouble finding it?
>
> Btw, I'm CCing Andrew as well here because I notice him missing from the
> CC list earlier for this patchset.

IIRC there were complaints from the zeroday build robot so I
dropped the branch and I am still waiting for a fixed up patch
series.

Yours,
Linus Walleij

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 1654 bytes --]

On Tue, Sep 29, 2020 at 02:45:18PM +0200, Linus Walleij wrote:
> On Sat, Sep 12, 2020 at 12:54 AM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Thu, Jul 16, 2020 at 02:49:35PM +0200, Linus Walleij wrote:
> > > Hi Syed,
> > >
> > > sorry for taking so long. I was on vacation and a bit snowed
> > > under by work.
> > >
> > > On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
> > >
> > > > Since this patchset primarily affects GPIO drivers, would you like
> > > > to pick it up through your GPIO tree?
> > >
> > > I have applied the patches to an immutable branch and pushed
> > > to kernelorg for testing (autobuilders will play with it I hope).
> > >
> > > If all works fine I will merge this into my devel branch for v5.9.
> > >
> > > It would be desirable if Andrew gave his explicit ACK on it too.
> > >
> > > Yours,
> > > Linus Walleij
> >
> > Hi Linus,
> >
> > What's the name of the branch with these patches on kernelorg; I'm
> > having trouble finding it?
> >
> > Btw, I'm CCing Andrew as well here because I notice him missing from the
> > CC list earlier for this patchset.
> 
> IIRC there were complaints from the zeroday build robot so I
> dropped the branch and I am still waiting for a fixed up patch
> series.
> 
> Yours,
> Linus Walleij

My apologies, I wasn't aware a build error was reported. I'll be happy
to help address the issue with Syed, but I can't seem to find a copy of
the message on <https://lkml.org/lkml/2020/6/27/107> or my email logs.
Do you have a link available to the zeroday build log?

Thanks,

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Tue, Sep 29, 2020 at 4:09 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
>
> On Tue, Sep 29, 2020 at 02:45:18PM +0200, Linus Walleij wrote:
> > On Sat, Sep 12, 2020 at 12:54 AM William Breathitt Gray
> > <vilhelm.gray@gmail.com> wrote:
> > > On Thu, Jul 16, 2020 at 02:49:35PM +0200, Linus Walleij wrote:
> > > > On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris <syednwaris@gmail.com> wrote:

...

> > > What's the name of the branch with these patches on kernelorg; I'm
> > > having trouble finding it?
> > >
> > > Btw, I'm CCing Andrew as well here because I notice him missing from the
> > > CC list earlier for this patchset.
> >
> > IIRC there were complaints from the zeroday build robot so I
> > dropped the branch and I am still waiting for a fixed up patch
> > series.

> My apologies, I wasn't aware a build error was reported. I'll be happy
> to help address the issue with Syed, but I can't seem to find a copy of
> the message on <https://lkml.org/lkml/2020/6/27/107> or my email logs.
> Do you have a link available to the zeroday build log?


Time to open lore.kernel.org? [1][2]

Linus, are you referencing to [3]? It was fixed in GENMASK()
implementation some time ago.

[1]: https://lore.kernel.org/lkml/cover.1593243079.git.syednwaris@gmail.com/
[2]: https://lore.kernel.org/lkml/cover.1592224128.git.syednwaris@gmail.com/
[3]: https://lore.kernel.org/lkml/202006171559.JSbGJXNw%25lkp@intel.com/

-- 
With Best Regards,
Andy Shevchenko

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Linus Walleij]

On Tue, Sep 29, 2020 at 3:14 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:

> Linus, are you referencing to [3]? It was fixed in GENMASK()
> implementation some time ago.
> [3]: https://lore.kernel.org/lkml/202006171559.JSbGJXNw%25lkp@intel.com/

Yup.

I tried to apply the patches again now to test it but now patch 2
needs to be rebased.

Sorry for all the trouble!

Syed can you rebase the patch set on v5.9-rc1 and resend as v10?

Yours,
Linus Walleij

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

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

On Wed, Sep 30, 2020 at 2:59 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Sep 29, 2020 at 3:14 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
> > Linus, are you referencing to [3]? It was fixed in GENMASK()
> > implementation some time ago.
> > [3]: https://lore.kernel.org/lkml/202006171559.JSbGJXNw%25lkp@intel.com/
>
> Yup.
>
> I tried to apply the patches again now to test it but now patch 2
> needs to be rebased.
>
> Sorry for all the trouble!
>
> Syed can you rebase the patch set on v5.9-rc1 and resend as v10?

Sure Linus. I will send it as soon as possible.

Thanks
Syed Nayyar Waris

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