Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4985731yba; Mon, 13 May 2019 03:24:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqy2gLKfXHvcfnTKr5qxbQGqNe/MpnfAnSPspuE9oin9cWS8XN8xI+VV3JaEYiAh2G8Id2Jd X-Received: by 2002:a63:f754:: with SMTP id f20mr29932531pgk.162.1557743093172; Mon, 13 May 2019 03:24:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557743093; cv=none; d=google.com; s=arc-20160816; b=AL7L4Po5QIBRN5giIQ+6MSj+rmnZMC83TF2rKP6OhxUtlL83dPMhqjI0hfBrbCPRD5 jOuv4bQoS2QAH2K+GQTv+aYd4pc/ZJMidfqvfFFtcy3ZAtKULvDHhtXqmflZ5bj6x7vf pgiWYIn3EI7qhBecFYDTUDh+d92RWkm9RaeS55y5WUQdPAfjmBFR1KFcI17q+WZX9T9T I6L/i8E/+/FHniUsY5MoiAKbI3kI3L2uE+zXD8lq/ozQGPLD7lHXsyJS3Z9Rp3FT9FLS SHt9nU2FDJPJZgIEjA6kyo6w0ixliVoNvSrrfNYIOl9MV6S5kHb95vTuuSmZex6Sbfm1 Fq8g== 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=kAcScdnptWilWbrCxWG79BiwT6BVJAZwRmSrnyS/Tes=; b=AOxZt41IW5fIVFsP9VXP4P169+ZNv8ZfFhdN48n6x+AqXl+7SnreaYJVPrZhED5DNI cDyVsFLQ+MQmmJNxC4bA4PyXoOZ7u5yCZ9Fifpwv+eRuMj2s839EJBdm2+sPHicPF6Td ZgCcksdzFHWKlkOqioJW1O3Aem4W11X5DDS9D+Kma3iZsG9ADxigq5/CfEYRCPNHhdHH C61msthXiCZKCjIbofiCVo0mTj3aODBVNdCLYvLjvqELbBqgBGa43LQprvJtFEX2M0rx +jiUVEUw/mk9LzCvHS73x1J7ZGGJN3W0L8nBIl+maMpvtAvM0Hrg+X6v18zCGx2rLKsx NZAQ== 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 68si15697926pga.147.2019.05.13.03.24.37; Mon, 13 May 2019 03:24:53 -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 S1728142AbfEMJtu (ORCPT + 99 others); Mon, 13 May 2019 05:49:50 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50538 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728042AbfEMJtt (ORCPT ); Mon, 13 May 2019 05:49:49 -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 9782C341; Mon, 13 May 2019 02:49:48 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 18AEE3F703; Mon, 13 May 2019 02:49:45 -0700 (PDT) Date: Mon, 13 May 2019 10:49:35 +0100 From: Sudeep Holla To: Amit Kucheria Cc: Niklas Cassel , Lorenzo Pieralisi , Andy Gross , David Brown , Rob Herring , Mark Rutland , Jorge Ramirez-Ortiz , Lina Iyer , Ulf Hansson , Bjorn Andersson , linux-arm-msm , DTML , Sudeep Holla , Linux Kernel Mailing List Subject: Re: [PATCH] arm64: dts: qcom: qcs404: Add PSCI cpuidle support Message-ID: <20190513094935.GA4885@e107155-lin> References: <20190508145600.GA26843@centauri> <20190510091158.GA10284@e107155-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 10, 2019 at 11:58:40PM +0530, Amit Kucheria wrote: > On Fri, May 10, 2019 at 2:54 PM Sudeep Holla wrote: > > [...] > > > > Yes entry-method="psci" is required as per DT binding but not checked > > in code on arm64. We have CPU ops with idle enabled only for "psci", so > > there's not need to check. > > I don't see it being checked on arm32 either. > arm_cpuidle_get_ops in arch/arm/kernel/cpuidle.c checks the method, has to match "psci" for drivers/firmware/psci.c to work on arm32 [...] > > > > Why do you want to deprecated just because Linux kernel doesn't want to > > use it. That's not a valid reason IMO. > > Fair enough. Just want to make sure that it isn't some vestigial > property that was never used. Do you know if another OS is actually > using it? > Not that I am aware of. But Linux uses it on arm32, so it's not entirely unused. > > > Do we expect to support PSCI platforms that might have a different > > > entry-method for idle states? > > > > Not on ARM64, but same DT bindings can be used for idle-states on > > say RISC-V and have some value other than "psci". > > Both enable-method and entry-method properties are currently only used > (and documented) for ARM platforms. Hence this discussion about > deprecation of one of them. > Yes, it's used on arm32 as mentioned above. > > > Should I whip up a patch removing entry-method? Since we don't check > > > for it today, it won't break the old DTs either. > > > > > > > Nope, I don't think so. But if it's causing issues, we can look into it. > > I don't want to restrict the use of the bindings for ARM/ARM64 or psci only. > > Only a couple of minor issues: > 1. There is a trickle of DTs that need fixing up every now and then > because they don't use entry-method in their idle-states node. Schema > validation ought to fix that. I understand, scheme should fix it. This is not just restricted to this, it's generic DT problem. So let's hope we get schema based validation soon. > 2. A property that isn't ready by any code is a bit confusing. Perhaps > we can mention something to the effect in the documentation? > Not entirely true. We have quite a lot of bindings that are added just because downstream drivers use e.g. GPU and even standard ePAPR or DT specification has lots of bindings which OS like Linux may choose not to use at all. Same applies to ACPI, so I am not for removing bindings just because there are no users in Linux. -- Regards, Sudeep