[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230621213124.GA2689001@dev-arch.thelio-3990X>
Date: Wed, 21 Jun 2023 21:31:24 +0000
From: Nathan Chancellor <nathan@...nel.org>
To: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
Cc: pavel@....cz, lee@...nel.org, sean.wang@...iatek.com,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
matthias.bgg@...il.com, linux-leds@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
kernel@...labora.com, llvm@...ts.linux.dev
Subject: Re: [PATCH v3 8/8] leds: leds-mt6323: Add support for WLEDs and
MT6332
Hi Angelo,
On Thu, Jun 01, 2023 at 01:08:13PM +0200, AngeloGioacchino Del Regno wrote:
> Add basic code to turn on and off WLEDs and wire up MT6332 support
> to take advantage of it.
> This is a simple approach due to the aforementioned PMIC supporting
> only on/off status so, at the time of writing, it is impossible for me
> to validate more advanced functionality due to lack of hardware.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
After this patch as commit 9bb0a9e0626c ("leds: leds-mt6323: Add support
for WLEDs and MT6332") in -next, I see the following warnings from
clang, which are basically flagging potential kernel Control Flow
Integrity [1] violations that will be visible at runtime (this warning
is not enabled for the kernel yet but we would like it to be):
drivers/leds/leds-mt6323.c:598:49: error: incompatible function pointer types assigning to 'int (*)(struct led_classdev *, enum led_brightness)' from 'int (struct led_classdev *, unsigned int)' [-Werror,-Wincompatible-function-pointer-types-strict]
598 | leds->led[reg]->cdev.brightness_set_blocking =
| ^
599 | mt6323_wled_set_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/leds/leds-mt6323.c:600:40: error: incompatible function pointer types assigning to 'enum led_brightness (*)(struct led_classdev *)' from 'unsigned int (struct led_classdev *)' [-Werror,-Wincompatible-function-pointer-types-strict]
600 | leds->led[reg]->cdev.brightness_get =
| ^
601 | mt6323_get_wled_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
>From what I can tell/understand, 'enum led_brightness' is obsolete and
the value that is passed via ->brightness_set_blocking() is an 'unsigned
int' as well but it seems 'enum led_brightness' is used as the parameter
in a lot of different callback implementations, so the prototype cannot
be easily updated without a lot of extra work. Is there any reason not
to just do something like this to avoid this issue?
[1]: https://lwn.net/Articles/898040/
Cheers,
Nathan
diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
index e8fecfc2e90a..24f35bdb55fb 100644
--- a/drivers/leds/leds-mt6323.c
+++ b/drivers/leds/leds-mt6323.c
@@ -76,7 +76,7 @@ struct mt6323_led {
int id;
struct mt6323_leds *parent;
struct led_classdev cdev;
- unsigned int current_brightness;
+ enum led_brightness current_brightness;
};
/**
@@ -451,7 +451,7 @@ static int mtk_wled_hw_off(struct led_classdev *cdev)
return 0;
}
-static unsigned int mt6323_get_wled_brightness(struct led_classdev *cdev)
+static enum led_brightness mt6323_get_wled_brightness(struct led_classdev *cdev)
{
struct mt6323_led *led = container_of(cdev, struct mt6323_led, cdev);
struct mt6323_leds *leds = led->parent;
@@ -471,7 +471,7 @@ static unsigned int mt6323_get_wled_brightness(struct led_classdev *cdev)
}
static int mt6323_wled_set_brightness(struct led_classdev *cdev,
- unsigned int brightness)
+ enum led_brightness brightness)
{
struct mt6323_led *led = container_of(cdev, struct mt6323_led, cdev);
struct mt6323_leds *leds = led->parent;
Powered by blists - more mailing lists