linux-kernel - Re: [PATCH v2 1/3] dt-bindings: spmi: Add generic SPMI NVMEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aAkLY3TYIPG7ojwx@blossom>
Date: Wed, 23 Apr 2025 11:46:43 -0400
From: Alyssa Rosenzweig <alyssa@...enzweig.io>
To: Rob Herring <robh@...nel.org>
Cc: Nick Chan <towinchenmi@...il.com>,
	Sasha Finkelstein <fnkl.kernel@...il.com>,
	Sven Peter <sven@...npeter.dev>, Janne Grunau <j@...nau.net>,
	Neal Gompa <neal@...pa.dev>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, asahi@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: spmi: Add generic SPMI NVMEM

> > >> What makes this generic?
> > >>
> > >> A generic driver is great, but "generic" or "simple" bindings are
> > >> generally a mistake.
> > > There is nothing apple-specific in that driver, just re-exporting
> > > several registers as cells. If you think that it is a mistake, I can
> > > rename it to apple-pmic, or something similar.
> 
> Like I said, a generic *driver* is great! I'm all for them. We should
> have more of them! Generic bindings on the other hand are generally a
> mistake. The problem is whether a generic driver works for you or not
> can evolve in either direction. You add more things like described
> below and then a generic driver doesn't work.

It sounds like the path of least resistance here is then:

1. rename the bindings to be apple m1+ (at least for now)
2. keep the driver as-is (no mfd, etc - at least for now)
3. land just that (at least for now)

Evolving the driver to share with not-Apple, or evolving the
bindings+driver to share with pre-M1, can happen in future series
if/when somebody wants to do that work.

Is this a fair understanding of the situation?