[v2,00/10] drivers, provide a way to add sysfs groups easily

Message

Greg KH July 31, 2019, 12:43 p.m. UTC

This patch originally started out just as a way for platform drivers to
easily add a sysfs group in a race-free way, but thanks to Dmitry's
patch, this series now is for all drivers in the kernel (hey, a unified
driver model works!!!)

I've only converted a few platform drivers here in this series to show
how it works, but other busses can be converted after the first patch
goes into the tree.

Here's the original 00 message, for people to get an idea of what is
going on here:

If a platform driver wants to add a sysfs group, it has to do so in a
racy way, adding it after the driver is bound.  To resolve this issue,
have the platform driver core do this for the driver, making the
individual drivers logic smaller and simpler, and solving the race at
the same time.

All of these patches depend on the first patch.  I'll take the first one
through my driver-core tree, and any subsystem maintainer can either ack
their individul patch and I will be glad to also merge it, or they can
wait until after 5.4-rc1 when the core patch hits Linus's tree and then
take it, it's up to them.

Thank to Richard Gong for the idea and the testing of the platform
driver patch and to Dmitry Torokhov for rewriting the first patch to
work well for all busses.

-----

V2 - work for all busses and not just platform drivers.


Dmitry Torokhov (1):
  driver core: add dev_groups to all drivers

Greg Kroah-Hartman (9):
  uio: uio_fsl_elbc_gpcm: convert platform driver to use dev_groups
  input: keyboard: gpio_keys: convert platform driver to use dev_groups
  input: axp20x-pek: convert platform driver to use dev_groups
  firmware: arm_scpi: convert platform driver to use dev_groups
  olpc: x01: convert platform driver to use dev_groups
  platform: x86: hp-wmi: convert platform driver to use dev_groups
  video: fbdev: wm8505fb: convert platform driver to use dev_groups
  video: fbdev: w100fb: convert platform driver to use dev_groups
  video: fbdev: sm501fb: convert platform driver to use dev_groups

 arch/x86/platform/olpc/olpc-xo1-sci.c | 17 ++++------
 drivers/base/dd.c                     | 14 ++++++++
 drivers/firmware/arm_scpi.c           |  5 +--
 drivers/input/keyboard/gpio_keys.c    | 13 ++------
 drivers/input/misc/axp20x-pek.c       | 15 ++-------
 drivers/platform/x86/hp-wmi.c         | 47 +++++++--------------------
 drivers/uio/uio_fsl_elbc_gpcm.c       | 23 +++++--------
 drivers/video/fbdev/sm501fb.c         | 37 +++++----------------
 drivers/video/fbdev/w100fb.c          | 23 ++++++-------
 drivers/video/fbdev/wm8505fb.c        | 13 ++++----
 include/linux/device.h                |  3 ++
 11 files changed, 76 insertions(+), 134 deletions(-)

Comments

Dmitry Torokhov July 31, 2019, 1:10 p.m. UTC | #1

On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> This patch originally started out just as a way for platform drivers to
> easily add a sysfs group in a race-free way, but thanks to Dmitry's
> patch, this series now is for all drivers in the kernel (hey, a unified
> driver model works!!!)
> 
> I've only converted a few platform drivers here in this series to show
> how it works, but other busses can be converted after the first patch
> goes into the tree.
> 
> Here's the original 00 message, for people to get an idea of what is
> going on here:
> 
> If a platform driver wants to add a sysfs group, it has to do so in a
> racy way, adding it after the driver is bound.  To resolve this issue,
> have the platform driver core do this for the driver, making the
> individual drivers logic smaller and simpler, and solving the race at
> the same time.
> 
> All of these patches depend on the first patch.  I'll take the first one
> through my driver-core tree, and any subsystem maintainer can either ack
> their individul patch and I will be glad to also merge it, or they can
> wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> take it, it's up to them.

Maybe make an immutable branch off 5.2 with just patch 1/10 so that
subsystems (and the driver core tree itself) could pull it in at their
leisure into their "*-next" branches and did not have to wait till 5.4
or risk merge clashes?

Thanks.

Greg KH July 31, 2019, 1:22 p.m. UTC | #2

On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> > 
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> > 
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> > 
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound.  To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> > 
> > All of these patches depend on the first patch.  I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
> 
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?

Good idea, I will do that when I apply it after a few days to give
people a chance to review it.

thanks,

greg k-h

Andy Shevchenko July 31, 2019, 1:38 p.m. UTC | #3

On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> > 
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> > 
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> > 
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound.  To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> > 
> > All of these patches depend on the first patch.  I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
> 
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?

Isn't cherry-pick enough for one patch?

Dmitry Torokhov July 31, 2019, 1:46 p.m. UTC | #4

On Wed, Jul 31, 2019 at 04:38:40PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> > On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > > This patch originally started out just as a way for platform drivers to
> > > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > > patch, this series now is for all drivers in the kernel (hey, a unified
> > > driver model works!!!)
> > > 
> > > I've only converted a few platform drivers here in this series to show
> > > how it works, but other busses can be converted after the first patch
> > > goes into the tree.
> > > 
> > > Here's the original 00 message, for people to get an idea of what is
> > > going on here:
> > > 
> > > If a platform driver wants to add a sysfs group, it has to do so in a
> > > racy way, adding it after the driver is bound.  To resolve this issue,
> > > have the platform driver core do this for the driver, making the
> > > individual drivers logic smaller and simpler, and solving the race at
> > > the same time.
> > > 
> > > All of these patches depend on the first patch.  I'll take the first one
> > > through my driver-core tree, and any subsystem maintainer can either ack
> > > their individul patch and I will be glad to also merge it, or they can
> > > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > > take it, it's up to them.
> > 
> > Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> > subsystems (and the driver core tree itself) could pull it in at their
> > leisure into their "*-next" branches and did not have to wait till 5.4
> > or risk merge clashes?
> 
> Isn't cherry-pick enough for one patch?

With cherry-picking you run into potential merge conflicts if Greg
changes more code in the same area. Plus, once everything is merged into
Linus' tree, there will be N git commits adding the same thing.

With immutable branch there is a single git commit, so merges are
guaranteed to be clean, with no conflicts.

Thanks.

Greg KH Aug. 2, 2019, 10:46 a.m. UTC | #5

On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> > 
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> > 
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> > 
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound.  To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> > 
> > All of these patches depend on the first patch.  I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
> 
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?

I have now done this with patch 1/10.  Here's the pull info if any
subsystem maintainer wants to suck this into their tree to provide the
ability for drivers to add/remove attribute groups easily.

This is part of my driver-core tree now, and will go to Linus for
5.4-rc1, along with a few platform drivers that have been acked by their
various subsystem maintainers that convert them to use this new
functionality.

If anyone has any questions about this, please let me know.

thanks,

greg k-h

-------------------

The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:

  Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers

for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:

  driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)

----------------------------------------------------------------
dev_groups added to struct driver

Persistent tag for others to pull this branch from

This is the first patch in a longer series that adds the ability for the
driver core to create and remove a list of attribute groups
automatically when the device is bound/unbound from a specific driver.

See:
	https://lore.kernel.org/r/[e-mail]
for details on this patch, and examples of how to use it in other
drivers.

Signed-off-by: Greg Kroah-Hartman <[e-mail]>

----------------------------------------------------------------
Dmitry Torokhov (1):
      driver core: add dev_groups to all drivers

 drivers/base/dd.c      | 14 ++++++++++++++
 include/linux/device.h |  3 +++
 2 files changed, 17 insertions(+)

Emil Velikov May 13, 2020, 10:18 p.m. UTC | #6

Hi Greg,

On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman
<[e-mail]> wrote:

>
> I have now done this with patch 1/10.  Here's the pull info if any
> subsystem maintainer wants to suck this into their tree to provide the
> ability for drivers to add/remove attribute groups easily.
>
> This is part of my driver-core tree now, and will go to Linus for
> 5.4-rc1, along with a few platform drivers that have been acked by their
> various subsystem maintainers that convert them to use this new
> functionality.
>
> If anyone has any questions about this, please let me know.
>
> thanks,
>
> greg k-h
>
> -------------------
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
>   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
>
> for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
>
>   driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
>
> ----------------------------------------------------------------
> dev_groups added to struct driver
>
> Persistent tag for others to pull this branch from
>
> This is the first patch in a longer series that adds the ability for the
> driver core to create and remove a list of attribute groups
> automatically when the device is bound/unbound from a specific driver.
>
> See:
>         https://lore.kernel.org/r/[e-mail]
> for details on this patch, and examples of how to use it in other
> drivers.
>
> Signed-off-by: Greg Kroah-Hartman <[e-mail]>
>
> ----------------------------------------------------------------
> Dmitry Torokhov (1):
>       driver core: add dev_groups to all drivers
>
>  drivers/base/dd.c      | 14 ++++++++++++++
>  include/linux/device.h |  3 +++
>  2 files changed, 17 insertions(+)
> _______________________________________________

Was planning to re-spin DRM a series which uses .dev_groups, although
I cannot see the core patch.
Did the it get reverted or simply fell though the cracks?

-Emil

Greg KH May 14, 2020, 7:16 a.m. UTC | #7

On Wed, May 13, 2020 at 11:18:15PM +0100, Emil Velikov wrote:
> Hi Greg,
> 
> On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman
> <[e-mail]> wrote:
> 
> >
> > I have now done this with patch 1/10.  Here's the pull info if any
> > subsystem maintainer wants to suck this into their tree to provide the
> > ability for drivers to add/remove attribute groups easily.
> >
> > This is part of my driver-core tree now, and will go to Linus for
> > 5.4-rc1, along with a few platform drivers that have been acked by their
> > various subsystem maintainers that convert them to use this new
> > functionality.
> >
> > If anyone has any questions about this, please let me know.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------------
> >
> > The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> >
> >   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
> >
> > for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
> >
> >   driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
> >
> > ----------------------------------------------------------------
> > dev_groups added to struct driver
> >
> > Persistent tag for others to pull this branch from
> >
> > This is the first patch in a longer series that adds the ability for the
> > driver core to create and remove a list of attribute groups
> > automatically when the device is bound/unbound from a specific driver.
> >
> > See:
> >         https://lore.kernel.org/r/[e-mail]
> > for details on this patch, and examples of how to use it in other
> > drivers.
> >
> > Signed-off-by: Greg Kroah-Hartman <[e-mail]>
> >
> > ----------------------------------------------------------------
> > Dmitry Torokhov (1):
> >       driver core: add dev_groups to all drivers
> >
> >  drivers/base/dd.c      | 14 ++++++++++++++
> >  include/linux/device.h |  3 +++
> >  2 files changed, 17 insertions(+)
> > _______________________________________________
> 
> Was planning to re-spin DRM a series which uses .dev_groups, although
> I cannot see the core patch.
> Did the it get reverted or simply fell though the cracks?

Nope, it's in there:
	23b6904442d0 ("driver core: add dev_groups to all drivers")
which showed up in the 5.4 kernel release.

Lots of other subsystems have already been converted to use this, do you
not see it in your tree?

thanks,

greg k-h

Emil Velikov May 14, 2020, 11:48 a.m. UTC | #8

On Thu, 14 May 2020 at 08:16, Greg Kroah-Hartman
<[e-mail]> wrote:
>
> On Wed, May 13, 2020 at 11:18:15PM +0100, Emil Velikov wrote:
> > Hi Greg,
> >
> > On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman
> > <[e-mail]> wrote:
> >
> > >
> > > I have now done this with patch 1/10.  Here's the pull info if any
> > > subsystem maintainer wants to suck this into their tree to provide the
> > > ability for drivers to add/remove attribute groups easily.
> > >
> > > This is part of my driver-core tree now, and will go to Linus for
> > > 5.4-rc1, along with a few platform drivers that have been acked by their
> > > various subsystem maintainers that convert them to use this new
> > > functionality.
> > >
> > > If anyone has any questions about this, please let me know.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > > -------------------
> > >
> > > The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> > >
> > >   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
> > >
> > > for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
> > >
> > >   driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
> > >
> > > ----------------------------------------------------------------
> > > dev_groups added to struct driver
> > >
> > > Persistent tag for others to pull this branch from
> > >
> > > This is the first patch in a longer series that adds the ability for the
> > > driver core to create and remove a list of attribute groups
> > > automatically when the device is bound/unbound from a specific driver.
> > >
> > > See:
> > >         https://lore.kernel.org/r/[e-mail]
> > > for details on this patch, and examples of how to use it in other
> > > drivers.
> > >
> > > Signed-off-by: Greg Kroah-Hartman <[e-mail]>
> > >
> > > ----------------------------------------------------------------
> > > Dmitry Torokhov (1):
> > >       driver core: add dev_groups to all drivers
> > >
> > >  drivers/base/dd.c      | 14 ++++++++++++++
> > >  include/linux/device.h |  3 +++
> > >  2 files changed, 17 insertions(+)
> > > _______________________________________________
> >
> > Was planning to re-spin DRM a series which uses .dev_groups, although
> > I cannot see the core patch.
> > Did the it get reverted or simply fell though the cracks?
>
> Nope, it's in there:
>         23b6904442d0 ("driver core: add dev_groups to all drivers")
> which showed up in the 5.4 kernel release.
>
> Lots of other subsystems have already been converted to use this, do you
> not see it in your tree?
>
A case of PEBKAC it seems - I was looking at a 5.3 checkout somehow.

Thanks for the core work. Will check/merge the fbdev patches over the
next few days and polish drm land.

-Emil