From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95208ECAAD3 for ; Wed, 31 Aug 2022 19:00:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233160AbiHaTAi (ORCPT ); Wed, 31 Aug 2022 15:00:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232176AbiHaTAa (ORCPT ); Wed, 31 Aug 2022 15:00:30 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BA8265A8 for ; Wed, 31 Aug 2022 12:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661972423; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rUjqtYUIKxPVVYBFMkLE+l8nb11gl1oPqWCY/ZAXF6g=; b=ETCA53LRr45mqMghPdoH/+y92nsQeqIoW2BapBlWfqozAl5tGtCxY27CuoJpruoQI7xSy6 Z3EcTRPEjqtos/3+Wa1QI5lWzRirZgylqwlf3hos65RR6KFUAYfEAZR8Adc5IV8y2P9ZyR R99Tt/BwBElRamJga5nrXIEazpOglSw= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-526-Xfs89RtpN3ymPe0Mbu8jUw-1; Wed, 31 Aug 2022 15:00:22 -0400 X-MC-Unique: Xfs89RtpN3ymPe0Mbu8jUw-1 Received: by mail-qt1-f200.google.com with SMTP id h19-20020ac85493000000b00343408bd8e5so11835427qtq.4 for ; Wed, 31 Aug 2022 12:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=rUjqtYUIKxPVVYBFMkLE+l8nb11gl1oPqWCY/ZAXF6g=; b=LCTV2fnHkOd5UyrGWNK33CylHnFVXy6R7cO10as7BiSiMt01g9VYJ5DiaEh3DXJJe4 ZAAHmVD8LhMlE+GxI0I0SLH9+r8OL+wecnDLDq3QgqcSPu//L/D2jvUaZUXdnRwyzx0Y Ni4BEmfYYDpCQfVFtmdid+o20ZSqdas9LVpuElsiKBKprFa5mlQIwsOJS/hzhf1JNnZR oxTRtRMbSIc/owqr7V2j9pPM0ol9WBIt3Dm8osLVYqBfdsGy9ihLQyQc/DEo2suVjOPw w/SYfbx04ZOzvUtX1YrgwlMJHJmo9IFYS2uIWPF48jbhxfIQOHJhjI/hOsJJ4GP7zHtx F+MQ== X-Gm-Message-State: ACgBeo38ur9N1b8+6+3oIy3bKqqkO0ftTJVcKVtBk0OjFJMdQ9MUb3p/ /ksmyb3XefYNzGG1gnAgXXNc28PFG9+s7cvtWB8u6tE91sQzUUJETpgVw0VFYOVRr075LfdIgQh rhZDqzbXUBcSyPHhitXPK/A== X-Received: by 2002:a05:620a:4627:b0:6bb:b3af:f5f7 with SMTP id br39-20020a05620a462700b006bbb3aff5f7mr17071673qkb.71.1661972421172; Wed, 31 Aug 2022 12:00:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR7zQF5gysCuQ9o1Jwi4N5e6+DIpOgT7moa77V5ta8D39VzNAd+5uJptd77sjX36fmyC42DCpA== X-Received: by 2002:a05:620a:4627:b0:6bb:b3af:f5f7 with SMTP id br39-20020a05620a462700b006bbb3aff5f7mr17071648qkb.71.1661972420924; Wed, 31 Aug 2022 12:00:20 -0700 (PDT) Received: from halaneylaptop ([2600:1700:1ff0:d0e0::48]) by smtp.gmail.com with ESMTPSA id t8-20020ac865c8000000b0033c36ef019esm8474410qto.63.2022.08.31.12.00.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 12:00:20 -0700 (PDT) Date: Wed, 31 Aug 2022 14:00:18 -0500 From: Andrew Halaney To: Doug Anderson Cc: Johan Hovold , Bjorn Andersson , 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: <20220831190018.3dexkam3efdcfysf@halaneylaptop> References: <20220829164952.2672848-1-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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. I can take a stab at this during the week here I hope.. I owe Doug for the slew of patches and have wanted to peek at how all the dt-binding validation stuff works anyways. Thanks, Andrew > > In any case, I think these dts patches are ready to land now. > > > > Perhaps at least for RPMh as it seemed you found some cases were this > > wasn't currently needed (even if that sounded like an Linux-specific > > implementation detail). > > I think you're talking about the RPM vs. RPMH difference? It's > actually not Linux specific. In RPM the API to the "hardware" > (actually a remote processor) is to pass the load. In RPMH the API to > the hardware is to pass a mode. This is why RPMH has > "regulator-allowed-modes" and "regulator-initial-mode". Both RPM and > RPMH have "regulator-allow-set-load" though... > > -Doug >