linux-kernel - Re: [PATCH] gpiolib: fix sysfs when cdev is not selected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHNNwZDiwKbhBgkOhStGip2+cMKOEBTUa13n2vuHrTc_nk2sMg@mail.gmail.com>
Date:   Thu, 5 Nov 2020 13:01:55 +0100
From:   Nicolas Schichan <nschichan@...ebox.fr>
To:     Kent Gibson <warthog618@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        bgolaszewski@...libre.com, linus.walleij@...aro.org
Subject: Re: [PATCH] gpiolib: fix sysfs when cdev is not selected

Hello Kent,

On Thu, Nov 5, 2020 at 11:41 AM Kent Gibson <warthog618@...il.com> wrote:
>
> In gpiochip_setup_dev() the call to gpiolib_cdev_register() indirectly
> calls device_add().  This is still required for the sysfs even when
> CONFIG_GPIO_CDEV is not selected in the build.
>
> Replace the stubbed functions in gpiolib-cdev.h with macros in gpiolib.c
> that perform the required device_add() and device_del() when
> CONFIG_GPIO_CDEV is not selected.
>
> Fixes: d143493c01b7 (gpiolib: make cdev a build option)
> Reported-by: Nicolas Schichan <nschichan@...ebox.fr>
> Signed-off-by: Kent Gibson <warthog618@...il.com>
> ---
>  drivers/gpio/gpiolib-cdev.h | 15 ---------------
>  drivers/gpio/gpiolib.c      | 18 +++++++++++++++---
>  2 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-cdev.h b/drivers/gpio/gpiolib-cdev.h
> index cb41dd757338..b42644cbffb8 100644
> --- a/drivers/gpio/gpiolib-cdev.h
> +++ b/drivers/gpio/gpiolib-cdev.h
> @@ -7,22 +7,7 @@
>
>  struct gpio_device;
>
> -#ifdef CONFIG_GPIO_CDEV
> -
>  int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt);
>  void gpiolib_cdev_unregister(struct gpio_device *gdev);
>
> -#else
> -
> -static inline int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt)
> -{
> -       return 0;
> -}
> -
> -static inline void gpiolib_cdev_unregister(struct gpio_device *gdev)
> -{
> -}
> -
> -#endif /* CONFIG_GPIO_CDEV */
> -
>  #endif /* GPIOLIB_CDEV_H */
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 8e29a60c3697..c980ddcda833 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -480,11 +480,23 @@ static void gpiodevice_release(struct device *dev)
>         kfree(gdev);
>  }
>
> +#ifdef CONFIG_GPIO_CDEV
> +#define gcdev_register(gdev, devt)     gpiolib_cdev_register((gdev), (devt))
> +#define gcdev_unregister(gdev)         gpiolib_cdev_unregister((gdev))
> +#else
> +/*
> + * gpiolib_cdev_register() indirectly calls device_add(), which is still
> + * required even when cdev is not selected.
> + */
> +#define gcdev_register(gdev, devt)     device_add(&(gdev)->dev)
> +#define gcdev_unregister(gdev)         device_del(&(gdev)->dev)
> +#endif
> +
>  static int gpiochip_setup_dev(struct gpio_device *gdev)
>  {
>         int ret;
>
> -       ret = gpiolib_cdev_register(gdev, gpio_devt);
> +       ret = gcdev_register(gdev, gpio_devt);
>         if (ret)
>                 return ret;
>
> @@ -500,7 +512,7 @@ static int gpiochip_setup_dev(struct gpio_device *gdev)
>         return 0;
>
>  err_remove_device:
> -       gpiolib_cdev_unregister(gdev);
> +       gcdev_unregister(gdev);
>         return ret;
>  }
>
> @@ -825,7 +837,7 @@ void gpiochip_remove(struct gpio_chip *gc)
>          * be removed, else it will be dangling until the last user is
>          * gone.
>          */
> -       gpiolib_cdev_unregister(gdev);
> +       gcdev_unregister(gdev);
>         put_device(&gdev->dev);
>  }
>  EXPORT_SYMBOL_GPL(gpiochip_remove);
> --
> 2.29.2
>

I have tested your patch and it works for both CONFIG_GPIO_CDEV set and unset.

Tested-by: Nicolas Schichan <nschichan@...ebox.fr>

Regards,

-- 
Nicolas Schichan
Freebox SAS