Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2017-06-17 Thread Greg Kroah-Hartman 
On Wed, Jun 07, 2017 at 10:12:08AM -0700, Dmitry Torokhov wrote:
> On Fri, Nov 06, 2015 at 11:23:37PM -0800, Dmitry Torokhov wrote:
> > On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > > > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > > > Many drivers create additional driver-specific device attributes 
> > > > > > when
> > > > > > binding to the device and providing managed version of 
> > > > > > sysfs_create_group()
> > > > > > will simplify unbinding and error handling in probe path for such 
> > > > > > drivers.
> > > > > 
> > > > > But they really shouldn't, because if they do this, they have raced
> > > > > userspace and tools don't know that the files are present.
> > > > > 
> > > > > I don't want to encourage drivers to do this at all, so I don't want 
> > > > > to
> > > > > make it easier for them to do things incorrectly.
> > > > 
> > > > The solution is not to forbid drivers from establishing attributes but
> > > > rather notify userspace when device is fully bound to the driver. Then
> > > > userspace that actually cares about these attributes will listen to
> > > > proper events.
> > > > 
> > > > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > > > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> > > 
> > > bound/unbound makes a bit more sense, maybe that would work, haven't
> > > thought that much about it.  Given that no one in the "real world" seem
> > > to notice the race condition, that means that people aren't really using
> > > tools like libudev to read sysfs attributes, so maybe no one even cares
> > > about the contents of them :)
> > 
> > Could be, or they have workarounds for this scenario.
> 
> So I have another concrete use-case for this feature: firmware updating.
> 
> Several touch controllers may come up in either normal (application) or
> boot mode, depending on whether firmware/configuration is corrupted or
> not when they are powered on. In boot mode we do not create input
> device instance (because we do not necessarily know the characteristics
> of the input device in question).
> 
> I would like to have firmware update scripts to be fired via udev. The
> scripts would check the current firmware version and state of the device
> and decide whether they need to update firmware or not. To do that they
> need to have driver bound to the physical device (i2c or spi), and
> therefore I can't rely on ADD events as those happen too early. Having
> the BOUND/UNBOUND events will allow me to do this cleanly.

Yeah, this is what convinced me we need this.  The act of
binding/unbinding a driver to a device is a state change for the device,
and userspace should learn about it.

> I will look into using this mechanism on chrome OS.

If you resend the patches, I can work on adding support for it in
libudev to see how that works out as well.

thanks,

greg k-h

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2017-06-17 Thread Greg Kroah-Hartman 
On Wed, Jun 07, 2017 at 10:12:08AM -0700, Dmitry Torokhov wrote:
> On Fri, Nov 06, 2015 at 11:23:37PM -0800, Dmitry Torokhov wrote:
> > On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > > > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > > > Many drivers create additional driver-specific device attributes 
> > > > > > when
> > > > > > binding to the device and providing managed version of 
> > > > > > sysfs_create_group()
> > > > > > will simplify unbinding and error handling in probe path for such 
> > > > > > drivers.
> > > > > 
> > > > > But they really shouldn't, because if they do this, they have raced
> > > > > userspace and tools don't know that the files are present.
> > > > > 
> > > > > I don't want to encourage drivers to do this at all, so I don't want 
> > > > > to
> > > > > make it easier for them to do things incorrectly.
> > > > 
> > > > The solution is not to forbid drivers from establishing attributes but
> > > > rather notify userspace when device is fully bound to the driver. Then
> > > > userspace that actually cares about these attributes will listen to
> > > > proper events.
> > > > 
> > > > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > > > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> > > 
> > > bound/unbound makes a bit more sense, maybe that would work, haven't
> > > thought that much about it.  Given that no one in the "real world" seem
> > > to notice the race condition, that means that people aren't really using
> > > tools like libudev to read sysfs attributes, so maybe no one even cares
> > > about the contents of them :)
> > 
> > Could be, or they have workarounds for this scenario.
> 
> So I have another concrete use-case for this feature: firmware updating.
> 
> Several touch controllers may come up in either normal (application) or
> boot mode, depending on whether firmware/configuration is corrupted or
> not when they are powered on. In boot mode we do not create input
> device instance (because we do not necessarily know the characteristics
> of the input device in question).
> 
> I would like to have firmware update scripts to be fired via udev. The
> scripts would check the current firmware version and state of the device
> and decide whether they need to update firmware or not. To do that they
> need to have driver bound to the physical device (i2c or spi), and
> therefore I can't rely on ADD events as those happen too early. Having
> the BOUND/UNBOUND events will allow me to do this cleanly.

Yeah, this is what convinced me we need this.  The act of
binding/unbinding a driver to a device is a state change for the device,
and userspace should learn about it.

> I will look into using this mechanism on chrome OS.

If you resend the patches, I can work on adding support for it in
libudev to see how that works out as well.

thanks,

greg k-h

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2017-06-07 Thread Dmitry Torokhov 
On Fri, Nov 06, 2015 at 11:23:37PM -0800, Dmitry Torokhov wrote:
> On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> > On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > > Many drivers create additional driver-specific device attributes when
> > > > > binding to the device and providing managed version of 
> > > > > sysfs_create_group()
> > > > > will simplify unbinding and error handling in probe path for such 
> > > > > drivers.
> > > > 
> > > > But they really shouldn't, because if they do this, they have raced
> > > > userspace and tools don't know that the files are present.
> > > > 
> > > > I don't want to encourage drivers to do this at all, so I don't want to
> > > > make it easier for them to do things incorrectly.
> > > 
> > > The solution is not to forbid drivers from establishing attributes but
> > > rather notify userspace when device is fully bound to the driver. Then
> > > userspace that actually cares about these attributes will listen to
> > > proper events.
> > > 
> > > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> > 
> > bound/unbound makes a bit more sense, maybe that would work, haven't
> > thought that much about it.  Given that no one in the "real world" seem
> > to notice the race condition, that means that people aren't really using
> > tools like libudev to read sysfs attributes, so maybe no one even cares
> > about the contents of them :)
> 
> Could be, or they have workarounds for this scenario.

So I have another concrete use-case for this feature: firmware updating.

Several touch controllers may come up in either normal (application) or
boot mode, depending on whether firmware/configuration is corrupted or
not when they are powered on. In boot mode we do not create input
device instance (because we do not necessarily know the characteristics
of the input device in question).

I would like to have firmware update scripts to be fired via udev. The
scripts would check the current firmware version and state of the device
and decide whether they need to update firmware or not. To do that they
need to have driver bound to the physical device (i2c or spi), and
therefore I can't rely on ADD events as those happen too early. Having
the BOUND/UNBOUND events will allow me to do this cleanly.

I will look into using this mechanism on chrome OS.

Thanks.

-- 
Dmitry

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2017-06-07 Thread Dmitry Torokhov 
On Fri, Nov 06, 2015 at 11:23:37PM -0800, Dmitry Torokhov wrote:
> On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> > On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > > Many drivers create additional driver-specific device attributes when
> > > > > binding to the device and providing managed version of 
> > > > > sysfs_create_group()
> > > > > will simplify unbinding and error handling in probe path for such 
> > > > > drivers.
> > > > 
> > > > But they really shouldn't, because if they do this, they have raced
> > > > userspace and tools don't know that the files are present.
> > > > 
> > > > I don't want to encourage drivers to do this at all, so I don't want to
> > > > make it easier for them to do things incorrectly.
> > > 
> > > The solution is not to forbid drivers from establishing attributes but
> > > rather notify userspace when device is fully bound to the driver. Then
> > > userspace that actually cares about these attributes will listen to
> > > proper events.
> > > 
> > > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> > 
> > bound/unbound makes a bit more sense, maybe that would work, haven't
> > thought that much about it.  Given that no one in the "real world" seem
> > to notice the race condition, that means that people aren't really using
> > tools like libudev to read sysfs attributes, so maybe no one even cares
> > about the contents of them :)
> 
> Could be, or they have workarounds for this scenario.

So I have another concrete use-case for this feature: firmware updating.

Several touch controllers may come up in either normal (application) or
boot mode, depending on whether firmware/configuration is corrupted or
not when they are powered on. In boot mode we do not create input
device instance (because we do not necessarily know the characteristics
of the input device in question).

I would like to have firmware update scripts to be fired via udev. The
scripts would check the current firmware version and state of the device
and decide whether they need to update firmware or not. To do that they
need to have driver bound to the physical device (i2c or spi), and
therefore I can't rely on ADD events as those happen too early. Having
the BOUND/UNBOUND events will allow me to do this cleanly.

I will look into using this mechanism on chrome OS.

Thanks.

-- 
Dmitry

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-11-06 Thread Dmitry Torokhov 
On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > Many drivers create additional driver-specific device attributes when
> > > > binding to the device and providing managed version of 
> > > > sysfs_create_group()
> > > > will simplify unbinding and error handling in probe path for such 
> > > > drivers.
> > > 
> > > But they really shouldn't, because if they do this, they have raced
> > > userspace and tools don't know that the files are present.
> > > 
> > > I don't want to encourage drivers to do this at all, so I don't want to
> > > make it easier for them to do things incorrectly.
> > 
> > The solution is not to forbid drivers from establishing attributes but
> > rather notify userspace when device is fully bound to the driver. Then
> > userspace that actually cares about these attributes will listen to
> > proper events.
> > 
> > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> 
> bound/unbound makes a bit more sense, maybe that would work, haven't
> thought that much about it.  Given that no one in the "real world" seem
> to notice the race condition, that means that people aren't really using
> tools like libudev to read sysfs attributes, so maybe no one even cares
> about the contents of them :)

Could be, or they have workarounds for this scenario.

> 
> > > Yes, I know that input does this for its devices, but I still think it
> > > is wrong and should be changed.  Let's not let this problem spread to
> > > other subsystems please.
> > 
> > Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> > drivers and so on? Where are platform devices supposed to create their
> > attributes? There are more than 300 drivers that add new groups and 581
> > instance of device_create_file().
> 
> Platform drivers are the main problem right now, I don't know what to do
> about them.  I hate those things :(
> 
> > Let's be realistic here and see that additional attributes are not going
> > anywhere and adding devm interface just helps getting error handling
> > right.
> 
> But the files are already removed from the system when the device is
> removed,

In this case the device to which we attach attributes is not removed
though, it is still present in the system.

> so with the exception of the odd error path on probe, this
> isn't doing much.  Does it save much code when used?

It basically allows replacing code like:

static void rohm_ts_remove_sysfs_group(void *_dev)
{
struct device *dev = _dev;

sysfs_remove_group(>kobj, _ts_attr_group);
}

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = sysfs_create_group(>kobj, _ts_attr_group);
if (error) {
dev_err(dev, "failed to create sysfs group: %d\n", error);
return error;
}

error = devm_add_action(dev, rohm_ts_remove_sysfs_group, dev);
if (error) {
rohm_ts_remove_sysfs_group(dev);
dev_err(>dev,
"Failed to add sysfs cleanup action: %d\n",
error);
return error;
}

...
}

with:

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = devm_sysfs_create_group(dev, rohm_ts_attr_group);
if (error)
return error;

...
}

which is arguable much more compact.

That assuming that the driver is using devm construct. In case driver
used goto error unwinding it really depends at what point the attributes
were created, but I strongly advise against mixing devm and goto
unwinding in one driver as it leads to confusion as to what strategy a
given resource is using, manual or devm?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-11-06 Thread Greg Kroah-Hartman 
On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > Many drivers create additional driver-specific device attributes when
> > > binding to the device and providing managed version of 
> > > sysfs_create_group()
> > > will simplify unbinding and error handling in probe path for such drivers.
> > 
> > But they really shouldn't, because if they do this, they have raced
> > userspace and tools don't know that the files are present.
> > 
> > I don't want to encourage drivers to do this at all, so I don't want to
> > make it easier for them to do things incorrectly.
> 
> The solution is not to forbid drivers from establishing attributes but
> rather notify userspace when device is fully bound to the driver. Then
> userspace that actually cares about these attributes will listen to
> proper events.
> 
> We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).

bound/unbound makes a bit more sense, maybe that would work, haven't
thought that much about it.  Given that no one in the "real world" seem
to notice the race condition, that means that people aren't really using
tools like libudev to read sysfs attributes, so maybe no one even cares
about the contents of them :)

> > Yes, I know that input does this for its devices, but I still think it
> > is wrong and should be changed.  Let's not let this problem spread to
> > other subsystems please.
> 
> Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> drivers and so on? Where are platform devices supposed to create their
> attributes? There are more than 300 drivers that add new groups and 581
> instance of device_create_file().

Platform drivers are the main problem right now, I don't know what to do
about them.  I hate those things :(

> Let's be realistic here and see that additional attributes are not going
> anywhere and adding devm interface just helps getting error handling
> right.

But the files are already removed from the system when the device is
removed, so with the exception of the odd error path on probe, this
isn't doing much.  Does it save much code when used?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-11-06 Thread Greg Kroah-Hartman 
On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > Many drivers create additional driver-specific device attributes when
> > > binding to the device and providing managed version of 
> > > sysfs_create_group()
> > > will simplify unbinding and error handling in probe path for such drivers.
> > 
> > But they really shouldn't, because if they do this, they have raced
> > userspace and tools don't know that the files are present.
> > 
> > I don't want to encourage drivers to do this at all, so I don't want to
> > make it easier for them to do things incorrectly.
> 
> The solution is not to forbid drivers from establishing attributes but
> rather notify userspace when device is fully bound to the driver. Then
> userspace that actually cares about these attributes will listen to
> proper events.
> 
> We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).

bound/unbound makes a bit more sense, maybe that would work, haven't
thought that much about it.  Given that no one in the "real world" seem
to notice the race condition, that means that people aren't really using
tools like libudev to read sysfs attributes, so maybe no one even cares
about the contents of them :)

> > Yes, I know that input does this for its devices, but I still think it
> > is wrong and should be changed.  Let's not let this problem spread to
> > other subsystems please.
> 
> Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> drivers and so on? Where are platform devices supposed to create their
> attributes? There are more than 300 drivers that add new groups and 581
> instance of device_create_file().

Platform drivers are the main problem right now, I don't know what to do
about them.  I hate those things :(

> Let's be realistic here and see that additional attributes are not going
> anywhere and adding devm interface just helps getting error handling
> right.

But the files are already removed from the system when the device is
removed, so with the exception of the odd error path on probe, this
isn't doing much.  Does it save much code when used?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-11-06 Thread Dmitry Torokhov 
On Fri, Nov 06, 2015 at 04:24:07PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 08:13:11AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > > > Many drivers create additional driver-specific device attributes when
> > > > binding to the device and providing managed version of 
> > > > sysfs_create_group()
> > > > will simplify unbinding and error handling in probe path for such 
> > > > drivers.
> > > 
> > > But they really shouldn't, because if they do this, they have raced
> > > userspace and tools don't know that the files are present.
> > > 
> > > I don't want to encourage drivers to do this at all, so I don't want to
> > > make it easier for them to do things incorrectly.
> > 
> > The solution is not to forbid drivers from establishing attributes but
> > rather notify userspace when device is fully bound to the driver. Then
> > userspace that actually cares about these attributes will listen to
> > proper events.
> > 
> > We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
> > KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).
> 
> bound/unbound makes a bit more sense, maybe that would work, haven't
> thought that much about it.  Given that no one in the "real world" seem
> to notice the race condition, that means that people aren't really using
> tools like libudev to read sysfs attributes, so maybe no one even cares
> about the contents of them :)

Could be, or they have workarounds for this scenario.

> 
> > > Yes, I know that input does this for its devices, but I still think it
> > > is wrong and should be changed.  Let's not let this problem spread to
> > > other subsystems please.
> > 
> > Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
> > drivers and so on? Where are platform devices supposed to create their
> > attributes? There are more than 300 drivers that add new groups and 581
> > instance of device_create_file().
> 
> Platform drivers are the main problem right now, I don't know what to do
> about them.  I hate those things :(
> 
> > Let's be realistic here and see that additional attributes are not going
> > anywhere and adding devm interface just helps getting error handling
> > right.
> 
> But the files are already removed from the system when the device is
> removed,

In this case the device to which we attach attributes is not removed
though, it is still present in the system.

> so with the exception of the odd error path on probe, this
> isn't doing much.  Does it save much code when used?

It basically allows replacing code like:

static void rohm_ts_remove_sysfs_group(void *_dev)
{
struct device *dev = _dev;

sysfs_remove_group(>kobj, _ts_attr_group);
}

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = sysfs_create_group(>kobj, _ts_attr_group);
if (error) {
dev_err(dev, "failed to create sysfs group: %d\n", error);
return error;
}

error = devm_add_action(dev, rohm_ts_remove_sysfs_group, dev);
if (error) {
rohm_ts_remove_sysfs_group(dev);
dev_err(>dev,
"Failed to add sysfs cleanup action: %d\n",
error);
return error;
}

...
}

with:

static int rohm_bu21023_i2c_probe(struct i2c_client *client, ...)
{
...

error = devm_sysfs_create_group(dev, rohm_ts_attr_group);
if (error)
return error;

...
}

which is arguable much more compact.

That assuming that the driver is using devm construct. In case driver
used goto error unwinding it really depends at what point the attributes
were created, but I strongly advise against mixing devm and goto
unwinding in one driver as it leads to confusion as to what strategy a
given resource is using, manual or devm?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Dmitry Torokhov 
On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > Many drivers create additional driver-specific device attributes when
> > binding to the device and providing managed version of sysfs_create_group()
> > will simplify unbinding and error handling in probe path for such drivers.
> 
> But they really shouldn't, because if they do this, they have raced
> userspace and tools don't know that the files are present.
> 
> I don't want to encourage drivers to do this at all, so I don't want to
> make it easier for them to do things incorrectly.

The solution is not to forbid drivers from establishing attributes but
rather notify userspace when device is fully bound to the driver. Then
userspace that actually cares about these attributes will listen to
proper events.

We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).

> 
> Yes, I know that input does this for its devices, but I still think it
> is wrong and should be changed.  Let's not let this problem spread to
> other subsystems please.

Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
drivers and so on? Where are platform devices supposed to create their
attributes? There are more than 300 drivers that add new groups and 581
instance of device_create_file().

Let's be realistic here and see that additional attributes are not going
anywhere and adding devm interface just helps getting error handling
right.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Greg Kroah-Hartman 
On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> Many drivers create additional driver-specific device attributes when
> binding to the device and providing managed version of sysfs_create_group()
> will simplify unbinding and error handling in probe path for such drivers.

But they really shouldn't, because if they do this, they have raced
userspace and tools don't know that the files are present.

I don't want to encourage drivers to do this at all, so I don't want to
make it easier for them to do things incorrectly.

Yes, I know that input does this for its devices, but I still think it
is wrong and should be changed.  Let's not let this problem spread to
other subsystems please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Dmitry Torokhov 
Many drivers create additional driver-specific device attributes when
binding to the device and providing managed version of sysfs_create_group()
will simplify unbinding and error handling in probe path for such drivers.

Signed-off-by: Dmitry Torokhov 
---
 fs/sysfs/group.c  | 124 ++
 include/linux/sysfs.h |  10 
 2 files changed, 134 insertions(+)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..9511437 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "sysfs.h"
@@ -352,3 +353,126 @@ void sysfs_remove_link_from_group(struct kobject *kobj, 
const char *group_name,
}
 }
 EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group);
+
+struct sysfs_group_devres {
+   const struct attribute_group *group;
+};
+
+static int devm_sysfs_group_match(struct device *dev, void *res, void *data)
+{
+   return ((struct sysfs_group_devres *)res)->group == data;
+}
+
+static void devm_sysfs_group_remove_group(struct device *dev, void *res)
+{
+   struct sysfs_group_devres *devres = res;
+   const struct attribute_group *group = devres->group;
+
+   dev_dbg(dev, "%s: removing group %p\n", __func__, group);
+   sysfs_remove_group(>kobj, group);
+}
+
+/**
+ * devm_sysfs_create_group - given a device, create a managed attribute group
+ * @dev:   The device to create the group for
+ * @grp:   The attribute group to create
+ *
+ * This function creates a group for the first time.  It will explicitly
+ * warn and error if any of the attribute files being created already exist.
+ *
+ * Returns 0 on success or error code on failure.
+ */
+int devm_sysfs_create_group(struct device *dev,
+   const struct attribute_group *grp)
+{
+   struct sysfs_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_sysfs_group_remove_group,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_group(>kobj, grp);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_group);
+
+/**
+ * devm_sysfs_create_groups - create a bunch of managed attribute groups
+ * @dev:   The device to create the group for
+ * @groups:The attribute groups to create, NULL terminated
+ *
+ * This function creates a bunch of managed attribute groups.  If an error
+ * occurs when creating a group, all previously created groups will be
+ * removed, unwinding everything back to the original state when this
+ * function was called.  It will explicitly warn and error if any of the
+ * attribute files being created already exist.
+ *
+ * Returns 0 on success or error code from sysfs_create_group on failure.
+ */
+int devm_sysfs_create_groups(struct device *dev,
+const struct attribute_group **groups)
+{
+   int error;
+   int i;
+
+   if (!groups)
+   return 0;
+
+   for (i = 0; groups[i]; i++) {
+   error = devm_sysfs_create_group(dev, groups[i]);
+   if (error) {
+   while (--i >= 0)
+   devm_sysfs_remove_group(dev, groups[i]);
+   return error;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_groups);
+
+/**
+ * devm_sysfs_remove_group: remove a managed group from a device
+ * @dev:   device to remove the group from
+ * @grp:   group to remove
+ *
+ * This function removes a group of attributes from a device.  The attributes
+ * previously have to have been created for this group, otherwise it will fail.
+ */
+void devm_sysfs_remove_group(struct device *dev,
+const struct attribute_group *grp)
+{
+   WARN_ON(devres_release(dev, devm_sysfs_group_remove_group,
+  devm_sysfs_group_match,
+  /* cast away const */ (void *)grp));
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_group);
+
+/**
+ * devm_sysfs_remove_groups - remove a list of managed groups
+ *
+ * @dev:   The device for the groups to be removed from
+ * @groups:NULL terminated list of groups to be removed
+ *
+ * If groups is not NULL, remove the specified groups from the device.
+ */
+void devm_sysfs_remove_groups(struct device *dev,
+ const struct attribute_group **groups)
+{
+   int i;
+
+   if (!groups)
+   return;
+
+   for (i = 0; groups[i]; i++)
+   devm_sysfs_remove_group(dev, groups[i]);
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_groups);
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9f65758..b59a913 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -269,6 +269,16

[PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Dmitry Torokhov 
Many drivers create additional driver-specific device attributes when
binding to the device and providing managed version of sysfs_create_group()
will simplify unbinding and error handling in probe path for such drivers.

Signed-off-by: Dmitry Torokhov 
---
 fs/sysfs/group.c  | 124 ++
 include/linux/sysfs.h |  10 
 2 files changed, 134 insertions(+)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..9511437 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "sysfs.h"
@@ -352,3 +353,126 @@ void sysfs_remove_link_from_group(struct kobject *kobj, 
const char *group_name,
}
 }
 EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group);
+
+struct sysfs_group_devres {
+   const struct attribute_group *group;
+};
+
+static int devm_sysfs_group_match(struct device *dev, void *res, void *data)
+{
+   return ((struct sysfs_group_devres *)res)->group == data;
+}
+
+static void devm_sysfs_group_remove_group(struct device *dev, void *res)
+{
+   struct sysfs_group_devres *devres = res;
+   const struct attribute_group *group = devres->group;
+
+   dev_dbg(dev, "%s: removing group %p\n", __func__, group);
+   sysfs_remove_group(>kobj, group);
+}
+
+/**
+ * devm_sysfs_create_group - given a device, create a managed attribute group
+ * @dev:   The device to create the group for
+ * @grp:   The attribute group to create
+ *
+ * This function creates a group for the first time.  It will explicitly
+ * warn and error if any of the attribute files being created already exist.
+ *
+ * Returns 0 on success or error code on failure.
+ */
+int devm_sysfs_create_group(struct device *dev,
+   const struct attribute_group *grp)
+{
+   struct sysfs_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_sysfs_group_remove_group,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_group(>kobj, grp);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_group);
+
+/**
+ * devm_sysfs_create_groups - create a bunch of managed attribute groups
+ * @dev:   The device to create the group for
+ * @groups:The attribute groups to create, NULL terminated
+ *
+ * This function creates a bunch of managed attribute groups.  If an error
+ * occurs when creating a group, all previously created groups will be
+ * removed, unwinding everything back to the original state when this
+ * function was called.  It will explicitly warn and error if any of the
+ * attribute files being created already exist.
+ *
+ * Returns 0 on success or error code from sysfs_create_group on failure.
+ */
+int devm_sysfs_create_groups(struct device *dev,
+const struct attribute_group **groups)
+{
+   int error;
+   int i;
+
+   if (!groups)
+   return 0;
+
+   for (i = 0; groups[i]; i++) {
+   error = devm_sysfs_create_group(dev, groups[i]);
+   if (error) {
+   while (--i >= 0)
+   devm_sysfs_remove_group(dev, groups[i]);
+   return error;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_groups);
+
+/**
+ * devm_sysfs_remove_group: remove a managed group from a device
+ * @dev:   device to remove the group from
+ * @grp:   group to remove
+ *
+ * This function removes a group of attributes from a device.  The attributes
+ * previously have to have been created for this group, otherwise it will fail.
+ */
+void devm_sysfs_remove_group(struct device *dev,
+const struct attribute_group *grp)
+{
+   WARN_ON(devres_release(dev, devm_sysfs_group_remove_group,
+  devm_sysfs_group_match,
+  /* cast away const */ (void *)grp));
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_group);
+
+/**
+ * devm_sysfs_remove_groups - remove a list of managed groups
+ *
+ * @dev:   The device for the groups to be removed from
+ * @groups:NULL terminated list of groups to be removed
+ *
+ * If groups is not NULL, remove the specified groups from the device.
+ */
+void devm_sysfs_remove_groups(struct device *dev,
+ const struct attribute_group **groups)
+{
+   int i;
+
+   if (!groups)
+   return;
+
+   for (i = 0; groups[i]; i++)
+   devm_sysfs_remove_group(dev, groups[i]);
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_groups);
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9f65758..b59a913 100644
--- a/include/linux/sysfs.h
+++

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Dmitry Torokhov 
On Fri, Oct 30, 2015 at 07:40:37AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> > Many drivers create additional driver-specific device attributes when
> > binding to the device and providing managed version of sysfs_create_group()
> > will simplify unbinding and error handling in probe path for such drivers.
> 
> But they really shouldn't, because if they do this, they have raced
> userspace and tools don't know that the files are present.
> 
> I don't want to encourage drivers to do this at all, so I don't want to
> make it easier for them to do things incorrectly.

The solution is not to forbid drivers from establishing attributes but
rather notify userspace when device is fully bound to the driver. Then
userspace that actually cares about these attributes will listen to
proper events.

We can either do KOBJ_BOUND/KOBJ_UNBOUND or reuse
KOBJ_ONLINE/KOBJ_OFFLINE. I'd prefer the former (adding new events).

> 
> Yes, I know that input does this for its devices, but I still think it
> is wrong and should be changed.  Let's not let this problem spread to
> other subsystems please.

Like HID, chargers, hwmon, wireless drivers, leds, backlights, platform
drivers and so on? Where are platform devices supposed to create their
attributes? There are more than 300 drivers that add new groups and 581
instance of device_create_file().

Let's be realistic here and see that additional attributes are not going
anywhere and adding devm interface just helps getting error handling
right.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysfs: add devm_sysfs_create_group() and friends

2015-10-30 Thread Greg Kroah-Hartman 
On Fri, Oct 30, 2015 at 04:47:06AM -0700, Dmitry Torokhov wrote:
> Many drivers create additional driver-specific device attributes when
> binding to the device and providing managed version of sysfs_create_group()
> will simplify unbinding and error handling in probe path for such drivers.

But they really shouldn't, because if they do this, they have raced
userspace and tools don't know that the files are present.

I don't want to encourage drivers to do this at all, so I don't want to
make it easier for them to do things incorrectly.

Yes, I know that input does this for its devices, but I still think it
is wrong and should be changed.  Let's not let this problem spread to
other subsystems please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/