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

[Greg Kroah-Hartman]

On Sat, Jul 06, 2019 at 10:39:38AM -0700, Dmitry Torokhov wrote:
> On Sat, Jul 6, 2019 at 10:19 AM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sat, Jul 06, 2019 at 10:04:39AM -0700, Dmitry Torokhov wrote:
> > > Hi Greg,
> > >
> > > On Sat, Jul 6, 2019 at 1:32 AM Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > 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@xxxxxxxxxxxxxxxxxxx> 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.
> > >
> > > I believe that your assertion that only platform devices want to
> > > install custom attributes is incorrect.
> >
> > Sorry, I didn't mean to imply that only platform drivers want to do
> > this, as you say, many other drivers do as well.
> >
> > > Drivers for devices attached
> > > to serio, i2c, USB, spi, etc, etc, all have additional attributes:
> > >
> > > dtor@dtor-ws:~/kernel/work (master *)$ grep -l '\(i2c\|usb\|spi\)'
> > > `git grep -l '\(device_add_group\|sysfs_create_group\)' -- drivers` |
> > > wc -l
> > > 170
> > >
> > > I am pretty sure some of this count is false positives, but majority
> > > is actually proper hits.
> >
> > Yeah, I know, we need to add this type of functionality to those busses
> > as well.  I don't see a way of doing it other than this bus-by-bus
> > conversion, do you?
> 
> Can't you push the **dev_groups from platform driver down to the
> generic driver structure and handle them in driver_sysfs_add()?

Sorry for the delay, got busy with the merge window...

Anyway, no, we can't call this then, because driver_sysfs_add() is
called before probe() is called.  So if probe() fails, we don't bind the
device to the driver.  We also should not be creating sysfs files for a
driver that has not had probe() called yet, as internal structures will
not be set up at that time.

> > > > > 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?
> > >
> > > Not for the new functionality, I do not think so. Newer kernels should
> > > be compatible with older userspace as it not breaking it, but new
> > > functionality is not guaranteed to be available with older userspace.
> >
> > I agree, but again, this is a kobject change (adding attributes), so
> > I think the event type I picked here is the correct one.
> 
> I guess once you push it all into core you'll end up with 2 uevents
> being emitted back-to-back and this seems inefficient.

It's not the nicest, I agree.  But, this is not all that common for
drivers to do, so it should not happen often enough to cause many
issues.  Not all devices in the system will have this happen for them.

> If you really want KOBJ_CHANGE maybe have some additional attribute
> like "CHANGE=driver-specific-attrs" in it? It's all quite ugly though.

What would that addition help out with?  You still need to rescan the
device attributes no matter what.  Trying to compare a list of
attributes with what is "new" is probably slower than just reading them
all over again "from scratch".

thanks,

greg k-h