drivers/leds/leds-lp5569.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Hi all,
After merging the leds-lj tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/leds/leds-lp5569.c:11:
drivers/leds/leds-lp5569.c: In function 'lp5569_post_init_device':
drivers/leds/leds-lp5569.c:204:52: error: passing argument 3 of 'lp55xx_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
204 | chip, LP5569_REG_STATUS, &val);
| ^~~~
| |
| int *
include/linux/iopoll.h:46:28: note: in definition of macro 'read_poll_timeout'
46 | (val) = op(args); \
| ^~~~
In file included from drivers/leds/leds-lp5569.c:20:
drivers/leds/leds-lp55xx-common.h:229:62: note: expected 'u8 *' {aka 'unsigned char *'} but argument is of type 'int *'
229 | extern int lp55xx_read(struct lp55xx_chip *chip, u8 reg, u8 *val);
| ~~~~^~~
drivers/leds/leds-lp5569.c:204:52: error: passing argument 3 of 'lp55xx_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
204 | chip, LP5569_REG_STATUS, &val);
| ^~~~
| |
| int *
include/linux/iopoll.h:51:36: note: in definition of macro 'read_poll_timeout'
51 | (val) = op(args); \
| ^~~~
drivers/leds/leds-lp55xx-common.h:229:62: note: expected 'u8 *' {aka 'unsigned char *'} but argument is of type 'int *'
229 | extern int lp55xx_read(struct lp55xx_chip *chip, u8 reg, u8 *val);
| ~~~~^~~
cc1: all warnings being treated as errors
Caused by commit
d9cc80b1c9b4 ("leds: leds-lp5569: Enable chip after chip configuration")
I have applied the folloing patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Jul 2024 14:40:23 +1000
Subject: [PATCH] fixup for "leds: leds-lp5569: Enable chip after chip configuration"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/leds/leds-lp5569.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lp5569.c b/drivers/leds/leds-lp5569.c
index 52fb83f35bb7..623030f2f5ac 100644
--- a/drivers/leds/leds-lp5569.c
+++ b/drivers/leds/leds-lp5569.c
@@ -173,6 +173,7 @@ static int lp5569_post_init_device(struct lp55xx_chip *chip)
{
int ret;
int val;
+ u8 u8val;
val = LP5569_DEFAULT_CONFIG;
val |= FIELD_PREP(LP5569_CP_MODE_MASK, chip->pdata->charge_pump_mode);
@@ -201,7 +202,7 @@ static int lp5569_post_init_device(struct lp55xx_chip *chip)
read_poll_timeout(lp55xx_read, ret, !(val & LP5569_STARTUP_BUSY),
LP5569_STARTUP_SLEEP, LP5569_STARTUP_SLEEP * 10, false,
- chip, LP5569_REG_STATUS, &val);
+ chip, LP5569_REG_STATUS, &u8val);
return lp5569_init_program_engine(chip);
}
--
2.43.0
--
Cheers,
Stephen Rothwell
Christian, > Hi all, > > After merging the leds-lj tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from drivers/leds/leds-lp5569.c:11: > drivers/leds/leds-lp5569.c: In function 'lp5569_post_init_device': > drivers/leds/leds-lp5569.c:204:52: error: passing argument 3 of 'lp55xx_read' from incompatible pointer type [-Werror=incompatible-pointer-types] > 204 | chip, LP5569_REG_STATUS, &val); > | ^~~~ > | | > | int * The only reason for applying this set this late in the cycle was that they appeared to be fixes for other brokenness. This is the second set that you've submitted in recent days that has caused build breakages. Something is wrong with your current development practices. Are you able to identify and rectify these issue(s) before a lose trust in your submissions? -- Lee Jones [李琼斯]
On Fri, Jul 12, 2024 at 08:31:39AM +0100, Lee Jones wrote: > Christian, > > > Hi all, > > > > After merging the leds-lj tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > In file included from drivers/leds/leds-lp5569.c:11: > > drivers/leds/leds-lp5569.c: In function 'lp5569_post_init_device': > > drivers/leds/leds-lp5569.c:204:52: error: passing argument 3 of 'lp55xx_read' from incompatible pointer type [-Werror=incompatible-pointer-types] > > 204 | chip, LP5569_REG_STATUS, &val); > > | ^~~~ > > | | > > | int * > > The only reason for applying this set this late in the cycle was that > they appeared to be fixes for other brokenness. > > This is the second set that you've submitted in recent days that has > caused build breakages. Something is wrong with your current > development practices. Are you able to identify and rectify these > issue(s) before a lose trust in your submissions? > Yes, I identified the problem and the config was silently getting disabled and hiding all the errors/warning. Driver also was tested on OpenWrt build system where the option WERROR wasn't enabled as I was devloping other stuff so this added on top of it of not noticing stuff. I promise this won't ever happen again. Also I sent v2 for this hoping things can get reverted and the correct series can be applied. If not I can quickly send a followup that fix this. I verified with the repro that the warning/error gets solved. (it's just channging the int to u8) -- Ansuel
On Fri, 12 Jul 2024, Christian Marangi wrote: > On Fri, Jul 12, 2024 at 08:31:39AM +0100, Lee Jones wrote: > > Christian, > > > > > Hi all, > > > > > > After merging the leds-lj tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > In file included from drivers/leds/leds-lp5569.c:11: > > > drivers/leds/leds-lp5569.c: In function 'lp5569_post_init_device': > > > drivers/leds/leds-lp5569.c:204:52: error: passing argument 3 of 'lp55xx_read' from incompatible pointer type [-Werror=incompatible-pointer-types] > > > 204 | chip, LP5569_REG_STATUS, &val); > > > | ^~~~ > > > | | > > > | int * > > > > The only reason for applying this set this late in the cycle was that > > they appeared to be fixes for other brokenness. > > > > This is the second set that you've submitted in recent days that has > > caused build breakages. Something is wrong with your current > > development practices. Are you able to identify and rectify these > > issue(s) before a lose trust in your submissions? > > > > Yes, I identified the problem and the config was silently getting > disabled and hiding all the errors/warning. Driver also was tested on > OpenWrt build system where the option WERROR wasn't enabled as I was > devloping other stuff so this added on top of it of not noticing stuff. > > I promise this won't ever happen again. Also I sent v2 for this hoping > things can get reverted and the correct series can be applied. If not I > can quickly send a followup that fix this. I verified with the repro > that the warning/error gets solved. (it's just channging the int to u8) No need to follow up. I've applied the new set and sent for pre-testing. Once passed, I'll push so it'll end up in -next again. -- Lee Jones [李琼斯]
© 2016 - 2025 Red Hat, Inc.