linux-kernel - Re: [PATCHv2] reset: ti-rstctrl: use the reset-simple driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqK4gLh17H+=5qPHB6Zd+s2Nn9mYQHbRsP=7DLFMTcstig@mail.gmail.com>
Date:   Thu, 8 Mar 2018 16:25:58 -0600
From:   Rob Herring <robh@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Philipp Zabel <philipp.zabel@...il.com>,
        Paul Parsons <lost.distance@...oo.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        linux-omap <linux-omap@...r.kernel.org>,
        Dave Gerlach <d-gerlach@...com>,
        Mark Rutland <mark.rutland@....com>, Nishant Menon <nm@...com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Suman Anna <s-anna@...com>, Tero Kristo <t-kristo@...com>
Subject: Re: [PATCHv2] reset: ti-rstctrl: use the reset-simple driver

On Thu, Mar 8, 2018 at 10:02 AM, Tony Lindgren <tony@...mide.com> wrote:
> Hi,
>
> * Rob Herring <robh@...nel.org> [180308 02:49]:
>> On Wed, Mar 07, 2018 at 10:21:43AM -0800, Tony Lindgren wrote:
>> > +TI RSTCTRL Reset Controller
>> > +
>> > +Required properties:
>> > +- compatible : "ti,rstctrl"
>> > +- reg : Should contain 1 register ranges(address and length)
>> > +- #reset-cells: 1
>> > +
>> > +Example:
>> > +   prm_gfx: prm@...0 {
>> > +           compatible = "simple-bus";
>>
>> What's a PRM?
>
> PRM is power and reset manager. There is one instance per
> interconnect instance (clockdomain). PRM shows the status of
> the connected devices in the interconnect, such as device
> context lost and hardware wake-up dependencies. It also
> contains a single reset controller register for external
> accelerators such as DSP. The reset controller instance then
> has 1 - 3 bits for external accelerator sub device resets.
> Then there is a reset status register that shows the reset
> reason for the external accelerator.
>
>> > +           #address-cells = <1>;
>> > +           #size-cells = <1>;
>> > +           ranges = <0 0x1100 0x100>;
>>
>> And what else is in this range?
>
> In PRM, there are also registers for each interconnect device
> context lost and wake-up dependencies. We don't have a driver
> for that yet, it's handled by the SoC init code currently.

Regardless of having/needing a driver, you should take a stab at doing
the binding at least. It doesn't make sense to do the binding of the
child without doing the parent.

> Unlike the binding for reset controller, the binding for
> wake-up dependencies and context lost should look similar
> binding to the clkctrl clock binding we have. That's because
> there are tons of those registers.
>
>> > +
>> > +           gfx_rstctrl: rstctrl@4 {
>> > +                   compatible = "ti,rstctrl";
>> > +                   reg = <0x4 0x4>;
>>
>> Anytime I see a single register in DT I worry about scaling. How many of
>> these in an SoC?
>
> There are not many instances of the reset controller. There
> is one register per interconnect instance for external
> accelerators, so about 3 - 10 reset controller registers
> per SoC.

Okay, seems a reasonable number.

However, couldn't you just have PRM node(s) and have that register as
a simple reset driver (along with anything else it handles).

Rob