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 9311AEE4996 for ; Tue, 22 Aug 2023 15:25:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234934AbjHVPZg (ORCPT ); Tue, 22 Aug 2023 11:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234131AbjHVPZg (ORCPT ); Tue, 22 Aug 2023 11:25:36 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 318F2CD1 for ; Tue, 22 Aug 2023 08:25:34 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4fe21e7f3d1so7204744e87.3 for ; Tue, 22 Aug 2023 08:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692717932; x=1693322732; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Y5CLA2KNaAWPxWmHn3gOeMHV9Mij34aiTzhvlGQZaYA=; b=gULeZIZxM1UDkuR2e7pdWHGfHRhZ7hVBNnziyChiJpXZtA8T3Lqt+zNhR6YmWG8Lwd QWBDk2Z+lS01O37XqNHRJSstML1IdWhRdagmgLmOh8F1UVKj2u6KdJIhaVgrLGJ62cu9 9l+hB8Q0CMROKXQboZwHmJvR4FbuIk4gKvAiSF9Ui4hRAQq1m9jLUcBe9fr+z+i775In +CKEeno8a3QEIhXyeR+jl+I9E/QS0akU0BwMO4UTivyi19E07TmPdEoreD0/IzdVaf2t atoCkHSiJtBC3X2vkbFGITe+xTv5Ohp06mrMnm6al1e0DQF5lRpG18xOjGuZOihQOZl/ RxRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692717932; x=1693322732; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y5CLA2KNaAWPxWmHn3gOeMHV9Mij34aiTzhvlGQZaYA=; b=MqWoA8+O7F9aPZMyF6N0o9B73ytELogjd2NmhnafSaVjSFxZQze1fdQgLf0g0dHT9f iDbt6/tcRxKLWYWmyijg9+6moqpfwb7GPmHmpIhrar9dRiqzNoDqUK+1eBbj+lK3nevv kMnEKZHGAb46Fios43Tb69V/RIE3AfQc0HDQhHhXFXcbpsFiujBwVzsWOjGl0oBTKdLa 13HgwypilfJWR+eoBJoXy6YlLy8g4moyeKZXomfENFae1+gH/8IWVfP8k0A4MZOVRcAZ rOAbqjqhexn6NcgL9J84/EGr3fghaRIQTYDdMMHi1X1uAV4M+kSWBKnelrHODP3NaOg4 ZFjg== X-Gm-Message-State: AOJu0YzPeX0p0znIChqapJG1lVtVq6YEgVBbUteqRB07MYe7xcAmEI6w mhBSKCEmmoDhfflTtSSkokXMWg== X-Google-Smtp-Source: AGHT+IEZBABvrUJyOnUqIjt8DQpu4/Ght7kXWGlnDfbg74DLs7ajvH75DORb8rvzSwmWJ5nrCs9TaA== X-Received: by 2002:a05:6512:39d1:b0:4f8:6625:f2ca with SMTP id k17-20020a05651239d100b004f86625f2camr7199083lfu.61.1692717932388; Tue, 22 Aug 2023 08:25:32 -0700 (PDT) Received: from [192.168.0.22] ([77.252.47.198]) by smtp.gmail.com with ESMTPSA id l2-20020aa7cac2000000b0052239012c65sm7794477edt.82.2023.08.22.08.25.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Aug 2023 08:25:31 -0700 (PDT) Message-ID: <51bc0ccf-425b-5f16-b8f2-94d7cc979fae@linaro.org> Date: Tue, 22 Aug 2023 17:25:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file To: Shenwei Wang , Rob Herring Cc: Krzysztof Kozlowski , Conor Dooley , Ulf Hansson , Liam Girdwood , Mark Brown , "imx@lists.linux.dev" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx References: <20230818153446.1076027-1-shenwei.wang@nxp.com> <9927403d-6dd9-3e5e-8f9d-f38e6640f95f@linaro.org> Content-Language: en-US From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 22/08/2023 17:18, Shenwei Wang wrote: > > >> -----Original Message----- >> From: Rob Herring >> Sent: Monday, August 21, 2023 1:50 PM >> To: Shenwei Wang >> Cc: Krzysztof Kozlowski ; Krzysztof Kozlowski >> ; Conor Dooley ; >> Ulf Hansson ; Liam Girdwood >> ; Mark Brown ; >>> Thank you for providing the link. After reviewing the entire thread, I >>> still don't understand how to proceed. What is the conclusion >>> regarding this commonly used use case but overlooked feature in the >> upstream kernel? >> >> Overlooked implies we missed and ignored it, but the same concept has been >> submitted twice and rejected twice. What use case cannot be supported? >> > > No offend. :) Sorry for my poor word. To provide more context, a common use case > example is using a GPIO pin as a power switch. The current implementation operates > as a fixed regulator, which makes it difficult to control the on/off timing without modifying > its driver. So it is a problem of a driver? > It also lacks power management support. Which is not related to bindings but implementation in given driver. > >> The detail that power-domains get handled automatically is an implementation >> detail in the kernel (currently). That could easily change and you'd be in the same >> position as with regulator supplies. > > The proposed regulator-pd driver follows the standard PD driver framework, so it for sure > relies on certain kernel implementation details. If those underlying implementation details > change in the future, this driver as well as other PD drivers built on the same framework > would need to be updated accordingly. We talk about bindings which you would not be allowed to change. Thus your case would stop working... > >> We could just as easily decide to make the driver core turn on all supplies in a >> node. That would give you the same "feature". Why would you design your DT >> around implementation decisions of the OS? >> > > This DT properties are proposed solely for this specific driver, not to hack the OS. This > is no different than other PD drivers like gpc/scu-pd/imx93-pd. I am not sure if you got Rob's point, I have feelings that not. Argument that some OS implements something some way, is not an argument for a new binding, barely hardware related. Best regards, Krzysztof