From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 F32AD286280 for ; Wed, 19 Feb 2025 22:15:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740003350; cv=none; b=i+H5LrmmuIaqH0b0kWAZq8GWJOvLWwkKqnMHO+9GgSHGz6kXzEX1ar6BY1BvSV34Tg/rhyBx1IVcvcK7n5Xa0KOHzooMiERNLDfkcWV296lu4qqtPLGbyIQGBNvZSW4O/5ZzV09jd2bmdo51ySoTi4lIdncZnYfF6voulAso+1Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740003350; c=relaxed/simple; bh=b2YgUcsEtKdZm3lpZ/T7h7Y1gRYtdDGz1wKwQ/chLN0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZoqMA9kmGXh8Wc+SohDyiuIZeI0X0rH3ZvQ0/eE5Jqe+S+PP3d5l7zSRik2Ei/V6idSLvAGf/wZWNPINHrJKHPFTeBYurf8Y/EplLtr4yB+uk1GLFyRuxyoxF1SiGR5dnUMFtugQOs9HcGyB9AdwLOJON63xfxygXRundV1lpF0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=ibH44aeC; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ibH44aeC" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-220c8f38febso4158445ad.2 for ; Wed, 19 Feb 2025 14:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740003348; x=1740608148; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dUTzFxcEo0vBZIZ3J735rVLtOIUOXWthhsxU1QIsawI=; b=ibH44aeCknuU9ymuSUl/6HBuL4wrNZeBDO/c81g7e1YDVXMeWXjZxHsREgCEH7TZo/ j06xMmwUsHmIG1x42nQiAkzMidKWJplaEnpc20TRWLePOOj2DAHB/2gA48R79qQgnqq2 fqjCfObDVcC82G1ZHDzP30/kAlP7CVL+jI0h4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740003348; x=1740608148; h=in-reply-to: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=dUTzFxcEo0vBZIZ3J735rVLtOIUOXWthhsxU1QIsawI=; b=MOcaaZCqYjpiLRlGBBZSTWrm4yzuvNH8LC8HQegLxDy9kcZByuCgXwLsVA5iF4dHtd 7m3NuGe4f9Q+/r+oYTlUP6UlmP2pmAJDwy6CyJAa4/SGPm8gXUUQ09YtITUCxTMSZGXc +d/i9FNHwoP+bopgcop0uqKWG50lkhBiQgCobHTKiL60c47l1br13/5uPzkbsdRrS6Ha b4x+dQyZcVSiRTCLStyRObRxMYeNDfzhksbUu3IIJGEmIwZybH1om2/x4jdMQ5gEOh8W EG9+MGoF68wkg+v67zteUx7zQP9etq36ZjsL+dWhjKshBO+MihyYALtya2uhdCfYVaLJ 2L7Q== X-Forwarded-Encrypted: i=1; AJvYcCUbv9TRXfwJG3+gq7LmWvnZ13KmsV3sM4qxl1qTK4v7Ov8Bbzy3z4kLJPWrG8pNAg/rtTCJhJ95/P8blfg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0KqUnU94qex95PtwrRQ180g7rJS7LQc701wOCT+rvDP7hTAzH ylN1+yl8ko4cdJ052+htf6Pozf+TZ7PIEmClVHG1nuPnb0X4pOx7nKHCoox6AA== X-Gm-Gg: ASbGncsMKhZD34tjVsHNFettZjU5adoXcp+1myucPdHByrFwGs2iI9eYE+jySVQwAVh s1QxMNjIx2ff9iEl0eQudM5K+8rnnEjQv86FlVHyOLekI3Q7MXndtQ1FXytLAV91UxPZuevDqNC badRAT0Bi4IN47eAj25MJv0hFGO3QPz+mC7c21vegv2a58u2bjViFuAe75aZkkycZCHlyM0vo3T IoR6nkkatqUTLUEWD5G0iksw+oFYqQJZmTyDB7Wb3EeNylLnBuoOCat0FPSV547tWNL3fhY6enG xYaGxJ+pvwF4mcFDcCGqDXOReeBHp/rNixGHiwlIe9TWoGcJB3ONmg== X-Google-Smtp-Source: AGHT+IHBOzzGaQZv6nzU5gasb+yLRcfRb1LfyeNWbuAMCeAMjpDumyCKot5B+fc1Bjp5QjOJiS3Zbg== X-Received: by 2002:a17:902:f54e:b0:212:996:3536 with SMTP id d9443c01a7336-22103efa4f4mr361188295ad.10.1740003348213; Wed, 19 Feb 2025 14:15:48 -0800 (PST) Received: from localhost ([2a00:79e0:2e14:7:151d:7120:73cf:b371]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-220d545c9bbsm107887405ad.127.2025.02.19.14.15.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 14:15:47 -0800 (PST) Date: Wed, 19 Feb 2025 14:15:46 -0800 From: Brian Norris To: "Rafael J. Wysocki" Cc: Ajay Agarwal , Oliver Neukum , "Rafael J. Wysocki" , Vincent Whitchurch , "jic23@kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-iio@vger.kernel.org" Subject: Re: PM runtime_error handling missing in many drivers? Message-ID: References: <5caa944f-c841-6f74-8e43-a278b2b93b06@suse.com> <20220708110325.GA5307@axis.com> <4ca77763-53d0-965a-889e-be2eafadfd2f@intel.com> <1937b65c-36c0-5475-c745-d7285d1a6e25@suse.com> <5c37ee19-fe2c-fb22-63a2-638e3dab8f7a@suse.com> 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=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Feb 12, 2025 at 08:29:34PM +0100, Rafael J. Wysocki wrote: > The reason why runtime_error is there is to prevent runtime PM > callbacks from being run until something is done about the error, > under the assumption that running them in that case may make the > problem worse. What makes you think it will make the problem worse? That seems like a rather large assumption to me. What kind of things do you think go wrong, that it requires the framework to stop any future attempts? Just spam (e.g., logging noise, if -EIO is persistent)? Or something worse? And OTOH, there are clearly cases where retrying would be not only acceptable, but expected -- so giving special case to -EAGAIN and -EBUSY, per another branch of this thread, seems wise. I'd also note that AFAICT, there is no similar feature in system PM. If suspend() fails, we unwind and report the error ... but still allow future system suspend requests. resume() is even "worse" -- errors are essentially logged and ignored. > I'm not sure if I see a substantial difference between suspend and > resume in that respect: If any of them fails, the state of the device > is kind of unstable. In particular, if resume fails and the device > doesn't actually resume, something needs to be done about it or it > just becomes unusable. To me, it's about the state of the device. If suspend failed, the device may still be active and functional -- but not power-efficient. If resume failed, the device may be suspended and non-functional. But anyway, I don't think I require asymmetry; I'm just more interested in unnecessary non-functionality. (Power inefficiency is less important, as in the worst case, we can at least save our data, reboot, and try again.) Brian