From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.cyberchaos.dev (mail.cyberchaos.dev [195.39.247.168]) (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 D1FA73F0AB7; Wed, 12 Aug 2026 09:16:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.39.247.168 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786526221; cv=none; b=e4uVuPVJTdKgTU3TLjzfQZIRM7gayHolqQ4sXOLvmbOZZuJGNkEzkb1bQMQuMTTk4gLIAOcVtS2BtsH00Vc0uL/5J2mf3DP+8xpcbL1vBtMsrLGBxoztQ2Wv7g/DFQSkWgcaas27WAMpnGvngBPVoWYmnT9NMlVotzdwadFPIgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786526221; c=relaxed/simple; bh=52nIbc4C8IUH3GWFN/KqlchQG7sfho9mcq9xNbqX5+s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PnQGBDMEJ051yIpBe5GCz1PlnpUjRrjoM0QgPSQ4MpRatueKYwP1kGaaZU7oj60EBt0uOBZFm7rAyCJbq/0LeAprKhq/3v1lDiLSqrOW+35kSDLgDz4OlPEpRLPvyaX+slfUaCKpjiKElEHxa1iww176OBjYKTrRk5zrX0KycfI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cyberchaos.dev; spf=pass smtp.mailfrom=cyberchaos.dev; dkim=pass (1024-bit key) header.d=cyberchaos.dev header.i=@cyberchaos.dev header.b=4D0qkhwQ; arc=none smtp.client-ip=195.39.247.168 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cyberchaos.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cyberchaos.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=cyberchaos.dev header.i=@cyberchaos.dev header.b="4D0qkhwQ" Message-ID: <87321252-e974-47be-8f93-2adccb0b136e@cyberchaos.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cyberchaos.dev; s=mail; t=1786526215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ON4yX+Syw+jUtr/PaTXfaOXt9C8DXWZkJkHSUgV/U1I=; b=4D0qkhwQbpUK+GI/5Xv4UGBGxycC1R2eoVDXyp/KPpUAnNfxlwz2HOKzpH+cqBpywUyzYF fcE4ROXvn9TAS+ZWGWuIylNRTghUhAfiXYbHogCxDiT8CijH1FRLyNfkhrHLBTOPNoLloy NhQDA6knNs8wWPr8gtBb8keN48bZRuc= Date: Wed, 12 Aug 2026 11:16:51 +0200 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/2] dt-bindings: nvme: Add apple,t8132-nvme-ans2 compatible To: Krzysztof Kozlowski , Yureka Lilian , Rob Herring Cc: Sven Peter , Janne Grunau , Neal Gompa , Krzysztof Kozlowski , Conor Dooley , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org References: <20260811-apple-nvme-t8132-v1-0-865be32e42c3@cyberchaos.dev> <20260811-apple-nvme-t8132-v1-1-865be32e42c3@cyberchaos.dev> <20260811231121.GA271810-robh@kernel.org> <1e4b3f04-7367-4651-9cdd-5c95e92e5874@kernel.org> Content-Language: en-US From: Yureka Lilian In-Reply-To: <1e4b3f04-7367-4651-9cdd-5c95e92e5874@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/12/26 10:46, Krzysztof Kozlowski wrote: > On 12/08/2026 10:08, Yureka Lilian wrote: >> Thank you for the quick feedback! >> >> On 8/12/26 01:11, Rob Herring wrote: >>> On Tue, Aug 11, 2026 at 10:49:47PM +0200, Yureka Lilian wrote: >>>> Add a new base compatible for the ANS2 NVMe on the Apple t8132 (M4) SoC, >>>> which uses a separate MMIO base for its NVMMU. >>>> >>>> Signed-off-by: Yureka Lilian >>>> --- >>>> .../devicetree/bindings/nvme/apple,nvme-ans.yaml | 77 ++++++++++++++-------- >>>> 1 file changed, 48 insertions(+), 29 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml >>>> index 4c0b1f90aff8..c8a41b268b9c 100644 >>>> --- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml >>>> +++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml >>>> @@ -16,6 +16,7 @@ properties: >>>> - items: >>>> - const: apple,t6020-nvme-ans2 >>>> - const: apple,t8103-nvme-ans2 >>>> + - const: apple,t8132-nvme-ans2 >>>> - items: >>>> - enum: >>>> # Do not add additional SoC to this list. >>>> @@ -24,16 +25,6 @@ properties: >>>> - apple,t6000-nvme-ans2 >>>> - const: apple,nvme-ans2 >>>> >>>> - reg: >>>> - items: >>>> - - description: NVMe and NVMMU registers >>>> - - description: ANS2 co-processor control registers >>>> - >>>> - reg-names: >>>> - items: >>>> - - const: nvme >>>> - - const: ans >>>> - >>> Keep properties defined at the top level. More below. >>> >>>> resets: >>>> maxItems: 1 >>>> >>>> @@ -68,25 +59,53 @@ properties: >>>> >>>> The SART address filter is documented in iommu/apple,sart.yaml. >>>> >>>> -if: >>>> - properties: >>>> - compatible: >>>> - contains: >>>> - enum: >>>> - - apple,t6000-nvme-ans2 >>>> - - apple,t6020-nvme-ans2 >>>> -then: >>>> - properties: >>>> - power-domains: >>>> - minItems: 3 >>>> - power-domain-names: >>>> - minItems: 3 >>>> -else: >>>> - properties: >>>> - power-domains: >>>> - maxItems: 2 >>>> - power-domain-names: >>>> - maxItems: 2 >>>> +allOf: >>>> + - if: >>>> + properties: >>>> + compatible: >>>> + contains: >>>> + const: apple,t8132-nvme-ans2 >>>> + then: >>>> + properties: >>>> + reg: >>>> + items: >>>> + - description: NVMMU registers >>>> + - description: NVMe registers >>>> + - description: ANS2 co-processor control registers >>>> + reg-names: >>>> + items: >>>> + - const: nvmmu >>>> + - const: nvme >>>> + - const: ans >>> New entries go on the end. >> Ack >>> So nvmmu last and defined at the top level. >> I did read the docs which said the properties should always be >> introduced at the top-level, however I couldn't figure out how to >> describe the intended constraints in this way. >>> Then this is just 'minItems: 3' >>> >>>> + else: >>>> + properties: >>>> + reg: >>>> + items: >>>> + - description: NVMe and NVMMU registers >>>> + - description: ANS2 co-processor control registers >>>> + reg-names: >>>> + items: >>>> + - const: nvme >>>> + - const: ans >>> And 'maxItems: 2' on these 2. >> When the three items are defined at the top-level, I can't seem to make >> the dtbs_check work: >> >> [...] >> arch/arm64/boot/dts/apple/t8112-j413.dtb: nvme@27bcc0000 >> (apple,t8112-nvme-ans2): reg: [[2, 2076966912, 0, 262144], [2, >> 2000683008, 0, 16384]] is too short >>     from schema $id: http://devicetree.org/schemas/nvme/apple,nvme-ans.yaml >> arch/arm64/boot/dts/apple/t8112-j413.dtb: nvme@27bcc0000 >> (apple,t8112-nvme-ans2): reg-names: ['nvme', 'ans'] is too short >>     from schema $id: http://devicetree.org/schemas/nvme/apple,nvme-ans.yaml >> [...] >> >> despite this compatible falling into the "... else ... maxItems: 2" branch >> >> Would it be acceptable to define the reg and reg-names with just >> minItems: 2, maxItems: 3, but without specific items or descriptions, >> and then add the compatible-specific items and descriptions in the >> conditional part below? > No, because you do workaround for your own introduced problem. If you > list the entries in top level in correct order, then everything will > work fine with Rob's answer/comment. > > This is your case: > https://elixir.bootlin.com/linux/v6.11-rc6/source/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml#L39 I had them in the correct order (nvmmu last), but was missing the minItems: 2 in the top-level. Problem solved. > > This is not your case: > https://elixir.bootlin.com/linux/v6.11-rc6/source/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml#L127 > Unless you provide arguments why it is. > > Best regards, > Krzysztof Thanks for the patience, - Yureka