[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL8sjw1o6PzCSRM9FtRx7XLDQg2bWXxo4Yw5t6fnroudw@mail.gmail.com>
Date: Tue, 27 Oct 2020 07:15:57 -0500
From: Rob Herring <robh@...nel.org>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...com>,
Christophe Roullier <christophe.roullier@...com>,
Sascha Hauer <kernel@...gutronix.de>,
Arnaud Pouliquen <arnaud.pouliquen@...com>,
devicetree@...r.kernel.org,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@...md-mailman.stormreply.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: arm: stm32: add simple-mfd compatible
for tamp node
On Mon, Oct 26, 2020 at 4:30 PM Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
>
> Hello Rob,
>
> On 10/26/20 3:36 PM, Rob Herring wrote:
> > On Wed, Oct 21, 2020 at 12:28:55PM +0200, Ahmad Fatoum wrote:
> >> The stm32mp1 TAMP (Tamper and backup registers) does tamper detection
> >> and features 32 backup registers that, being in the RTC domain, may
> >> survive even with Vdd switched off.
> >>
> >> This makes it suitable for use to communicate a reboot mode from OS
> >> to bootloader via the syscon-reboot-mode binding. Add a "simple-mfd"
> >> to support probing such a child node. The actual reboot mode
> >> node could then be defined in a board.dts or fixed up by the bootloader.
> >
> > 'simple-mfd' implies there is no dependency on the parent node for the
> > child (such as the regmap perhaps). Is that the case here?
>
> No, there's a dependency and the Linux driver does syscon_node_to_regmap
> on the device tree node's parent but that's how the syscon-reboot-mode binding
> is documented:
>
> The SYSCON mapped register is retrieved from the
> parental dt-node plus the offset. So the SYSCON reboot-mode node
> should be represented as a sub-node of a "syscon", "simple-mfd" node.
>
> How would you prefer this being done instead?
Well, probably the syscon driver could just probe any children, but
I'm not sure if that would break anyone. So I guess fine as-is.
Reviewed-by: Rob Herring <robh@...nel.org>
Rob
Powered by blists - more mailing lists