Re: [PATCH v2 6/9] dt-bindings: nvme: apple,nvme-ans: Add Apple A11
From: Janne Grunau <j@jannau.net>
Date: 2025-08-27 12:25:31
Also in:
asahi, linux-devicetree, linux-iommu, linux-nvme, lkml
On Thu, Aug 21, 2025 at 03:09:42PM +0200, Krzysztof Kozlowski wrote:
On 21/08/2025 12:25, Sven Peter wrote:quoted
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 messI 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