Re: [PATCH v3 0/5] Fix a whole host of nvmem registration/cleanup issues

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Hector Martin <marcan@marcan.st>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Gaosheng Cui <cuigaosheng1@huawei.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Maxime Ripard <mripard@kernel.org>
Subject: Re: [PATCH v3 0/5] Fix a whole host of nvmem registration/cleanup issues
Date: Wed, 4 Jan 2023 10:29:59 +0000	[thread overview]
Message-ID: <Y7VVJxpLtouhEO6u@shell.armlinux.org.uk> (raw)
In-Reply-To: <c5b1949f-f39e-8783-19be-cb27c96aea33@marcan.st>

On Wed, Jan 04, 2023 at 10:15:14AM +0900, Hector Martin wrote:
> On 04/01/2023 06.15, Srinivas Kandagatla wrote:
> > Hi Russell,
> > 
> > 
> > On 03/01/2023 16:58, Russell King (Oracle) wrote:
> >> Hi,
> >>
> >> This series fixes a whole host of nvmem registration/error cleanup
> >> issues that have been identified by both Hector and myself. It is a
> >> substantial rework of my original patch fixing the first problem.
> >>
> >> The first most obvious problem is the race between nvmem registration
> >> and use, which leads to sporadic failures of drivers to probe at boot
> >> time.
> >>
> >> While fixing this, it has been noticed that a recent fix to check the
> >> return value of dev_set_name() introduced a new bug where wp_gpio was
> >> not being put in that newly introduced error path.
> >>
> >> Then there's a fix for a previous fix which itself purports to fix
> >> another bug, but results in the allocated ID being leaked. Fix for a
> >> fix for a fix is not good!
> >>
> >> Then there's an error in the docbook documentation for wp_gpio (it's
> >> listed as wp-gpio instead) but as nothing seems to set wp_gpio, we
> >> might as well get rid of it - which also solves the issue that we
> >> call gpiod_put() on this whether we own it or not.
> >>
> >> Lastly, there's a fix for yet another spurious white-space in this
> >> code, one of what seems to be a long history of past white-space
> >> fixes.
> >>
> >> These patches have been individually build-tested in the order of
> >> posting, but not run-time tested except for the entire series.
> > 
> > 
> > thanks for fixing these issues, I have applied these after fixing the 
> > subject on all the patches, as it ended up with email ids in subject.
> 
> Right. I see none of the issues you two lectured me about actually
> mattered, it was all for show, and this isn't getting backported anyway.
> 
> Good job you two. The day I finally rage quit the kernel after enough of
> this nonsense and make a big dossier of just how fucked up the kernel
> maintainer community's attitude is, I will be sure to use this as an
> example.
> 
> That day is not today though. But I certainly won't be upstreaming any
> more patches to nvmem.

You've really little clue, have you.

I really don't see that you'll *ever* get apple hardware properly
functional in mainline. Good luck maintaining a fork of the kernel
for ever into the future.

I've had enough of you.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel