[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ba87a3f-e2f4-4caf-8d23-aa78caaba45a@ti.com>
Date: Thu, 1 Feb 2024 17:50:00 -0600
From: Andrew Davis <afd@...com>
To: Rob Herring <robh@...nel.org>
CC: Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
Santosh
Shilimkar <ssantosh@...nel.org>,
Krzysztof Kozlowski
<krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Sebastian Reichel <sre@...nel.org>,
Vignesh Raghavendra <vigneshr@...com>,
<linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 02/12] dt-bindings: arm: keystone: ti-sci: Add
reboot-controller child node
On 2/1/24 5:03 PM, Rob Herring wrote:
> On Wed, Jan 31, 2024 at 04:19:47PM -0600, Andrew Davis wrote:
>> The TI-SCI firmware supports rebooting the system in addition to the
>> functions already listed here, document child node for the same.
>>
>> Signed-off-by: Andrew Davis <afd@...com>
>> ---
>> .../devicetree/bindings/arm/keystone/ti,sci.yaml | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
>> index c24ad0968f3ef..e392175b33c74 100644
>> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
>> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
>> @@ -83,6 +83,10 @@ properties:
>> type: object
>> $ref: /schemas/reset/ti,sci-reset.yaml#
>>
>> + reboot-controller:
>> + type: object
>> + $ref: /schemas/power/reset/ti,sci-reboot.yaml#
>
> Don't need a ref just for a single property.
>
> But then why do we need a node here at all? Can't you assume reboot
> support for TI-SCI firmware (i.e. based on the parent node). Then you
> don't need a DT update to add the feature.
>
We could yes, but then again we could do the same for all the
child nodes of this system-controller parent node. Might even
have been better that way, for now I'm trying to be consistent
with what is already here (child node per service provided,
even though the services are always the same).
Andrew
> Rob
Powered by blists - more mailing lists