linux-kernel - Re: [PATCH v3] firmware/psci: add support for SYSTEM

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] [day] [month] [year] [list]

Message-ID: <CAPDyKFpjKAVPhpRmtO=7Boyh7aLv-BUQLY5GTKcQrM6gGP9=tg@mail.gmail.com>
Date:   Mon, 15 Apr 2019 12:14:59 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Mark Rutland <mark.rutland@....com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Aaro Koskinen <aaro.koskinen@...ia.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Florian Fainelli <f.fainelli@...il.com>,
        Michal Simek <michal.simek@...inx.com>
Subject: Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi
<lorenzo.pieralisi@....com> wrote:
>
> On Fri, Apr 12, 2019 at 02:42:22PM +0100, Sudeep Holla wrote:
> > On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> > > Sudeep, Lorenzo, Mark
> > >
> > > On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <sudeep.holla@....com> wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, April 12, 2019 12:02:27 PM CEST Sudeep Holla wrote:
> > > > > > PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> > > > > > where the semantics are described by the PSCI specification itself as
> > > > > > well as vendor-specific resets. Currently only system warm reset
> > > > > > semantics is defined as part of architectural resets by the specification.
> > > > > >
> > > > > > This patch implements support for SYSTEM_RESET2 by making using of
> > > > > > reboot_mode passed by the reboot infrastructure in the kernel.
> > > > > >
> > > > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> > > > > > Acked-by: Mark Rutland <mark.rutland@....com>
> > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@....com>
> > > > > > ---
> > > > > >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> > > > > >  include/uapi/linux/psci.h |  2 ++
> > > > > >  2 files changed, 25 insertions(+), 1 deletion(-)
> > > >
> > > > [...]
> > > >
> > > > > > --
> > > > >
> > > > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > > > >
> > > >
> > > > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > > > your tree. No worries, I will rebase and repost soon. I want testing
> > > > by xilinx or Aaro Koskinen before that.
> > > >
> > > > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > > > result. :-)
> > > > >
> > > >
> > > > I can understand, I assure it's one off :)
> > >
> > > Speaking about that. I would gladly help out to host a git tree to
> > > collect patches that you have acked. In this way, we can, for example,
> > > get the patches pre-tested in linux next before we send the
> > > pull-request.
> > >
> > > If you think sounds like a good idea, just tell me so I can prepare a
> > > tree for the next release cycle...
> > >
> >
> > For now, I just have this one patch. So if Rafael has queued all your
> > patches, I can just rebase and post it once I get tested-by from Aaro
> > Koskinen, so that Rafael can queue this too. Or are you planning to
> > send PR to Rafael, sorry if I missed details already discussed on the
> > list.
>
> Mark and I can queue PSCI patches as we usually do, we agreed they would
> go via Rafael's tree (thanks) because of dependencies with the PM tree
> (that did not turn out to be there so we could have sent them to arm-soc
> just as well as we usually do), next cycle if and when there are patches
> to be queued we will queue them up and send them upstream ourselves.

Why I wanted them queued via Rafael's tree, is because of the
following series for PSCI that I will post in a a day or two, that has
dependencies to new changes to genpd.

My proposal with a git tree was mainly because of allowing patches to
be pre-tested in Stephen Rothwell's linux-next tree, before you send
the pull request to arm-soc. Or are you saying you already have a tree
for this, but not listed in MAINTAINERS?

In any case, it was just a suggestion to improve the working flow for
better tests etc. Feel free to ignore it.

Kind regards
Uffe