linux-kernel - Re: [PATCH 4/4] soc: renesas: rcar-sysc: Fix power domain control after system resume

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]

Date:   Mon, 10 Dec 2018 12:47:28 +0100
From:   Simon Horman <horms@...ge.net.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] soc: renesas: rcar-sysc: Fix power domain control
 after system resume

On Thu, Dec 06, 2018 at 09:22:24AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Dec 5, 2018 at 10:21 PM Simon Horman <horms@...ge.net.au> wrote:
> > On Wed, Dec 05, 2018 at 04:39:45PM +0100, Geert Uytterhoeven wrote:
> > > To control power to a power domain, the System Controller (SYSC) needs
> > > the corresponding interrupt source to be enabled, but masked, to prevent
> > > the CPU from receiving it.
> > >
> > > Currently this is handled in the driver's probe() routine, and set up
> > > for every domain present, even if it will not be controlled directly by
> > > SYSC (CPU domains are powered through the APMU on R-Car Gen2 and later).
> > >
> > > On R-Car Gen3, PSCI powers down the SoC during system suspend, thus
> > > loosing any configured interrupt state.  Hence after system resume, power
> > > domains not controlled through the APMU (e.g. A3IR, A3VC, A3VP) fail to
> > > power up.
> >
> > I corrected the spelling of losing when applying this patch.
> 
> Checkpatch complained about that as well, so I did some investigation, and
> decided to keep it... Was I wrong?

I will not claim to be an expert but  at the time I thought
checkpatch was right.