From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5B6F14A82 for ; Wed, 8 Jan 2025 16:02:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736352142; cv=none; b=jrNdtzgtnOsQyBwu/cag//nGl8e90iw7/t3iK+2/kZInHUGFwxYWVasJJ/kfovDliFY92qWEVdE1dGlQe7xIoic2kFZI9yAAjtGgIJjAGrlhs7DcsXZAekCti9KPB4zhJyXillCxpzHJhWRZShk9T0gZvk6Icn+gC2E1ZBQGEYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736352142; c=relaxed/simple; bh=q2pod2nUbwMJD0bdVvi2G9EzGICOQ3Pcv9WM6ocnZY8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YgiIlwJr6bppqp1puF3BEiUrzbixwuri4A2lSPfvy3QoGJi1PQ/5oJI9WSuCh65Gz0aQ2NxpNfgrddRiEBcJuQ30pm3tWO7UBJ+mWkCds4GV6WPu+rp/1sld87SMPMLWjajMpREl7K+cRhLOTu5B/1hkCjk/Gli+FspMJvaD/eM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=I++6xX9b; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="I++6xX9b" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-21636268e43so79556345ad.2 for ; Wed, 08 Jan 2025 08:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736352140; x=1736956940; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=gDnmmr+BPzeGSONCgPZRDtmO65LxOmvvSiVUiu5r1WI=; b=I++6xX9b8Y6I8yvtjQp3yw5PiNR/inwXfxk/igpwBv0lZpW3sgfdr5NDe5ZFwMMlA9 CDxsIKTVla18Xsfb5Q2Cq6Axo8ixdNeYtQparZ5W09B48NsRXjvNfkadu8iIeO23O9FD A4oy9fsOF3KPSuU/C03WGqMOtBAKDosx2G0E6LE5MrUWxgV3iEcU8gOFcyQ6Q7XgJInm 73Gbd+JIyQCWPGqstZ58nv8dh7MHrGidBZd0Cig5xlnPvQ9RSOBOuU5BRQFgy1Yo3Up5 IXiqJvSce7sV967fdT0cBHOiyb86EOq5zmuZyOmvSYOA16dpBfycCyiqe/b3RkvCHtbn roFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736352140; x=1736956940; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gDnmmr+BPzeGSONCgPZRDtmO65LxOmvvSiVUiu5r1WI=; b=bVEIqLPYl3nmKBHFgS8iaCdjcbRuYpW4ao8ZF7aaBC3TUPdvjM82giE6vQaIeCjgt1 XaUPWJeVRDojQ5kcOBvl+/gJIEFw3Ffk7KpSF6sIJZtvlF8oEYs+wJmZ5xVLvImBVJX2 irfuGyMbeNe8bNqeWaFDY1ZwIFWeYkW9xDdW5FiJIhCBQWkSSPNt4gXZHnt3vfzeIKz4 QAJwSYYiqV830cMGWdGtWQISQwy2jV1kshcechCvOUABobBjtYOoCto+nUMIuBrJIRbR G5LbPgknutUg2m6kYOu1fZw9IOa5Gu+qZueJM7x7NHGFUeiVirsbjx2mM/8YTspBb++O Mp7g== X-Forwarded-Encrypted: i=1; AJvYcCWvg/EdkzXyFCDfKujnbLLTk0WrAof2akI4jTC7Sz+upm7k7RcX8OWAc5uTCLVcDlHB5it2690KWi9pYTM=@vger.kernel.org X-Gm-Message-State: AOJu0Yxii97Q0JzWWxfPrAN2JzXcvbYBNTdqamqNuRucwSBomcVINUi7 pHr3H4QFs0iCtPCDE40JFWeqStPXeoVEkq4/VBzGmw+R7Z+C8iKNn2wX4Md00w== X-Gm-Gg: ASbGncsx7x/8eMqgnYGbbF3ybV/qrbBg0ZjtMdcKika1hKLYWFfny9UdW8mU11IEYQ1 rUc0LAV63APhyvyeIs4IS4AFg8UQtK9HGSPlMFdaQS4MtXvMI1m5IyzKk5vtkiawlTmLPUI/k1A aGQMyhaHuGAeJpqGSQQSGXbbeNud8NTYJstQK0l5Zm/7wsjUqdPdbTfrr2eP+v6onJMYvBViY/e vhj6n0Re4mo1plEwrK1/3+iC3tzoVQ24FAaDIPKuAxpaen3Dq1oUXrQS8Ak+j9JxTQJ X-Google-Smtp-Source: AGHT+IGnIOJxVu4wkWjov5XG3BAJjb4T++JDP8RJTAnpDKLkqISVD6wPeoA7et1loROcLPRxCQ2RcA== X-Received: by 2002:a17:902:c941:b0:215:7fad:49ab with SMTP id d9443c01a7336-21a83f46a12mr51005925ad.10.1736352138709; Wed, 08 Jan 2025 08:02:18 -0800 (PST) Received: from thinkpad ([117.213.97.234]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-219dc970cbbsm329441405ad.103.2025.01.08.08.02.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 08:02:18 -0800 (PST) Date: Wed, 8 Jan 2025 21:32:11 +0530 From: Manivannan Sadhasivam To: Loic Poulain Cc: mhi@lists.linux.dev, Johan Hovold , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2] bus: mhi: host: pci_generic: Recover the device synchronously from mhi_pci_runtime_resume() Message-ID: <20250108160211.6dok3zcn2qaoj3lp@thinkpad> References: <20250108-mhi_recovery_fix-v1-0-a0a00a17da46@linaro.org> <20250108-mhi_recovery_fix-v1-2-a0a00a17da46@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 08, 2025 at 04:19:06PM +0100, Loic Poulain wrote: > On Wed, 8 Jan 2025 at 14:39, Manivannan Sadhasivam via B4 Relay > wrote: > > > > From: Manivannan Sadhasivam > > > > Currently, in mhi_pci_runtime_resume(), if the resume fails, recovery_work > > is started asynchronously and success is returned. But this doesn't align > > with what PM core expects as documented in > > Documentation/power/runtime_pm.rst: > > > > "Once the subsystem-level resume callback (or the driver resume callback, > > if invoked directly) has completed successfully, the PM core regards the > > device as fully operational, which means that the device _must_ be able to > > complete I/O operations as needed. The runtime PM status of the device is > > then 'active'." > > > > So the PM core ends up marking the runtime PM status of the device as > > 'active', even though the device is not able to handle the I/O operations. > > This same condition more or less applies to system resume as well. > > > > So to avoid this ambiguity, try to recover the device synchronously from > > mhi_pci_runtime_resume() and return the actual error code in the case of > > recovery failure. > > > > For doing so, move the recovery code to __mhi_pci_recovery_work() helper > > and call that from both mhi_pci_recovery_work() and > > mhi_pci_runtime_resume(). Former still ignores the return value, while the > > latter passes it to PM core. > > > > Cc: stable@vger.kernel.org # 5.13 > > Reported-by: Johan Hovold > > Closes: https://lore.kernel.org/mhi/Z2PbEPYpqFfrLSJi@hovoldconsulting.com > > Fixes: d3800c1dce24 ("bus: mhi: pci_generic: Add support for runtime PM") > > Signed-off-by: Manivannan Sadhasivam > > Note that it will noticeably impact the user experience on system-wide > resume (mhi_pci_resume), because MHI devices usually take a while (a > few seconds) to cold boot and reach a ready state (or time out in the > worst case). So we may have people complaining about delayed resume > regression on their laptop even if they are not using the MHI > device/modem function. Are we ok with that? > Are you saying that the modem will enter D3Cold all the time during system suspend? I think you are referring to x86 host machines here. If that is the case, we should not be using mhi_pci_runtime_*() calls in mhi_pci_suspend/resume(). Rather the MHI stack should be powered down during suspend and powered ON during resume. - Mani -- மணிவண்ணன் சதாசிவம்