[PATCH] leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks

Nick Desaulniers ndesaulniers at google.com
Thu Jun 22 09:43:09 PDT 2023


On Thu, Jun 22, 2023 at 9:12 AM Nathan Chancellor <nathan at kernel.org> wrote:
>
> Clang's kernel Control Flow Integrity (kCFI) is a compiler-based
> security mitigation that ensures the target of an indirect function call
> matches the expected type of the call and trapping if they do not match
> exactly. The warning -Wincompatible-function-pointer-types-strict aims
> to catch these issues at compile time, which reveals:
>
>  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.
>
> While 'unsigned int' is ABI compatible with 'enum led_brightness' (hence
> no warning from -Wincompatible-function-pointer-types) and the callers
> of these callbacks use/pass the values as 'unsigned int', the mismatch
> between the prototype and the called function will trip kCFI at runtime.
>
> Change the types in the implementations to match the prototypes, clearing
> up the warning and avoiding kCFI failures.
>
> Fixes: 9bb0a9e0626c ("leds: leds-mt6323: Add support for WLEDs and MT6332")
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>

Thanks for the patch! Consider additionally having
mt6323_get_wled_brightness return LED_OFF rather than 0 in its
ternary.
Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>


> ---
>  drivers/leds/leds-mt6323.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> 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;
>
> ---
> base-commit: 7bd932d9adbcc5c5370d968bdb0b00385606bf3a
> change-id: 20230621-mt6323-wled-wincompatible-function-pointer-types-strict-334f06d92ffb
>
> Best regards,
> --
> Nathan Chancellor <nathan at kernel.org>
>
>


-- 
Thanks,
~Nick Desaulniers



More information about the linux-arm-kernel mailing list