linux-kernel - Re: [PATCH v2 6/9] dt-bindings: nvme: apple,nvme-ans: Add Apple A11

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250827122525.GA204299@robin.jannau.net>
Date: Wed, 27 Aug 2025 14:25:25 +0200
From: Janne Grunau <j@...nau.net>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Sven Peter <sven@...nel.org>, Nick Chan <towinchenmi@...il.com>,
	Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Neal Gompa <neal@...pa.dev>, Jassi Brar <jassisinghbrar@...il.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Hector Martin <marcan@...can.st>, Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
	Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	iommu@...ts.linux.dev, linux-nvme@...ts.infradead.org
Subject: Re: [PATCH v2 6/9] dt-bindings: nvme: apple,nvme-ans: Add Apple A11

On Thu, Aug 21, 2025 at 03:09:42PM +0200, Krzysztof Kozlowski wrote:
> On 21/08/2025 12:25, Sven Peter wrote:
> > 
> > 1) For situations like this one where the generic one just doesn't make 
> > any sense we deprecate "apple,nvme-ans2" in the binding and use
> > "apple,t8103-nvme-ans2" as the fallback instead, i.e. just
> > "apple,t8103-nvme-ans2" for M1, "apple,t6000-nvme-ans2", 
> > "apple,t8103-nvme-ans2" for M1 Pro, and just "apple,t8015-nvme-ans2" for 
> > A11.
> > 
> > We keep the generic one in the driver for now but also add
> > "apple,t8103-nvme-ans2". We then remove the generic one from all 
> > upstream DTS files but keep it inside the downstream files we ship to 
> > users for now to avoid pain with kernel upgrades/downgrades.
> > A year or two from now we can then delete the deprecated generic 
> > compatibles everywhere. This all has to be synced with OpenBSD and 
> > u-boot as well since both also use these bindings.
> > It's gonna be rather painful but this would clean up the entire mess.
> > 
> > 
> > 2) We keep using the ones that are already upstream and just accept that 
> > the situation is a mess and add comment above all the bindings that we 
> > messed up and that this should not be used as pattern.
> > In this case that means it'll just be "apple,t8015-nvme-ans2" for A11 
> > without any fallback and we keep everything else the way it is.
> > 
> > I prefer option (2) but if you really want to get rid of all this mess 
> 
> 
> I also prefer option (2). That's the least disruptive option for users
> and inconsistency in bindings naming is just inconsistency, no big deal.
> You just need to remember not to grow the old items/pattern with generic
> compatible.

This sounds to me like a mix of option 1) and 2).

All devices / SoCs already upstream will use the fixed current
compatibles and thus are following option 2)

New SoCs will have to use
    compatible = "apple,t6020-nvme-ans2", "apple,t8103-nvme-ans2";
using t6020 as example even though they will be using the same driver
code as "apple,nvme-ans2". Using t6020 as an example I planned to submit
today.
This will require adding the new fallback "apple,t8103-nvme-ans2"
compatible string to the driver.

Asking for clarification as I could image such driver changes will raise
questions from the driver maintainers.

Is there a way do document/annotate the generic compatibles as
deprecated / "do not use" for new devices?

Thanks
Janne