linux-kernel - RE: [PATCH v12 2/9] dt-bindings: reset: Add bindings for SP7021 reset 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: <7a344146331847ce88d26716fc3b6380@cqplus1.com>
Date:   Fri, 1 Apr 2022 08:24:45 +0000
From:   qinjian[覃健] <qinjian@...lus1.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Rob Herring <robh+dt@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        "Stephen Boyd" <sboyd@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Russell King - ARM Linux" <linux@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>
Subject: RE: [PATCH v12 2/9] dt-bindings: reset: Add bindings for SP7021 reset
 driver

> 
> On Thu, Mar 31, 2022 at 10:29 AM Qin Jian <qinjian@...lus1.com> wrote:
> 
> > +/* mo_reset0 ~ mo_reset9 */
> > +#define RST_SYSTEM             0x00
> > +#define RST_RTC                        0x02
> > +#define RST_IOCTL              0x03
> > +#define RST_IOP                        0x04
> > +#define RST_OTPRX              0x05
> > +#define RST_NOC                        0x06
> > +#define RST_BR                 0x07
> > +#define RST_RBUS_L00           0x08
> > +#define RST_SPIFL              0x09
> > +#define RST_SDCTRL0            0x0a
> > +#define RST_PERI0              0x0b
> > +#define RST_A926               0x0d
> > +#define RST_UMCTL2             0x0e
> > +#define RST_PERI1              0x0f
> > +
> > +#define RST_DDR_PHY0           0x10
> > +#define RST_ACHIP              0x12
> > +#define RST_STC0               0x14
> > +#define RST_STC_AV0            0x15
> > +#define RST_STC_AV1            0x16
> > +#define RST_STC_AV2            0x17
> 
> The list looks like these definitions just match the hardware, which means you
> don't have to define them as a binding at all, just use the hardware numbers
> directly in the dt, as you do for interrupts or gpio numbers.
> 
> If the hardware does not have a sane way of mapping reset lines to a particular
> hardware number, then you may have to define a binding, but in that case just
> use consecutive integer numbers, not hexadecimal numbers.
> 
>        Arnd

You are right, these definitions does match the hardware, In reset-sunplus.c:
static int sp_reset_status(struct reset_controller_dev *rcdev,
                           unsigned long id)
{
        struct sp_reset *reset = to_sp_reset(rcdev);
        int index = id / BITS_PER_HWM_REG;
        int shift = id % BITS_PER_HWM_REG;
        u32 reg;

        reg = readl(reset->base + (index * 4));

        return !!(reg & BIT(shift));
}
the 'id'  is these value passed from dt.

I'll remove this file & update dt, thanks for your comments.