From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 8389D31A04E for ; Thu, 12 Feb 2026 12:03:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770897820; cv=none; b=PkKPgSRIg7//BA9p3fZ7vzem/g/I+mz+gQ6w3xRwC+2f/6sKiUebKFO3bTk2N4q8oEL+AYlS01nBposnqhsZwjf/sLxet0tUpdFzZgroA2qGUZUohyJ9P4v0a8aIWQ8XrijfYvLfD+uSo4b9Ku67PIqzPFtlu0xGb13fdYoWRzU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770897820; c=relaxed/simple; bh=orrgARdRVXY24gkPcC6wmruEl81dP2QFKl4esYE/FQM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=YDhAnDQJCoKR4BHyv7yb/6OxL2orOhWo4pX1GFooVwLl229SRny1mtErTcO7ISCsJdVJKYYiBdfx130D4imMoJscN7Ybc8CDnxUikstQ8QRNoHWDx+C/GgwtjS72n+g25umYqKr0oKI/otT9wEka/oRmjK+QFV40/IgpGXfbdBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=hPevaUBM; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="hPevaUBM" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-436e8758b91so2957316f8f.0 for ; Thu, 12 Feb 2026 04:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770897817; x=1771502617; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=IPXBLe0yJUYbIoGyT5kMiHrz15M67LzrqjA/DC/nqFM=; b=hPevaUBMTdCmjZpAIUz7m6NyBYoypy0QXWXugrn8NpEoAZXFHNDiiVOl2Smyqm4YPk duPm5qjppAE7oLpC8XXBzbDWq60ZRcG12QbaR2uXf7ONwcFatznIFD+oNs4fpUh2Ui8E xlgvLjnhdqxdRlZSIPTM9nCFj4AY0/En66eOiSDmMGrA0z4qIhRjtp+cGju6MOgub0d8 F2mg7IFc+KbfPOAI8mt/PwHDSYaDxlWkX2hA7gjiivtVKrQ4xD5WSMGQLJkQjeAHaFcM APc/D+5Wdu4XdpcFQhN7B6YXPd4088r7i6+fHkw42j0DTzABWXajFLe+BzuFDXBda3ZH KDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770897817; x=1771502617; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IPXBLe0yJUYbIoGyT5kMiHrz15M67LzrqjA/DC/nqFM=; b=JXTO/7gb/xIBhK6A+6NjTZaOSFUgyksSMNyeyl0GuHQvmSf2b18zDtfESJo38X3k5s 59z1eCSSJg9698JJUqm5VJOvKTzTxUD10+maMFd+n+8c1F2l0pw9wNPbRgoI8K0NfAQJ p9hxJ+WQinFo8WetEE2qwIWjCA0BHzar/d+ulexL08IF22caPxKHgBLVUCLVp1c8imtZ dZUqI9kjIS/EhNRy/7UXAYz9CTyboNMVvQ0nU1yUn4bLQ4kZIV1YhWVS+gkA53nG7/z0 r5LLasl3WB9E9Pp4NqhHHQivKpZGo0khWIkRlfyBLh+lk0TslauTpYIJc6dDdCG3CUHM LJ5g== X-Forwarded-Encrypted: i=1; AJvYcCXZQyCzHGmwUQOphcjRf87OtQyDog/rec7SnJeeIzCl0ojAPGgt4K+UC9Jb4UfDJoLtuf1BVNlo+r6pOOE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+AbfcgGQxqPKgBVFNHgSAiCZ+e9T13nz7HTNG5kOnyulDOYAH i0oztKDSSuVfeHO7P6g5/l5bi8c38DYWnahW1cfRueHYeiO8/dVTJ7hy6bvbJX7mHgo= X-Gm-Gg: AZuq6aICrUdQM0fYD9Zr0nl/vE8bbJfhLED4lV61img0vBf4nPl5xiCVfIDxuXAskW1 CP+yL0OXNxoIZ/RW2CT0JTplPsUNbjnvZhB26/PWf29D6+zMq54DRJ7tmeDrCYYXjXTUGXabz/2 6iasOb/zloDBrX2aylfZ/NmGry1xgbXFtIODEoh/yZCgndgATeRe9kU3Aj0O77Bkx0H7X6iopur H/bSpNpXg70aXjqka0Ol5rYZQacJrHnEJ6KwB+e383w7w6tyMpXm0jWMCJfYmazO3BinW8eULM0 Q4SxMCXayjahpg/y7p0MbuFvvO3XAF434fR2/6TZq+47Zk2UMIZyn7BGstvWsN8zNZd3/DZVFzu Wm0IvKPBgerkkEi6gTXhfBxTJv2wII6pIppFYzw86ZBT0Htb+qZUUbSb5FP+oWwg2udivAvd1P5 GxCaAzqaA7F7B3X6ykMjHUt2Qga/nw99r/+pTIJW9g X-Received: by 2002:a05:6000:2901:b0:436:233c:c7c2 with SMTP id ffacd0b85a97d-4378aa0c732mr4446267f8f.16.1770897816772; Thu, 12 Feb 2026 04:03:36 -0800 (PST) Received: from draszik.lan ([212.129.82.233]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43783dfc8b9sm11365172f8f.24.2026.02.12.04.03.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 04:03:36 -0800 (PST) Message-ID: Subject: Re: [PATCH v5 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children From: =?ISO-8859-1?Q?Andr=E9?= Draszik To: Rob Herring Cc: Krzysztof Kozlowski , Alim Akhtar , Conor Dooley , Krzysztof Kozlowski , Ulf Hansson , Liam Girdwood , Mark Brown , Peter Griffin , Tudor Ambarus , Juan Yescas , Will McVicker , kernel-team@android.com, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Marek Szyprowski Date: Thu, 12 Feb 2026 12:03:38 +0000 In-Reply-To: <20260211211229.GA3882182-robh@kernel.org> References: <20260205-gs101-pd-v5-0-ede49cdb57a6@linaro.org> <20260205-gs101-pd-v5-4-ede49cdb57a6@linaro.org> <20260211211229.GA3882182-robh@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-2+build4 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Rob, On Wed, 2026-02-11 at 15:12 -0600, Rob Herring wrote: > On Thu, Feb 05, 2026 at 09:42:32PM +0000, Andr=C3=A9 Draszik wrote: > > The power domains are a property of / implemented in the PMU. As such, > > they should be modelled as child nodes of the PMU. > >=20 > > Tested-by: Marek Szyprowski > > Signed-off-by: Andr=C3=A9 Draszik > > --- > > v4: > > - consistent quoting using " (Krzysztof) > > - add samsung,dtzpc to example > >=20 > > Note: Ideally, the newly added properties (ranges, etc.) should only be > > 'required' if "^power-domain@[0-9a-f]+$" exists as a patternProperty, > > as they're needed only in that case. As-is, this patch now causes > > warnings for existing DTs as they don't specify the new properties (and > > they shouldn't need to).=20 >=20 > We can't have warnings added if they aren't valid. >=20 > > Only if DTs are updated to include > > power-domains, such an update should also add the new properties. > >=20 > > I've not been able to come up with the correct schema syntax to achieve > > that. dependencies, dependentRequired, and dependentSchemas don't seem > > to support patterns. Similarly, > > =C2=A0 - if: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 required: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - ... > > =C2=A0=C2=A0=C2=A0 then: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 required: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - ... > >=20 > > doesn't allow patterns in the 'if' block (or I didn't get the syntax > > right). > >=20 > > Rob said in > > https://lore.kernel.org/all/20251010141357.GA219719-robh@kernel.org/ > > that this is a known limitation in json-schema. >=20 > For a given compatible, you should either have child nodes or you don't.= =20 > The h/w is not variable. So something like this should work: >=20 > if: > =C2=A0 properties: > =C2=A0=C2=A0=C2=A0 compatible: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 contains: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const: foo,bar >=20 > then: > =C2=A0 required: > =C2=A0=C2=A0=C2=A0 - ranges > =C2=A0=C2=A0=C2=A0 - '#address-cells' > =C2=A0=C2=A0=C2=A0 - '#size-cells' >=20 Thanks Rob, yes, that works in general, but unfortunately in this case exis= ting DTs don't specify ranges etc for the google,gs101-pmu compatible. (This bin= ding is specifically for google,gs101-pmu only anyway). The above suggestion will cause the same validation warnings for existing D= Ts which is no different to just adding those properties to the top-level requ= ired: as my patch is doing. Unless I misunderstood your suggestion. The compatible doesn't change with these patches. So I'm not sure how to ma= ke your suggestion work without causing warnings for existing DTs. We can eith= er have an old incomplete DT+binding: pmu_system_controller: system-controller@17460000 { compatible =3D "google,gs101-pmu"; reg =3D <0x17460000 0x10000>; }; or the new one: pmu_system_controller: system-controller@17460000 { compatible =3D "google,gs101-pmu"; reg =3D <0x17460000 0x10000>; ranges; #address-cells =3D <1>; #size-cells =3D <1>; power-domain@1c00 { compatible =3D "google,gs101-pd"; reg =3D <0x1c00 0x80>; #power-domain-cells =3D <0>; label =3D "eh"; samsung,dtzpc =3D <&dtzpc_eh>; }; }; I.e. in the old case (when binding + DT were incomplete) ranges etc. are not 'required' (and shouldn't be), while with the power-domain@[0-9a-f]+ child node(s) added, ranges etc must be specified.=20 If power-domain@[0-9a-f]+ wasn't a pattern, it'd be easy, but I really want it to be a pattern, not least because there are so many instances. What works (at the top level) is: dependentRequired: power-domain@1e00: [ranges] but it would require spelling out all the instances instead of a pattern. T= he following (or various variations I've tried) doesn't: dependentRequired: power-domain@.*: [ranges] I've also tried to come up with something involving dependentSchemas:, but = to no avail. Similarly, allOf: - if: anyOf: - required: [power-domain@1e00] - required: [power-domain@2000] then: required: - ranges works, but when using a regex, it doesn't: allOf: - if: anyOf: - required: [power-domain@.*] then: required: - ranges I've also tried: allOf: - if: required: - "^power-domain@[0-9a-f]+$" then: required: - ranges and anyOf: - required: - power-domain@1e00 - ranges - reg - required: - reg and anyOf: - required: - "^power-domain@[0-9a-f]+$" - ranges - reg - required: - reg None of these seem to do what I would like (even the non-regex one). Cheers, Andre'