linux-kernel - Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform

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: <CAKdAkRQ4W7wjYjZcBn4_s+PD26pv_8mrjUt-ne24GkimGEXoiA@mail.gmail.com>
Date:   Thu, 4 Jul 2019 14:17:22 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Johan Hovold <johan@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Richard Gong <richard.gong@...ux.intel.com>,
        Romain Izard <romain.izard.pro@...il.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mans Rullgard <mans@...sr.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver

Hi Greg,

On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> Platform drivers like to add sysfs groups to their device, but right now
> they have to do it "by hand".  The driver core should handle this for
> them, but there is no way to get to the bus-default attribute groups as
> all platform devices are "special and unique" one-off drivers/devices.
>
> To combat this, add a dev_groups pointer to platform_driver which allows
> a platform driver to set up a list of default attributes that will be
> properly created and removed by the platform driver core when a probe()
> function is successful and removed right before the device is unbound.

Why is this limited to platform bus? Drivers for other buses also
often want to augment list of their attributes during probe(). I'd
move it to generic probe handling.

>
> Cc: Richard Gong <richard.gong@...ux.intel.com>
> Cc: Romain Izard <romain.izard.pro@...il.com>
> Cc: "Rafael J. Wysocki" <rafael@...nel.org>
> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: Mans Rullgard <mans@...sr.com>
> Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>
> Cc: Randy Dunlap <rdunlap@...radead.org>
> Cc: Johan Hovold <johan@...nel.org>
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
> v2: addressed Johan's comments by reordering when we remove the files
>     from the device, and clean up on an error in a nicer way.  Ended up
>     making the patch smaller overall, always nice.
>
>  drivers/base/platform.c         | 16 +++++++++++++++-
>  include/linux/platform_device.h |  1 +
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 713903290385..74428a1e03f3 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -614,8 +614,20 @@ static int platform_drv_probe(struct device *_dev)
>
>         if (drv->probe) {
>                 ret = drv->probe(dev);
> -               if (ret)
> +               if (ret) {
> +                       dev_pm_domain_detach(_dev, true);
> +                       goto out;
> +               }
> +       }
> +       if (drv->dev_groups) {
> +               ret = device_add_groups(_dev, drv->dev_groups);
> +               if (ret) {
> +                       if (drv->remove)
> +                               drv->remove(dev);
>                         dev_pm_domain_detach(_dev, true);
> +                       return ret;
> +               }
> +               kobject_uevent(&_dev->kobj, KOBJ_CHANGE);

We already emit KOBJ_BIND when we finish binding device to a driver,
regardless of the bus. I know we still need to teach systemd to handle
it properly, but I think it is better than sprinkling KOBJ_CHANGE
around.

Thanks.

-- 
Dmitry