| Message ID | 20190731124349.4474-1-gregkh@linuxfoundation.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drivers, provide a way to add sysfs groups easily | expand |
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.
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
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?
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.
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/20190731124349.4474-2-gregkh@linuxfoundation.org for details on this patch, and examples of how to use it in other drivers. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> ---------------------------------------------------------------- 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(+)
Hi Greg, On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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/20190731124349.4474-2-gregkh@linuxfoundation.org > for details on this patch, and examples of how to use it in other > drivers. > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > ---------------------------------------------------------------- > 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
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 > <gregkh@linuxfoundation.org> 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/20190731124349.4474-2-gregkh@linuxfoundation.org > > for details on this patch, and examples of how to use it in other > > drivers. > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > ---------------------------------------------------------------- > > 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
On Thu, 14 May 2020 at 08:16, Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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 > > <gregkh@linuxfoundation.org> 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/20190731124349.4474-2-gregkh@linuxfoundation.org > > > for details on this patch, and examples of how to use it in other > > > drivers. > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > ---------------------------------------------------------------- > > > 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