Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3074351ybt; Mon, 29 Jun 2020 14:37:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4TBOP0OvNhLCjCApM4ltxAoTleROFc/UTHY5Ru3hi92P7rVTiUbOHaCKEPSqRnRfsogLB X-Received: by 2002:a17:906:71d4:: with SMTP id i20mr16495179ejk.533.1593466678265; Mon, 29 Jun 2020 14:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593466678; cv=none; d=google.com; s=arc-20160816; b=kaI6xu16OLc4PZB0cIkgz8nuaJW08o6ReUivKZn72Np2kk4RqDwGtFsctvpNbrvgvd bF7/uJ04cMUNE5xIqG/gef+hLy3w6JwYklA4bHGheuunKIZ/GtpoRqe2GcMgL66+WT2V d9SzRWT6YxW8HO6x1EK6yhhUjEzh2XLAs8w8Y0vjMyx1WRjwZnILe+HQHfUp6ogH3jVg ea62fbQEGocka7D88o7a1eXF/Rzvlk4UkIYT17mlkaOT6U1qNEwByHwqLNL9oCYQNpTQ LihUH1MuVLwbLw7ltjS1qADcLPOYWkrAVdJboqqZjUE8bDNqV9WrFCgZRacGNGwUGB6e m/+w== 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:dkim-signature; bh=uvPcUSvJhbdjPNCBsY3u5fpzzEChSotWu9T/obTRLOw=; b=0qCyLNV2s+BIYhfkKxUGl5wJy5wGErMwF6YpkXEUYFRtoRQo5//XGQ8AOLonnioiIY orIMNXCQ3dwo0x223H1uYs/AlpQgfHpnxSZEPr3gHq0Ah/QNQVJXBkBIW56GLmzi0wok CjG/baWggC0a1SsjQXL/3en5qbsO65UtDe2KWaDukZie14JvD1cvS9SSbR0QDR+HVCWl jzgT8W6zBDY+ca30PPwIWW0A8gesPNPbVdZe8o7LQbydB2GA8+L35IG1OSFXgGoR2yb9 gpNGq2s+if8kHd5nZJ5maFPYZ5cGzJ1h7tgxABWmpZKr/tGeqL5j0s/ezGPY7EdU+oNx OydQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aSSuD7UP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id n6si416115edy.324.2020.06.29.14.37.35; Mon, 29 Jun 2020 14:37:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aSSuD7UP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728950AbgF2Ve7 (ORCPT + 99 others); Mon, 29 Jun 2020 17:34:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:60654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728566AbgF2Skz (ORCPT ); Mon, 29 Jun 2020 14:40:55 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 51FD823D25; Mon, 29 Jun 2020 12:57:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593435478; bh=bcyRH8SrIJRpWOCioAE7dQk1Zwno7fu5lbGQHD57n+M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aSSuD7UPU9scWauVRzNqe8ZN1yN6QlsyN7rZk8VrNsWYDgD/+hATBOQzmvBCe2E+t D3Xh+qBwPFvd/SS8ZHrwu7i6dNvNqobYG+MXCWb6C9721v0VwWQxe/CzBuVBy5sWdE YIMT3SzvxnbDL+UZ6JEuxwTiUHnlnblRL/az3+KA= Date: Mon, 29 Jun 2020 13:57:56 +0100 From: Mark Brown To: Yoshihiro Shimoda Cc: "ulf.hansson@linaro.org" , Sudeep Holla , "lgirdwood@gmail.com" , "geert+renesas@glider.be" , "magnus.damm@gmail.com" , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH/RFC v4 2/4] regulator: fixed: add regulator_ops members for suspend/resume Message-ID: <20200629125756.GC5499@sirena.org.uk> References: <1593163942-5087-1-git-send-email-yoshihiro.shimoda.uh@renesas.com> <1593163942-5087-3-git-send-email-yoshihiro.shimoda.uh@renesas.com> <20200626143914.GE5289@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: X-Cookie: Real programs don't eat cache. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vOmOzSkFvhd7u8Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2020 at 02:42:26AM +0000, Yoshihiro Shimoda wrote: > > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM Copying in Sudeep for the feedback on firmware interfaces. > > According to the changelog this is all about reflecting changes in the > > system state done by firmware but there's no interaction with firmware > > here which means this will be at best fragile. If we need to reflect > > changes in firmware configuration I'd expect there to be some > > interaction with firmware about how it is configured, or at least that > > the configuration would come from the same source. > I should have described background of previous patch series though, > according to previous discussion [1] the firmware side (like PSCI) is > also fragile unfortunately... So, I thought using regulator-off-in-suspend > in a regulator was better. > On other hand, Ulf is talking about either adding a property (perhaps like > regulator-off-in-suspend) into a regulator or just adding a new property > into MMC [2]. What do you think about Ulf' comment? I'm thinking > adding a new property "full-pwr-cycle-in-suspend" is the best solution. > This is because using a regulator property and reflecting a state of regu= lator without > firmware is fragile, as you said. TBH I worry about a property drifting out of sync with the firmware on systems where the firmware can be updated. Personally my default assumption would always be that we're going to loose power for anything except the RAM and whatever is needed for wake sources during suspend so I find the discussion a bit surprising but in any case that seems like a better option than trying to shoehorn things in the way the series here did. Like I said in my earlier replies if this is done through the regulator API I'd expect it to be via the suspend interface. > [1] > https://lore.kernel.org/linux-renesas-soc/CAMuHMdXjU7N4oG89YsozGijMpjgKGN= 6ezw2qm6FeGX=3DJyRhsvg@mail.gmail.com/ >=20 > [2] > https://lore.kernel.org/linux-renesas-soc/CAPDyKFpiBU1D+a7zb+Ggm0_HZ+YR4= =3DLXJZ5MPytXtT=3DuBEdjPA@mail.gmail.com/ >=20 > Best regards, > Yoshihiro Shimoda >=20 --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl755VMACgkQJNaLcl1U h9BCWAf/alYjM1GUf8o0xC1cfZB+/ZQDJlP1ynAY3yBAz6znDVqyB0+0YHESvJeZ H9rCGXZ4YyH+CRLnd3TzJrAYfJ9wedaSQiabb5GE7hUKuC/SYPgLHX/3201Kgwl+ +MNM6w0kvzjyU/0OzvYI0SXBFu5g21LAZLR5FSaYcReUfqOJah+OtilSFdO+z86h YsX6CMecRYl+4gwHkKlr1mQ7ZvrdtFkYynwxr3CZaD/ZsxZQ5DFL/p4h46D/ewKJ qYoD8RX0S5QnWLxNBWmy10XtW67Rznftmh5lSBV9UkG2zxIIYL8878fmVecdLsiI ZeLVxrKgg+Jq0Jzcy+7yux7aucvd+A== =ENZF -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms--