Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp908912imm; Wed, 8 Aug 2018 07:44:26 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxnfvF+od7JaWDJGlEXMNaKz36pgqp+RdoQ2b3wbrJ7gp8Rt8l+iCFES0QuFNrl9HW06DYH X-Received: by 2002:a63:f244:: with SMTP id d4-v6mr2844908pgk.2.1533739466761; Wed, 08 Aug 2018 07:44:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533739466; cv=none; d=google.com; s=arc-20160816; b=zof0B5GD4vsza39bsyJ0O+JxKLQNj9AjY9L+Zk9019uadXJo2rPKYFGGPNWAF33P1b BFcN2XaL0PRwAGLy/GuEyDr7oTsyEkgt/QJAJRaRgM1IKmphmkcZ2hQh15nI2WmWIqex EbmeySDQtnMCiYLhwcU9JaX+gEuVlslisVQ07boraLHQRMvBNtebttvTIzF3T7z8EM8O KDYEax7JROiLYQpW7HIvD+iKwWTFn2ffmjQMlrh3Fuuaza2Pr516PAsBz9/6y4NzV3Bn zqpMQiDLKG7H32hSfoDsKkFrsGhh7lcU7swZtxQpqr2XUii4FofWQuAjhK0Kgeau8Pvz GN2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=6lwIzBAEoNGC063wphBd0PuW2gzgh6zhLOAGSjcSb6Q=; b=o8afDfWvlDUffVckE/3EJ8gswjyXhjNln9srcWvpAmnpK1AC04OFA6AriI3J7Xn8Yj 42tyMLAYo1zqLtZqHpVjZUo4lCCBWe3RZg5gOhuf+YIVQAaJWTFjljRWNajA4UDmFRXn bwuyaZ0ELKdUFnRTt1jKNdO/GAn5TQWz27LSOBWlDuA0YkceUn1FlPRS+A7yy8eZKYRk qojzTcJMb+GrMyVgBS22CvJiUjHswwqe3+LvBooguif4ppz1Qig6oXBBTwOgtGUeoFbl 0jmN7fEJ5WX8AigEE8XJoCO+NP3IIyoQMm8vfNea5RsX/UBlOuOps4AvZ4i6F2Y758MG SCwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Knc+7JY+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z137-v6si3697732pgz.144.2018.08.08.07.44.12; Wed, 08 Aug 2018 07:44:26 -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; dkim=pass header.i=@kernel.org header.s=default header.b=Knc+7JY+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727500AbeHHRDN (ORCPT + 99 others); Wed, 8 Aug 2018 13:03:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:42332 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727198AbeHHRDM (ORCPT ); Wed, 8 Aug 2018 13:03:12 -0400 Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A609219F5; Wed, 8 Aug 2018 14:43:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1533739394; bh=WyTPmcLf26uVa54updGaaJ/g97kqbywaz6/9IZnrHDU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Knc+7JY+lwU/eKFLkGM/BqweuGo6Nl61zRQEtfnOQLvrmSLhlVkZYAbSMAZKvmto/ nhJElWu7YiuXWDS1dwwae7c/TevYsnElqt8rz2PD/Bi/SWHNemDjISLcLDVJ7U34T2 YSZPWJ5RHwfJ45lCE9hv/ksyp7MWBoi9UBMeC/cY= Received: by mail-qk0-f182.google.com with SMTP id c126-v6so1662130qkd.7; Wed, 08 Aug 2018 07:43:14 -0700 (PDT) X-Gm-Message-State: AOUpUlH/yC+/td8qgrctkSjTkzeH1uq4zIM/BsiHDmsT8MzA0Tej+C9F ROIujxTLcef0S9OKBAsNcxe/KbegToV3EcdORA== X-Received: by 2002:a37:a0c8:: with SMTP id j191-v6mr2621286qke.375.1533739393265; Wed, 08 Aug 2018 07:43:13 -0700 (PDT) MIME-Version: 1.0 References: <20180802115008.4031-1-hch@lst.de> <20180802115008.4031-3-hch@lst.de> In-Reply-To: <20180802115008.4031-3-hch@lst.de> From: Rob Herring Date: Wed, 8 Aug 2018 08:43:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 02/11] dt-bindings: Add an enable method to RISC-V To: Christoph Hellwig Cc: Thomas Gleixner , Palmer Dabbelt , Jason Cooper , Marc Zyngier , Mark Rutland , Anup Patel , atish.patra@wdc.com, devicetree@vger.kernel.org, Albert Ou , "linux-kernel@vger.kernel.org" , linux-riscv@lists.infradead.org, Stafford Horne Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 2, 2018 at 5:50 AM Christoph Hellwig wrote: > > From: Palmer Dabbelt > > RISC-V doesn't currently specify a mechanism for enabling or disabling > CPUs. Instead, we assume that all CPUs are enabled on boot, and if > someone wants to save power we instead put a CPU to sleep via a WFI > loop. Future systems may have an explicit mechanism for putting a CPU > to sleep, so we're standardizing the device tree entry for when that > happens. > > We're not defining a spin-table based interface to the firmware, as the > plan is to handle this entirely within the kernel instead. > > Signed-off-by: Palmer Dabbelt > Signed-off-by: Christoph Hellwig > --- > Documentation/devicetree/bindings/riscv/cpus.txt | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt > index b0b038d6c406..6aa9cd075a5b 100644 > --- a/Documentation/devicetree/bindings/riscv/cpus.txt > +++ b/Documentation/devicetree/bindings/riscv/cpus.txt > @@ -82,6 +82,15 @@ described below. > Value type: > Definition: Contains the RISC-V ISA string of this hart. These > ISA strings are defined by the RISC-V ISA manual. > + - cpu-enable-method: Something wrong with "enable-method" as defined in the DT spec[1]? > + Usage: optional > + Value type: > + Definition: When absent, default is either "always-disabled" > + "always-enabled", depending on the current state > + of the CPU. > + Must be one of: > + * "always-disabled": This CPU cannot be enabled. > + * "always-enabled": This CPU cannot be disabled. To follow the spec, 'enable-method' should simply not be present in the always-enabled case. I think the always disabled case should be handled with: status = "disabled"; enable-method = "none"; With "none" needing to be added to the spec. [1] https://github.com/devicetree-org/devicetree-specification/blob/master/source/devicenodes.rst#general-properties-of-cpuscpu-nodes