Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: pavel@ucw.cz, lee@kernel.org, sean.wang@mediatek.com,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, linux-leds@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com, llvm@lists.linux.dev
Subject: Re: [PATCH v3 8/8] leds: leds-mt6323: Add support for WLEDs and MT6332
Date: Wed, 21 Jun 2023 21:31:24 +0000	[thread overview]
Message-ID: <20230621213124.GA2689001@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20230601110813.2373764-9-angelogioacchino.delregno@collabora.com>

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@collabora.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;

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

  parent reply	other threads:[~2023-06-21 21:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 11:08 [PATCH v3 0/8] Add support for MT6331 and MT6332 LEDs AngeloGioacchino Del Regno
2023-06-01 11:08 ` [PATCH v3 1/8] dt-bindings: leds: leds-mt6323: Document mt6331 compatible AngeloGioacchino Del Regno
2023-06-09  6:40   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 2/8] dt-bindings: leds: leds-mt6323: Document mt6332 compatible AngeloGioacchino Del Regno
2023-06-09  6:41   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 3/8] dt-bindings: leds: leds-mt6323: Support WLED output AngeloGioacchino Del Regno
2023-06-02  8:32   ` Krzysztof Kozlowski
2023-06-09  6:42     ` Lee Jones
2023-06-09  7:51     ` AngeloGioacchino Del Regno
2023-06-13  6:59       ` Krzysztof Kozlowski
2023-06-14  8:33         ` AngeloGioacchino Del Regno
2023-06-01 11:08 ` [PATCH v3 4/8] leds: leds-mt6323: Specify registers and specs in platform data AngeloGioacchino Del Regno
2023-06-09  6:42   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 5/8] leds: leds-mt6323: Drop MT6323_ prefix from macros and defines AngeloGioacchino Del Regno
2023-06-09  6:43   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 6/8] leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro AngeloGioacchino Del Regno
2023-06-09  6:43   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 7/8] leds: leds-mt6323: Add support for MT6331 leds AngeloGioacchino Del Regno
2023-06-09  6:44   ` Lee Jones
2023-06-01 11:08 ` [PATCH v3 8/8] leds: leds-mt6323: Add support for WLEDs and MT6332 AngeloGioacchino Del Regno
2023-06-09  6:44   ` Lee Jones
2023-06-21 21:31   ` Nathan Chancellor [this message]
2023-06-22  9:10     ` AngeloGioacchino Del Regno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230621213124.GA2689001@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@collabora.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=matthias.bgg@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sean.wang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox