From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 759181E260C for ; Mon, 29 Jun 2026 03:47:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782704834; cv=none; b=L59WCvbs+RTTZ6UnGmt+m2nFXzpuE3VzxukoiWqfSnv+2GCeavZc6WpwAj9tMwA+HGq0V1PBmN2XXiXBOGcLR0LfxYbEk99wHnOxXg6lrkkcyWnuH7zLGDfWvctHFhpCkY7cWEdhw9lZvex/Akwpy++YysILz+oEweu+YtFdAew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782704834; c=relaxed/simple; bh=5PshR+IvyLF9JmCnWECgYoo5CmXC1kxLnDlSDUXXqWY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FRV8W8foucgK2AENSfHMyUFXXYCxtVPnKWbSK66/O6Lb+OCLxQruGQ3O6dK0jLams+kSq5+aW0oRlWNMvGM9gjyuFan4Jbfw0U4xLXnDO40llXLKIREXflKnSU0TvltYXm9vfP4dkbU4nRrcYAIn8Syn17utHKz1Gxk36alqCIs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NWzyDcOi; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NWzyDcOi" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-37fa53bc22dso1753606a91.3 for ; Sun, 28 Jun 2026 20:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782704833; x=1783309633; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=z4glFEoTlSdEvWgu5Qz9SrofqHmqDCDT1GO9md08oew=; b=NWzyDcOi7LUY7WIqJISxWh0SV7sQtBcXfYNRruamqewDVFtfHDCIZleBx9sYOEeEvF iS/4K4qsc2ZKiUslQq+85XzO7vXtxcng/FA4z69/vA7tm7N7g1+yb2K8Wz/cogW/Zjsq uYmTSZpWASzEKAR4rrzZtJw4L0j2r/pf6H3WgqWTGhJ8zCcMCklFHLORFRQ9454yUzWL So2DCyCxSnT4n91TD9ys6J5FaSITnkw+TWTx8nTkPauvEGjIjjC6mnqA8Z7jXAPdwzdj Xu5uKcZtXeGZOe1SwwkiNFu8cUTQ+CRn1wSuF8lzPNXZvQCs/as9/TFOWGcPohrPGRGg jWzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782704833; x=1783309633; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z4glFEoTlSdEvWgu5Qz9SrofqHmqDCDT1GO9md08oew=; b=jLV52Yt6pJIP0jLo64isO0k7Wym3rGqN6ocWD31mIBVl585PjViTQVre7MxTwIi81v wCBZU08ehrNSWaM9tn9GtKtknGHxnyhLwlJh7snTKobLw1Cje1aLuiAKtSp0nt4WiBsc ngFqLtpL/Nd8l/M38DGcNQOsMKNDMOI4Q8BajrqFkuCab+dqQUhJewCZEFeTZ6zCKN77 zT5P5L7KVPfTcNz1VIrGmas70JLCUbaaWhB+Y4Rnp2D9FP+BPnxET6eK7s/2NAaYhzv9 ccVG5M03ssU5/sCp0uxpEf23vR8BATZ803dyoSgBgGBU1BA2pHGKQl3T8FisFzjkSTPf rdlw== X-Forwarded-Encrypted: i=1; AHgh+RoYlo0Jv3/Id8ei/nmgTAU7lQIqix3wx+yOlaaee42WJ+IX/SZtiuqUgTKaexG9a3qN0bXZQ06zi9B9ras=@vger.kernel.org X-Gm-Message-State: AOJu0YxtDouPZJyYob1rIY3S2+D9HZoznDeMTfonCdxy0t9aXaw9yDFH caJbPo/EcxvMOL7PULjET05lQ45cXcCxRx8JjeBHwrZIhDqpTRqPGdey1K0z0w== X-Gm-Gg: AfdE7cl7cwhS/J7bKE9UYa7sbJ+cJmhMkUiKJFR2I4fcmdwH1UYSGu+UBa17gBU1z2V al3lGQT24C6hkUyY1rBuZ9IbHW4u97GJZMzbtNfymDygjG5+As8+l1QS5HqAxiu1jsmNdai4xNG juHrcZBLPsbq9B9GIbH2kvzTUjEPJhTL/4XqJQStk9CkVDmXRYlJiKNAdko1kqWriWrkTTrZFGG VCLMbkyhOoctEc2ApJmxq/OKY8K16sNfHc5matvmRzUxrrnGVikQwbboCjUtNVEDAlyMeI26APl 4c6Nsdme16TzB5NEJ3hsPSwcv/FUSSLwBtukZo5ynnyYsAc1wVtulMNkpgLniEGxgZ81YdEMfIn 1q8/swPYgh9EfX+14D90PmvWrKV3gDF1PpHYDxtG+jhLhb3SPGDzME0R32DHKn6+TjF4gYSOUe+ 4bC1Crt2ZIHQYXjw/x4XN6n4k+2J4yPsq1YcAgJdLjt6gv40ICCPzkV2CH9y5/0ehTcw== X-Received: by 2002:a17:90b:28d0:b0:37f:9ce3:ca92 with SMTP id 98e67ed59e1d1-37f9ce3cb4emr6630306a91.27.1782704832538; Sun, 28 Jun 2026 20:47:12 -0700 (PDT) Received: from [192.168.0.100] (60-250-196-139.hinet-ip.hinet.net. [60.250.196.139]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37eaff87f61sm4687705a91.17.2026.06.28.20.47.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2026 20:47:11 -0700 (PDT) Message-ID: Date: Mon, 29 Jun 2026 11:47:03 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants To: Icenowy Zheng , Conor Dooley Cc: Conor Dooley , maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, ychuang3@nuvoton.com, schung@nuvoton.com, yclu4@nuvoton.com, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260625094449.708386-1-a0987203069@gmail.com> <20260625094449.708386-2-a0987203069@gmail.com> <20260625-bobbing-annotate-d1c4d6874ee2@spud> <20260626-astrology-mural-853d3860e048@wendy> <20260626-everybody-epilogue-8fb298a54981@wendy> <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn> Content-Language: en-US From: Joey Lu In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/26/2026 5:33 PM, Icenowy Zheng wrote: > 在 2026-06-26五的 10:26 +0100，Conor Dooley写道： >> On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote: >>> 在 2026-06-26五的 08:19 +0100，Conor Dooley写道： >>>> On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote: >>>>> 在 2026-06-25四的 17:33 +0100，Conor Dooley写道： >>>>>> On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote: >>>>>>> +allOf: >>>>>>> +  - if: >>>>>>> +      properties: >>>>>>> +        compatible: >>>>>>> +          contains: >>>>>>> +            const: thead,th1520-dc8200 >>>>>>> +    then: >>>>>>> +      properties: >>>>>>> +        clocks: >>>>>>> +          minItems: 5 >>>>>>> +          maxItems: 5 >>>>>>> + >>>>>>> +        clock-names: >>>>>>> +          minItems: 5 >>>>>>> +          maxItems: 5 >>>>>> All the maxItems here repeat the maximum constraint and do >>>>>> nothing. >>>>>> >>>>>> Since you didn't change the minimum constraint at the top >>>>>> level, >>>>>> your >>>>>> minItems also do nothing. >>>>>> >>>>>>> + >>>>>>> +        resets: >>>>>>> +          minItems: 3 >>>>>>> +          maxItems: 3 >>>>>>> + >>>>>>> +        reset-names: >>>>>>> +          minItems: 3 >>>>>>> +          maxItems: 3 >>>>>>> + >>>>>>> +      required: >>>>>>> +        - resets >>>>>>> +        - reset-names >>>>>> Both conditional sections have this, but the original binding >>>>>> doesn't >>>>>> require these for the thead device. This is a functional >>>>>> change >>>>>> therefore and shouldn't be in a patch calling itself >>>>>> "generalise >>>>>> for >>>>>> single ended variants". >>>>> Well yes they're required. >>>>> >>>>> Should I send a patch adding the `thead,th1520-dc8200` part of >>>>> the >>>>> schema? >>>> If you mean the code above, no. Adding a conditional section when >>>> there's only that compatible doesn't make sense. >>>> >>>> What you could do is just add it at the top level though, which >>>> would >>>> also benefit this patch since it'd not have to be conditionally >>>> added >>>> for the new nuvoton device. >>>> Just note in your commit message about what the ABI impact of the >>>> change >>>> to required properties is (effectively nothing because it's >>>> optional >>>> in >>>> the driver and the only user has the properties). >>> Okay, I will craft such a patch and send it. >>> >>>>>>> + >>>>>>> +        resets: >>>>>>> +          minItems: 1 >>>>>>> +          maxItems: 1 >>>>>>> + >>>>>>> +        reset-names: >>>>>>> +          items: >>>>>>> +            - const: core >>>>>> This is just maxItems: 1. >>>>> Well the implicit rules of DT binding schemas are quite >>>>> weird... >>>> I don't think it is that strange, as the binding has >>>>   reset-names: >>>>     items: >>>>       - const: core >>>>       - const: axi >>>>       - const: ahb >>> Ah does the list constraint the order of items? If it constrains >>> the >> It does, yes. >> Alternatively, using an enum permits free ordering. > Ah in this case this should be converted to an enum, I think. > > Should I send a patch for converting it? > > Thanks, > Icenowy Thank you all for the detailed review and discussion, it really helped clarify the right approach. Since I will supply all four clocks with the same phandle for core/axi/ahb, and only one reset "core" for MA35D1, the ordering constraint in the `items` list is not a problem, "core" is already the first entry. There is no need to convert to an enum. Regarding the clock situation for the MA35D1: I agree with supplying all four clocks (core, axi, ahb, pix0) in the devicetree, even though the MA35D1 clock controller gates core/axi/ahb with a single bit. The DT will use the same clock phandle for core, axi, and ahb:   clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;   clock-names = "core", "axi", "ahb", "pix0"; This correctly models the hardware topology. Since all three names resolve to the same underlying clock node, the CCF's standard enable refcounting handles the shared gate correctly without any custom implementation needed. I will also revert the change in patch 4/7 that made axi and ahb clocks optional, since they will now always be provided in the devicetree. Regarding moving `resets` and `reset-names` to the top-level `required:`, I will wait for Icenowy's patch to land before sending v6 to avoid duplicating the work. In v6 I will update patch 1/7 with: - Update the subject to "dt-bindings: display: verisilicon,dc: add   support for nuvoton,ma35d1-dcu" - Lower `clocks`/`clock-names` `minItems` to 4 at the top level - Remove the `thead,th1520-dc8200` conditional block entirely - Keep only the `nuvoton,ma35d1-dcu` conditional block, using only   `maxItems: 4` for clocks/clock-names and `maxItems: 1` for   resets/reset-names to tighten the top-level constraints BR, Joey >>> order, it partly breaks the intention of having names; if it does >>> not >>> constrain the order, it needs to be clarified that the required 1 >>> reset >>> is core instead of the other two. >> Given the discussion we're having on the clocks, I wonder if this is >> also an oversimplification and the IP has three resets inputs hooked >> up >> to one output of the reset controller (or 3 outputs controlled by one >> bit..).