Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755955AbcCCUY1 (ORCPT ); Thu, 3 Mar 2016 15:24:27 -0500 Received: from mail-pf0-f173.google.com ([209.85.192.173]:33733 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751994AbcCCUYZ (ORCPT ); Thu, 3 Mar 2016 15:24:25 -0500 From: Kevin Hilman To: Laurent Pinchart Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Ulf Hansson Subject: Re: [PATCH] PM / Domains: Propagate start and restore errors during runtime resume Organization: BayLibre References: <1456874438-26330-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> Date: Thu, 03 Mar 2016 12:24:23 -0800 In-Reply-To: <1456874438-26330-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> (Laurent Pinchart's message of "Wed, 2 Mar 2016 01:20:38 +0200") Message-ID: <7h60x3wbrc.fsf@baylibre.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1184 Lines: 27 Laurent Pinchart writes: > During runtime resume the return values of the start and restore steps > are ignored. As a result drivers are not notified of runtime resume > failures and can't propagate them up. Fix it by returning an error if > either the start or restore step fails, and clean up properly in the > error path. > > Signed-off-by: Laurent Pinchart > --- > drivers/base/power/domain.c | 20 ++++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > This fixes an issue I've noticed with my driver's .runtime_resume() handler > returning an error that was never propagated out of pm_runtime_get_sync(). Acked-by: Kevin Hilman > A second issue then appeared. The device .runtime_error field is set to the > error code returned by my .runtime_resume() handler, but it never reset. Any > subsequent try to resume the device fails with -EINVAL. I'm not sure what the > right way to solve that is, advices are welcome. Probably setting it (back) to zero after each successful runtime_suspend or runtime_resume is the right way. Rafael? Kevin