Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Jul 04, 2019 at 02:17:22PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
> 
> On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.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.

This is not limited to the platform at all, the driver core supports
this for any bus type today, but it's then up to the bus-specific code
to pass that on to the driver core.  That's usually set for the
bus-specific attributes that they want exposed for all devices of that
bus type (see the bus_groups, dev_groups, and drv_groups pointers in
struct bus_type).

For the platform devices, the problem is that this is something that the
individual drivers want after they bind to the device.  And as all
platform devices are "different" they can't be a "common" set of
attributes, so they need to be created after the device is bound to the
driver.

> > Cc: Richard Gong <richard.gong@linux.intel.com>
> > Cc: Romain Izard <romain.izard.pro@gmail.com>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Mans Rullgard <mans@mansr.com>
> > Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > Cc: Randy Dunlap <rdunlap@infradead.org>
> > Cc: Johan Hovold <johan@kernel.org>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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.

But the object's attributes did just change, which is what KOBJ_CHANGE
tells userspace, so this should be the correct thing to say to
userspace.

And yes, ideally KOBJ_BIND would be handled, and it will be sent once
the device's probe function succeeds, but we have to deal with old
userspaces as well, right?

thanks,

greg k-h