On 19.08.25 11:18, Krzysztof Kozlowski wrote:

On Mon, Aug 18, 2025 at 04:42:59PM +0800, Nick Chan wrote:

quoted

Add ANS2 NVMe bindings for Apple A11 SoC.

Signed-off-by: Nick Chan <redacted>
---
  .../devicetree/bindings/nvme/apple,nvme-ans.yaml          | 15 +++++++++------
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
index fc6555724e1858e8a16f6750302ff0ad9c4e5b88..4127d7b0a0f066fd0e144b32d1b676e3406b9d5a 100644
--- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
+++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml

@@ -11,12 +11,14 @@ maintainers:
  
  properties:
    compatible:
-    items:
-      - enum:
-          - apple,t8103-nvme-ans2
-          - apple,t8112-nvme-ans2
-          - apple,t6000-nvme-ans2
-      - const: apple,nvme-ans2
+    oneOf:
+      - const: apple,t8015-nvme-ans2
+      - items:
+          - enum:
+              - apple,t8103-nvme-ans2
+              - apple,t8112-nvme-ans2
+              - apple,t6000-nvme-ans2
+          - const: apple,nvme-ans2

When some months ago this pattern of generic fallback appeared, I
believe I commented it is bad idea. So now months later we have a proof
- generic fallback is useless and you should have been using SoC
specific compatibles from the start.

Now it is just confusing and this broken pattern will be spreading more
and more, because you folks put generic compatibles everywhere.

I haven't commented on the dt-bindings yet because I suspect this patch 
is wrong but haven't had time to test this yet.

I believe we want "apple,t8015-nvme-ans2", "apple,nvme-ans2" here and
then use the code Nick added for "apple,nvme-ans2" by default and only
enable additional features (NVMMU, linear submission queue) when we see
the SoC-specific compatibles for t8103, t8112, and t6000. IIRC these
newer SoCs still support the old way of submitting commands just fine
and the new way was added at some point to add support for this weird
integrated IOMMU.

I've already seen some strings about ANS3 somewhere which I suspect
will be the controller in some future SoC (or maybe M3/M4 which we 
haven't reverse engineered yet) that actually breaks compatibility.

It's too late to drop them here but if you're strongly opposed to these
generic fallbacks we can just switch to only use tXXXX-nvme-ans3 at that
point without making anything confusing. Same for any other new hardware
blocks we reverse engineer and upstream.



Sven