Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp476118yba; Fri, 12 Apr 2019 07:20:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1QU6PAh9r6VWfF6QTWyRNLrRsQF4MWZaoyGyJrKlbsq4abrbvna3F6B2ryvN/CCer3RlL X-Received: by 2002:a63:618d:: with SMTP id v135mr53353988pgb.2.1555078851437; Fri, 12 Apr 2019 07:20:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555078851; cv=none; d=google.com; s=arc-20160816; b=FW5CBtZsRMQMVa/GP6BTlL+26gqB6BlaeTMVniAhHJaSbinFO/CFTJeTWEx6/DNv/E iiwFGJ0+EVhWfDriw+Ce+CCvnw5nrZ7ThkxvsMwqNhrg+Dp+yeC8ZryLE9s8CgWSURFJ 5FHCt3QVHeDZ2hdHoTEjlzyi+hJ7nQsrPvHk8NrSPDbXNKRjQu2HslUuZBvNfz23PV25 sO29WjPejEP6I7IFKtipXXXBTGh8iowVDB0xx0bpUP50Pj5PKc5DmD1B7/P0jzQdAKgV Uf6Mj2U/PCtATQ/cOaWy88MCbnF6WFV71TVwHIUORycMtE+LAkDMLuXGY9S7IqtJIEQP K0PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=WTBHFB82cz/2Utod2MW7OcAR4EE+OChxmgwucwVROjI=; b=JPsbEArSEIj644vc4N4serNvLqo4b+dS2SUyWUhtoOOhphvDOJlhW9JduRcRzVH4jW FJ8kcsg+eoexFzE+5VCB1ZeJUyQqqv119UFlMfjnJ4cQd179foc7h9575MaM32yrwzaZ ZWXyNZZZhoNSiJz+JVwISq+LgIu8Q17IhwWfg4QQUi+IbbGr6mvfBfvtA7DCP6yo901r ixbfDuytEDOtSynn4etGaFVadzU0mm5cvhcptO85aHL/t/YF0Dtdqn7Pkf7sfqIxA9o0 oSNG2ROdPapzUmI+rUe96vMsyhnbh7jj0mUi833hdcbTj65b4nmO6kznzOCNh8nS3M0H JJig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a23si36649323pls.188.2019.04.12.07.20.35; Fri, 12 Apr 2019 07:20:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726930AbfDLOTp (ORCPT + 99 others); Fri, 12 Apr 2019 10:19:45 -0400 Received: from foss.arm.com ([217.140.101.70]:33878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726711AbfDLOTo (ORCPT ); Fri, 12 Apr 2019 10:19:44 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0DB02374; Fri, 12 Apr 2019 07:19:44 -0700 (PDT) Received: from red-moon (unknown [10.1.197.39]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E09A3F557; Fri, 12 Apr 2019 07:19:42 -0700 (PDT) Date: Fri, 12 Apr 2019 15:19:37 +0100 From: Lorenzo Pieralisi To: Sudeep Holla Cc: Ulf Hansson , Mark Rutland , "Rafael J. Wysocki" , Linux ARM , Linux Kernel Mailing List , Aaro Koskinen , Aaro Koskinen , Florian Fainelli , Michal Simek Subject: Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2 Message-ID: <20190412141937.GA8600@red-moon> References: <20190412100227.15024-1-sudeep.holla@arm.com> <2000694.m04KBuNrDd@kreacher> <20190412101522.GB12424@e107155-lin> <20190412134200.GA23351@e107155-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190412134200.GA23351@e107155-lin> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > > > > Acked-by: Mark Rutland > > > > > Signed-off-by: Sudeep Holla > > > > > --- > > > > > 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. Thanks, Lorenzo