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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7CCAEC48260 for ; Fri, 16 Feb 2024 15:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GgPiAg6y/7nIZbKQxEbAWCog39MUqmgbF5wPzSVc/ck=; b=0cV+pIYF/501Cv WBQqdyBFa1lc6Y+m4r6iKQB2bl7EyjV3yosio21SrDoug52NFuBV5C7wXkQr7cS5JYfCbC8CsTkeJ LPGiSON+0IFRZ4EY7Y1yIdFw2LVnzObTFb9xWTQM6rMzahwFr78I1SGeE/1r8h4g86By0KXq5JpmB VRtaWQHEabIwXcc/pZVBRj12tCNG3YyPTwlfuuDHHYomKBdEaPSxup2DJawhyiHcMf2It3+6mHd3O Dw81Y/by2etnUCGoHD1PHIW3ZQVD7e0k+bIYf4/PxGUxz7NqH5Otx9+h3Vb7h43MWnG/2b/QjvTWO ypgX7H+fMec4A2Id5iEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1razoM-00000002hPI-1r2A; Fri, 16 Feb 2024 15:07:34 +0000 Received: from mgamail.intel.com ([198.175.65.18]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1razoJ-00000002hOq-3Xh9; Fri, 16 Feb 2024 15:07:32 +0000 X-IronPort-AV: E=McAfee;i="6600,9927,10985"; a="2338135" X-IronPort-AV: E=Sophos;i="6.06,164,1705392000"; d="scan'208";a="2338135" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2024 07:07:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10985"; a="912374280" X-IronPort-AV: E=Sophos;i="6.06,164,1705392000"; d="scan'208";a="912374280" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2024 07:07:24 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1razo9-000000054rn-1ock; Fri, 16 Feb 2024 17:07:21 +0200 Date: Fri, 16 Feb 2024 17:07:21 +0200 From: Andy Shevchenko To: Thomas Richard Cc: Linus Walleij , Bartosz Golaszewski , Tony Lindgren , Haojian Zhuang , Vignesh R , Aaro Koskinen , Janusz Krzysztofik , Andi Shyti , Peter Rosin , Vinod Koul , Kishon Vijay Abraham I , Philipp Zabel , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Bjorn Helgaas , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org, linux-phy@lists.infradead.org, linux-pci@vger.kernel.org, gregory.clement@bootlin.com, theo.lebrun@bootlin.com, thomas.petazzoni@bootlin.com, u-kumar1@ti.com Subject: Re: [PATCH v3 05/18] mux: add mux_chip_resume() function Message-ID: References: <20240102-j7200-pcie-s2r-v3-0-5c2e4a3fac1f@bootlin.com> <20240102-j7200-pcie-s2r-v3-5-5c2e4a3fac1f@bootlin.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240216_070731_940744_D6CA2663 X-CRM114-Status: GOOD ( 26.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 16, 2024 at 08:52:17AM +0100, Thomas Richard wrote: > On 2/15/24 16:29, Andy Shevchenko wrote: > > On Thu, Feb 15, 2024 at 04:17:50PM +0100, Thomas Richard wrote: ... > >> +int mux_chip_resume(struct mux_chip *mux_chip) > >> +{ > >> + int global_ret = 0; > >> + int ret, i; > >> + > >> + for (i = 0; i < mux_chip->controllers; ++i) { > >> + struct mux_control *mux = &mux_chip->mux[i]; > >> + > >> + if (mux->cached_state == MUX_CACHE_UNKNOWN) > >> + continue; > >> + > >> + ret = mux_control_set(mux, mux->cached_state); > >> + if (ret < 0) { > >> + dev_err(&mux_chip->dev, "unable to restore state\n"); > >> + if (!global_ret) > >> + global_ret = ret; > > > > Hmm... This will record the first error and continue. > > In the v2 we talked about this with Peter Rosin. > > In fact, in the v1 (mux_chip_resume() didn't exists yet, everything was > done in the mmio driver) I had the same behavior: try to restore all > muxes and in case of error restore the first one. > > I don't know what is the right solution. I just restored the behavior I > had in v1. Okay, I believe you know what you are doing, folks. But to me this approach sounds at bare minimum "unusual". Because the failures here are not fatal and recording the first one may or may not make sense and it's so fragile as it completely implementation-dependent. > >> + } > >> + } > >> + return global_ret; > > > > So here, we actually will get stale data in case there are > 1 failures. > > Yes, indeed. But we will have an error message for each failure. Which is also problematic. PM calls may easily spam the logs and outshadow really important messages (like oopses). -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel