Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1574167rwe; Thu, 1 Sep 2022 23:15:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR5p7oDYHI4ICJkCWSiEwg0W4Qt0ZXzebtae35ef6728LZ95eGlcpgvSX0RGPJYNCdY8GsVO X-Received: by 2002:a63:5a1a:0:b0:42b:52f0:4134 with SMTP id o26-20020a635a1a000000b0042b52f04134mr28588831pgb.164.1662099339981; Thu, 01 Sep 2022 23:15:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662099339; cv=none; d=google.com; s=arc-20160816; b=W3VUUtG/SCos81W+wC/aWcHB9CTBWpj61m6QmJ3kxABn8MdJmW48bd1IuNkqLhDc/f 2j2+u4FQooJz+zANmmHCQpy0HNeY42d9LLnW263AW6VeU2T+sK7MLCqKapC2AaDFgYUW jyKSM2/GWiUxGBHsz/UOia5Ms24PmAr/rtY3wS5ggoUhld9a9w6H5un9mJGdUdgzC9lx WQ5R4+EMXsLMkhyNPKLcAjpAoDAzm0FM6WQRpYmmfcC3vyaXGLbOU1V4TUWaFrXNH2Fh hSVatifSTywlVU8zeY+zQFeITR2pL+kLtDQTp70svE50AY0fHSy3zDwJoW310jhuXVYg XLiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ohHqbXpFroSUPqobHh3O8VPSF/dD9j3wewdbxtQ59nE=; b=MHfLKgw2Bnf0HQ/7fLO26CVYlv/ws4hBUp2UYbqIdi8yDc2ZG+tebV1fQu8/3Rmtrj ARdhVeZtgjL0hENlPCgYrghTfz0r54xUsNsfhb34Z6970Bjn56I21Z7rDp5qsD2Qn7N/ yQW4ovFC3i5XOcpKneqHDzIIEOQyY+zIhpfRW4OV2/A82ec08PZ3AyIZSwA3rPEjkuvj vCRUP6CkD3Mbh5+70DMB2HuCFx71hXy43YXLCXcpR4dioWr1q9dehBDpmp9CLRIoFOot 5XCaMQmEezqfl4BUSyzkmUxokcKjrvwnD9Gawg9Ky6QB4c8VO1JmwJxFL7VD8w9faP8I aM7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sJet8hBn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p12-20020a170902eacc00b001729bd62293si1138372pld.450.2022.09.01.23.15.29; Thu, 01 Sep 2022 23:15:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sJet8hBn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S235111AbiIBFke (ORCPT + 99 others); Fri, 2 Sep 2022 01:40:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235060AbiIBFkc (ORCPT ); Fri, 2 Sep 2022 01:40:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0D172E6BB; Thu, 1 Sep 2022 22:40:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AC045B829E0; Fri, 2 Sep 2022 05:40:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 528C7C433C1; Fri, 2 Sep 2022 05:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662097228; bh=5515oJEpY7e2I8udEF7OHHU204KydB1v52PApM443tg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sJet8hBnFqqyrC9W0n0b3eThX9T6n4CsDdtz5NdFRHR0HOlUtqamI3yVFGjyN+MWf C7hNT1BRP8mgqAe8rE7pVkFxtOAiBv95sRqdzCrXptrE3Es90TAToceIc+OKteMW6L gRedBukWWda2YsAjalC9hceCIqp2vJlTsKZrT4knd+1aqyr5teHlUVD18uzNVyVpAQ gpX7ABDmgWzEtwApq2mxjuYqTuJC2pHLOCSHZU09d2LqGEa0vfkfeTp051Syn/FH1y lgbS447yof5RAiFPFbnC7sFkCUotyevshni8FAfmez3pvcwPnw60V1y4gMfGgk7sSL uu6ZTRw6QurRw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oTzPq-0007lS-PV; Fri, 02 Sep 2022 07:40:30 +0200 Date: Fri, 2 Sep 2022 07:40:30 +0200 From: Johan Hovold To: Doug Anderson Cc: Bjorn Andersson , Andrew Halaney , Mark Brown , Andy Gross , AngeloGioacchino Del Regno , Bhupesh Sharma , Johan Hovold , Konrad Dybcio , Krzysztof Kozlowski , Rob Herring , Vinod Koul , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-arm-msm , LKML Subject: Re: [PATCH v2 0/6] arm64: dts: qcom: Fix broken regulator spec on RPMH boards Message-ID: References: <20220829164952.2672848-1-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 01, 2022 at 05:44:03PM -0700, Doug Anderson wrote: > Hi, > > On Thu, Sep 1, 2022 at 8:52 AM Johan Hovold wrote: > > > > On Wed, Aug 31, 2022 at 07:52:52AM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Tue, Aug 30, 2022 at 11:47 PM Johan Hovold wrote: > > > > > > > > On Mon, Aug 29, 2022 at 09:49:46AM -0700, Douglas Anderson wrote: > > > > > Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement > > > > > get_optimum_mode(), not set_load()") several boards were able to > > > > > change their regulator mode even though they had nothing listed in > > > > > "regulator-allowed-modes". After that commit (and fixes [1]) we'll be > > > > > stuck at the initial mode. Discussion of this (again, see [1]) has > > > > > resulted in the decision that the old dts files were wrong and should > > > > > be fixed to fully restore old functionality. > > > > > > > > > > This series attempts to fix everyone. I've kept each board in a > > > > > separate patch to make stable / backports work easier. > > > > > > > > Should you also update the bindings so that this can be caught during > > > > devicetree validation? That is, to always require > > > > "regulator-allowed-modes" when "regulator-allow-set-load" is specified. > > > > > > Yeah, it's probably a good idea. I'm happy to review a patch that does > > > that. I'm already quite a few patches deep of submitting random > > > cleanups because someone mentioned it in a code review. ;-) That's > > > actually how I got in this mess to begin with. The RPMH change was in > > > response to a request in a different code review. ...and that came > > > about in a code review that was posted in response to a comment about > > > how awkward setting regulator loads was... Need to get back to my day > > > job. > > > > Heh. > > > > > In any case, I think these dts patches are ready to land now. > > > > Yeah, as the old dtbs are now broken with newer kernels these are indeed > > needed. > > With the latest patches in the regulator tree things shouldn't be > _too_ broken even without the dts files. Essentially things will get > stuck at their initial mode (HPM). So without these patches things > should all still boot but could possibly end up at a higher power > state. Ok, and there's also a warning during boot when that happens so that it's not a silent regression? Johan