Messages in this thread | | | Date | Tue, 10 Jan 2023 16:25:00 +0000 | From | "Russell King (Oracle)" <> | Subject | Re: [PATCH v3 0/5] Fix a whole host of nvmem registration/cleanup issues |
| |
On Tue, Jan 03, 2023 at 08:56:32PM +0000, Russell King (Oracle) wrote: > Really not interested in your politics. Not interested in fixing this > problem. > > I'll use these patches to fix the problem in my tree. I don't care about > mainline.
Having thought this over, this was an unfair over-reaction for which I'd like to apologise. It was proving to be a very stressful couple of days.
> > Uhh. The series itself looks fine as far as fixing the problems, but I > > fail to see how this is any better than my attempt as far as backporting > > or commit atomicity goes. Patch #4 fixes the newer gpio leak bug *and* > > half fixes the race condition bug,
There are two choices for patch for:
1. add gpiod_put(). 2. make use of the gpiod_put() already present in the release function.
Either way, patch 5 depends on patch 4, and there's no way around that. This does not mean that they can't be back ported though - patch 4 can be backported to the appropriate point, and further backported merely by dropping one hunk - and thus it becomes a preparatory patch for patch 5, and even more so, separates the conversion from device_register() to device_initialize()+device_add() from the actual fix itself (which in patch 5 merely moves device_add() and rearranges the cleanup.)
However, where our patches differ is that my series fixes one problem in one patch, rather than trying to address multiple problems in one patch. As has been pointed out, this is a documented requirement in the submitting-patches.rst document, which has been there for a very long time. You had been pointed to this document already over this point.
Therefore, I believe my series to be a technically better approach which addresses several more issues while conforming to the "Solve only one problem per patch." requirement which can be trivially backported - and I truely believe that even patch 4 complies with the requirement in submitting-patches.rst. I certainly do not believe patch 4 is a kind of "partial" fix for the race condition, since it in no way changes the presence of the race.
I hope that we can continue to work to get the Apple M1 supported more fully in the future.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |