[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff53263d-813f-43c3-9090-e73dc0031949@samsung.com>
Date: Tue, 21 Jan 2025 22:58:29 +0100
From: Michal Wilczynski <m.wilczynski@...sung.com>
To: Philipp Zabel <p.zabel@...gutronix.de>, mturquette@...libre.com,
sboyd@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
drew@...7.com, guoren@...nel.org, wefu@...hat.com, jassisinghbrar@...il.com,
paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
frank.binns@...tec.com, matt.coster@...tec.com,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
airlied@...il.com, simona@...ll.ch, ulf.hansson@...aro.org,
jszhang@...nel.org, m.szyprowski@...sung.com
Cc: linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
dri-devel@...ts.freedesktop.org, linux-pm@...r.kernel.org
Subject: Re: [RFC v3 07/18] dt-bindings: reset: Add T-HEAD TH1520 SoC Reset
Controller
On 1/21/25 09:35, Philipp Zabel wrote:
> On Mo, 2025-01-20 at 18:21 +0100, Michal Wilczynski wrote:
>> Add a YAML schema for the T-HEAD TH1520 SoC reset controller. This
>> controller manages resets for subsystems such as the GPU within the
>> TH1520 SoC.
>
> This mentions "resets", plural, but the #reset-cells = <0> below and
> the driver implementation look like there only is a single reset
> control (for the GPU).
>
>>
>> Signed-off-by: Michal Wilczynski <m.wilczynski@...sung.com>
>> ---
>> .../bindings/reset/thead,th1520-reset.yaml | 44 +++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 45 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
>> new file mode 100644
>> index 000000000000..c15a80e00935
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
>> @@ -0,0 +1,44 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: https://protect2.fireeye.com/v1/url?k=9a1e91c0-fb9584d9-9a1f1a8f-74fe485cbfec-4ac5a7f48f7ed305&q=1&e=57e2ad34-940c-48d4-b365-a5719457bd20&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Freset%2Fthead%2Cth1520-reset.yaml%23
>> +$schema: https://protect2.fireeye.com/v1/url?k=40dd1447-2156015e-40dc9f08-74fe485cbfec-5ae5fe2734d49263&q=1&e=57e2ad34-940c-48d4-b365-a5719457bd20&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
>> +
>> +title: T-HEAD TH1520 SoC Reset Controller
>> +
>> +description:
>> + The T-HEAD TH1520 reset controller is a hardware block that asserts/deasserts
>> + resets for SoC subsystems.
>
> Again, plural.
Yeah should be singular sorry.
>
>> +
>> +maintainers:
>> + - Michal Wilczynski <m.wilczynski@...sung.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - thead,th1520-reset
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + "#reset-cells":
>> + const: 0
>
> Should this be "const: 1" instead?
Right now I'm not planning to extend by more resets, I've thought about
this during the discussion on v2 of this patchset. At this point I just
can't see more interesting resets to have. Vendor kernel implements WDT
and NPU. I don't think NPU driver will be upstream anytime soon. That
would leave WDT reset potentially.
>
> regards
> Philipp
>
>
Powered by blists - more mailing lists