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

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:

quoted

On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:

quoted

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.

-- 
Dmitry