Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Ulf Hansson]

On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> 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@xxxxxxx> 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@xxxxxxx>
> > > > > > Acked-by: Mark Rutland <mark.rutland@xxxxxxx>
> > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
> > > > > > ---
> > > > > >  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