On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > Acked-by: Mark Rutland <[email protected]> > > > > > > Signed-off-by: Sudeep Holla <[email protected]> > > > > > > --- > > > > > > 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
