* [PATCH v9 3/4] gpio: thunderx: Utilize for_each_set_clump macro
2020-06-27 8:09 [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
@ 2020-06-27 8:13 ` Syed Nayyar Waris
2020-06-27 8:14 ` [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value Syed Nayyar Waris
` (2 subsequent siblings)
3 siblings, 0 replies; 13+ messages in thread
From: Syed Nayyar Waris @ 2020-06-27 8:13 UTC (permalink / raw)
To: linus.walleij
Cc: andriy.shevchenko, vilhelm.gray, rrichter, bgolaszewski,
linux-gpio, linux-kernel
This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.
Cc: Robert Richter <rrichter@marvell.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v9:
- No change.
Changes in v8:
- No change.
Changes in v7:
- No change.
Changes in v6:
- No change.
Changes in v5:
- No change.
Changes in v4:
- Minor change: Inline value '64' in code for better code readability.
Changes in v3:
- Change datatype of some variables from u64 to unsigned long
in function thunderx_gpio_set_multiple.
Changes in v2:
- No change.
drivers/gpio/gpio-thunderx.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..58c9bb25a377 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip *chip,
unsigned long *bits)
{
int bank;
- u64 set_bits, clear_bits;
+ unsigned long set_bits, clear_bits, gpio_mask;
+ unsigned long offset;
+
struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
- for (bank = 0; bank <= chip->ngpio / 64; bank++) {
- set_bits = bits[bank] & mask[bank];
- clear_bits = ~bits[bank] & mask[bank];
+ for_each_set_clump(offset, gpio_mask, mask, chip->ngpio, 64) {
+ bank = offset / 64;
+ set_bits = bits[bank] & gpio_mask;
+ clear_bits = ~bits[bank] & gpio_mask;
writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_SET);
writeq(clear_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_CLR);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value.
2020-06-27 8:09 [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
2020-06-27 8:13 ` [PATCH v9 3/4] gpio: thunderx: Utilize " Syed Nayyar Waris
@ 2020-06-27 8:14 ` Syed Nayyar Waris
2020-07-08 12:54 ` William Breathitt Gray
2020-07-10 8:04 ` [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
2020-07-16 12:49 ` Linus Walleij
3 siblings, 1 reply; 13+ messages in thread
From: Syed Nayyar Waris @ 2020-06-27 8:14 UTC (permalink / raw)
To: linus.walleij
Cc: andriy.shevchenko, vilhelm.gray, bgolaszewski, michal.simek,
linux-gpio, linux-arm-kernel, linux-kernel
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value.
2020-06-27 8:14 ` [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value Syed Nayyar Waris
@ 2020-07-08 12:54 ` William Breathitt Gray
0 siblings, 0 replies; 13+ messages in thread
From: William Breathitt Gray @ 2020-07-08 12:54 UTC (permalink / raw)
To: Syed Nayyar Waris
Cc: linus.walleij, andriy.shevchenko, bgolaszewski, michal.simek,
linux-gpio, linux-arm-kernel, linux-kernel
[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-06-27 8:09 [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
2020-06-27 8:13 ` [PATCH v9 3/4] gpio: thunderx: Utilize " Syed Nayyar Waris
2020-06-27 8:14 ` [PATCH v9 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value Syed Nayyar Waris
@ 2020-07-10 8:04 ` Syed Nayyar Waris
2020-07-16 12:49 ` Linus Walleij
3 siblings, 0 replies; 13+ messages in thread
From: Syed Nayyar Waris @ 2020-07-10 8:04 UTC (permalink / raw)
To: Linus Walleij, Andrew Morton
Cc: Andy Shevchenko, William Breathitt Gray, Michal Simek,
Arnd Bergmann, rrichter, Bartosz Golaszewski, Masahiro Yamada,
Zhang, Rui, Daniel Lezcano, Amit Kucheria, Linux-Arch,
open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
linux-arm Mailing List, Linux PM
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-06-27 8:09 [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
` (2 preceding siblings ...)
2020-07-10 8:04 ` [PATCH v9 0/4] Introduce the for_each_set_clump macro Syed Nayyar Waris
@ 2020-07-16 12:49 ` Linus Walleij
2020-08-31 15:37 ` Syed Nayyar Waris
2020-09-11 22:54 ` William Breathitt Gray
3 siblings, 2 replies; 13+ messages in thread
From: Linus Walleij @ 2020-07-16 12:49 UTC (permalink / raw)
To: Syed Nayyar Waris
Cc: Andy Shevchenko, William Breathitt Gray, Michal Simek,
Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
linux-arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-07-16 12:49 ` Linus Walleij
@ 2020-08-31 15:37 ` Syed Nayyar Waris
2020-09-11 22:54 ` William Breathitt Gray
1 sibling, 0 replies; 13+ messages in thread
From: Syed Nayyar Waris @ 2020-08-31 15:37 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, William Breathitt Gray, Michal Simek,
Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
Linux-Arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-07-16 12:49 ` Linus Walleij
2020-08-31 15:37 ` Syed Nayyar Waris
@ 2020-09-11 22:54 ` William Breathitt Gray
2020-09-29 12:45 ` Linus Walleij
1 sibling, 1 reply; 13+ messages in thread
From: William Breathitt Gray @ 2020-09-11 22:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Syed Nayyar Waris, akpm, Andy Shevchenko, Michal Simek,
Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
linux-arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-09-11 22:54 ` William Breathitt Gray
@ 2020-09-29 12:45 ` Linus Walleij
2020-09-29 13:07 ` William Breathitt Gray
0 siblings, 1 reply; 13+ messages in thread
From: Linus Walleij @ 2020-09-29 12:45 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Syed Nayyar Waris, Andrew Morton, Andy Shevchenko, Michal Simek,
Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
linux-arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-09-29 12:45 ` Linus Walleij
@ 2020-09-29 13:07 ` William Breathitt Gray
2020-09-29 13:14 ` Andy Shevchenko
0 siblings, 1 reply; 13+ messages in thread
From: William Breathitt Gray @ 2020-09-29 13:07 UTC (permalink / raw)
To: Linus Walleij
Cc: Syed Nayyar Waris, Andrew Morton, Andy Shevchenko, Michal Simek,
Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
linux-arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
[-- Attachment #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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-09-29 13:07 ` William Breathitt Gray
@ 2020-09-29 13:14 ` Andy Shevchenko
2020-09-30 9:29 ` Linus Walleij
0 siblings, 1 reply; 13+ messages in thread
From: Andy Shevchenko @ 2020-09-29 13:14 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Linus Walleij, Syed Nayyar Waris, Andrew Morton, Andy Shevchenko,
Michal Simek, Arnd Bergmann, Robert Richter, Bartosz Golaszewski,
Masahiro Yamada, Zhang Rui, Daniel Lezcano, Amit Kucheria,
Linux-Arch, open list:GPIO SUBSYSTEM, linux-kernel, Linux ARM,
Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-09-29 13:14 ` Andy Shevchenko
@ 2020-09-30 9:29 ` Linus Walleij
2020-10-02 20:58 ` Syed Nayyar Waris
0 siblings, 1 reply; 13+ messages in thread
From: Linus Walleij @ 2020-09-30 9:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: William Breathitt Gray, Syed Nayyar Waris, Andrew Morton,
Andy Shevchenko, Michal Simek, Arnd Bergmann, Robert Richter,
Bartosz Golaszewski, Masahiro Yamada, Zhang Rui, Daniel Lezcano,
Amit Kucheria, Linux-Arch, open list:GPIO SUBSYSTEM,
linux-kernel, Linux ARM, Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
2020-09-30 9:29 ` Linus Walleij
@ 2020-10-02 20:58 ` Syed Nayyar Waris
0 siblings, 0 replies; 13+ messages in thread
From: Syed Nayyar Waris @ 2020-10-02 20:58 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, William Breathitt Gray, Andrew Morton,
Andy Shevchenko, Michal Simek, Arnd Bergmann, Robert Richter,
Bartosz Golaszewski, Masahiro Yamada, Zhang Rui, Daniel Lezcano,
Amit Kucheria, Linux-Arch, open list:GPIO SUBSYSTEM,
linux-kernel, Linux ARM, Linux PM list
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
^ permalink raw reply [flat|nested] 13+ messages in thread