From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E1083469F4 for ; Wed, 21 Jan 2026 15:42:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769010173; cv=none; b=YTgl09NoPfYbyKoPYD24cIDEv6j/SfbUVHTEX6aZTlA9Dja2GF4ZS4M3LqEzZWY5taVGheCjPLAtm8ITy2SkWPMieYUdR22eRqn+lBI6zRuPTfbhkXsvBFDyol4Tqbg8YpOZkksAstv+sC5wIGwo8UOxq+DMzizkGgDqJho7DpM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769010173; c=relaxed/simple; bh=XoQZe6GcbbFkC/VKgri6MxPnJDx/x7CacdPk2P6jXwY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gTsN8OLztZpsK3oaEw/aHJQatJWRMeeaGE5/4KSLL6k18oNhHF/aZxPJ9E4LJGvPoRI4yHG5HiGZ31AhATSlFJ0+EE3bO/ginKvIDqweNwNLSeF4RGo9FS+pMUWJIc/bhKS4YrWYC8iKrSVet/ixVW/0f/88+YzqyQT3m+Kt1Q8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SjhkfZHM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SjhkfZHM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2C79C4CEF1; Wed, 21 Jan 2026 15:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769010172; bh=XoQZe6GcbbFkC/VKgri6MxPnJDx/x7CacdPk2P6jXwY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SjhkfZHMmb5bJym98/OPPD1TTiDkBNyKnrchTtfar4lR0uiPtSg3spiBY9HTfOXRg nEGOHc6CcbJkP/7bdRnTfZnuQXgM2J7bX2SKBcMW2kDevQ8rNWSvMF25LxQWgbstT3 hv4wu/MdMTX7eQtiBrAT4EPymVLjDVqwX2CvCqtGMsZ8OLbec6M3QGhsdpjGKKcJX+ 8rtyuprihUXY49BNBmmPWg+CfYvfTGW3x28JSymbN7srZhZb9MKJ4OSahDxMygiJ5F fIvHtz3Iadt+OUMP2Uyf4F1iJeR21v3ZH+QBzmqhLlU02M6+kpeTBO3JYR5Dv6dpTN rtjbS6K/qCXRQ== Received: from johan by xi.lan with local (Exim 4.98.2) (envelope-from ) id 1viaM4-000000006VZ-2YTt; Wed, 21 Jan 2026 16:42:48 +0100 Date: Wed, 21 Jan 2026 16:42:48 +0100 From: Johan Hovold To: Bartosz Golaszewski Cc: Bartosz Golaszewski , Srinivas Kandagatla , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers Message-ID: References: <20260116-nvmem-unbind-v1-0-7bb401ab19a8@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 20, 2026 at 08:57:41PM +0100, Bartosz Golaszewski wrote: > On Tue, Jan 20, 2026 at 11:18 AM Johan Hovold wrote: > > > > For reference, this is related to the i2c discussion here: > > > > > > > > https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/ > > > > > > > > > > Your argument against the i2c changes is that they affect lots of > > > drivers and decrease readability. I can see it as a point worth > > > considering. In the end it's up to Wolfram to decide and I think he > > > was pretty clear he wants it to proceed. > > > > > > This series addresses the unbinding issue entirely within nvmem core, > > > no driver changes are required. It uses SRCU which is very fast in > > > read sections. What exactly is your argument against it? What is the > > > reason for your comment? Unless you deal with nvmem internals, you > > > never have to concern yourself with it. > > > > My concern is that you're stuck on the idea of wrapping every access in > > "Every access" is an exaggeration. > > > the kernel with unnecessary constructs because you seem to think driver > > unbinding is something we need to worry about it. It's not. At least > > not at any cost (readability, maintainability, cognitive load, churn, > > performance, ...). > > > > That is simply incorrect. I didn't just suddenly make this up. I > encountered this issue - and subsequently started working on it - in > my work with a client's device based on CP2112 I2C/GPIO USB expander > where unplugging it would either crash the system in GPIO unbind path > or freeze the kernel thread forever waiting for a completion in I2C > unbind path. That's why - contrary to what you're claiming here - we > (the kernel community) *do* care about driver unbinding. I truly can't > comprehend why kernel just easily crashing on what is pretty normal > operation does not seem wrong to you. Again, driver unbinding (module unloading) is a development tool, if making it 100% fool proof would require making drivers unmaintainable while adding enough runtime overhead it *may* simply not be worth it. And there are other ways to address this without any such costs since in 99.9999% of cases where unbinding makes no sense at all. If you don't trust yourself from running around unbinding random drivers, you can even disable unloading completely. And fw_devlink unbinds consumers before providers. Etc, etc. Hot-plug is a different issue, and not something new that you've just discovered. USB serial deals with this since forever and during Project Ara we quickly learned that most subsystems do not support hot plugging (for obvious reasons). But the most relevant issue here is the user-space interface since a user can keep a file descriptor open indefinitely. And that can potentially be solved in a generic fashion without messing up every driver for something that is not a problem in practice. > Ever since Laurent's first talk about object life-time issues (was > that 2021?), I've discussed this with many people - including key > kernel maintainers like Greg KH. People disagree on ways of fixing > this family of problems (it's not a single bug) but you are quite > literally the only person who says that we should do nothing. Re-read what I just wrote above. > Meanwhile, unbinding may not be a problem until it is. I've had Brian > Masney from Red Hat approach me during LPC in Tokyo because he needs > to be able to unbind a clock driver at runtime. At another conference, > Bootlin had a whole BoF/miniconf about dynamically instantiated and > removed platform devices (this was for cape-like extensions but > unbinding was one of the issues). If you're claiming it's unimportant, > then you're simply wrong. That's about tearing down a subtree, where children would be removed before parents. If we have random links to hotpluggable devices then that would be an issue, but so far that looks like yet another contrived example. > Feel free to review the patches or point out anything incorrect in the > description of the problem, but please stop commenting under every > related series I post (seriously, did you filter lore by my name to > find this one?), saying "we don't want to do this". The consensus is > that this can and should be fixed. You yourself posted a link to > Wolfram's email saying that much about I2C. Don't flatter yourself. Johan