From patchwork Mon Oct 5 14:07:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thierry Reding X-Patchwork-Id: 7327661 Return-Path: X-Original-To: patchwork-linux-fbdev@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 22E03BEEA4 for ; Mon, 5 Oct 2015 14:08:09 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0DC9620660 for ; Mon, 5 Oct 2015 14:08:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BDC4D2065D for ; Mon, 5 Oct 2015 14:08:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751655AbbJEOHu (ORCPT ); Mon, 5 Oct 2015 10:07:50 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:36782 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbbJEOHq (ORCPT ); Mon, 5 Oct 2015 10:07:46 -0400 Received: by wicgb1 with SMTP id gb1so121376376wic.1; Mon, 05 Oct 2015 07:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Vj5x9AKatC4+nU7Iw0A3XRqPSOkszmaxed6y24OGg00=; b=KM1CIgQZVbQuXJa2BntoX5p8xyi0mlN0P4jRjh4OHB0E9iZiNQ/cwBn7gjqmhEKEr0 GyeGHNe5/WDyvyZk7bu9PJ2tR2qvj4u5x9APo8lj40wJ4tcFP/ezP7QbS/Dl8SD1bVRR 5QsJp4Bo0vaz13ZgLFuOpCfREbBuHmqIFWaOm3Cr5EsLVhhJ5ip4w4YOOVeA50HN8Ddm 3H8mIYQkDNB0vnCQVjOjIDwyYouZt2EL+tszHfyQZWGWbp8DiW71zv23X98h9xZMbNih ey9tDtfnsApHO2EuFBmzyVO02FVdbkTp3BkcVGTU9SLmIZlNEIeDm1e9+3Up4nq+3eb/ Qojw== X-Received: by 10.194.60.115 with SMTP id g19mr29574105wjr.29.1444054063841; Mon, 05 Oct 2015 07:07:43 -0700 (PDT) Received: from localhost (port-54044.pppoe.wtnet.de. [46.59.211.200]) by smtp.gmail.com with ESMTPSA id lf10sm27099685wjb.23.2015.10.05.07.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 07:07:42 -0700 (PDT) Date: Mon, 5 Oct 2015 16:07:41 +0200 From: Thierry Reding To: Boris Brezillon Cc: Nicolas Ferre , Robert Jarzmik , linux-pwm@vger.kernel.org, Alexandre Belloni , Jingoo Han , Lee Jones , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM" Message-ID: <20151005140741.GA10625@ulmo> References: <1443295482-18687-1-git-send-email-robert.jarzmik@free.fr> <87bncjemdk.fsf@belgarion.home> <560CE816.1060307@atmel.com> <20151005093543.GB30219@ulmo> <20151005131912.4da38169@bbrezillon> <20151005125803.GA30025@ulmo> <20151005153024.3a245b0b@bbrezillon> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151005153024.3a245b0b@bbrezillon> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Oct 05, 2015 at 03:30:24PM +0200, Boris Brezillon wrote: > On Mon, 5 Oct 2015 14:58:03 +0200 > Thierry Reding wrote: > > > On Mon, Oct 05, 2015 at 01:19:12PM +0200, Boris Brezillon wrote: > > > Hi Thierry, > > > > > > On Mon, 5 Oct 2015 11:35:43 +0200 > > > Thierry Reding wrote: > > > > > > > On Thu, Oct 01, 2015 at 10:00:22AM +0200, Nicolas Ferre wrote: > > > > > Le 30/09/2015 21:29, Robert Jarzmik a écrit : > > > > > > Robert Jarzmik writes: > > > > > > > > > > > >> This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f. > > > > > >> This commit breaks legacy platforms, for which : > > > > > >> (a) no pwm table is added (legacy platforms) > > > > > >> (b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore > > > > > >> chosen == NULL, and therefore pwm_get() returns NULL, and pwm_get() > > > > > >> returns -EPROBE_DEFER > > > > > >> (c) as a consequence, this code is unreachable in pwm_bl.c : > > > > > >> if (IS_ERR(pb->pwm)) { > > > > > >> ret = PTR_ERR(pb->pwm); > > > > > >> dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret); > > > > > >> if (ret == -EPROBE_DEFER) > > > > > >> goto err_alloc; > > > > > >> > > > > > >> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n"); > > > > > >> pb->legacy = true; > > > > > >> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight"); > > > > > >> > > > > > >> As this code is unreachable, all legacy platforms relying on pwm_id are > > > > > >> broken, amongst which pxa have been tested as broken. > > > > > >> > > > > > >> Signed-off-by: Robert Jarzmik > > > > > > Thierry, would you have a look please ? > > > > > > As I said before, all legacy platform relying on pwm_id are broken. I'd like to > > > > > > be sure this lands in the next -rc series. > > > > > > > > > > Well, as I answered on the linux-pwm mailing-list (I was not in copy) here: > > > > > http://article.gmane.org/gmane.linux.pwm/2744 > > > > > I wonder if it's not easier to fix the platforms and add the pwm tables... > > > > > > > > > > Otherwise, Boris proposed this fix: > > > > > 8<----------------------------------------------------------- > > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > > > > index eff379b..00483d4 100644 > > > > > --- a/drivers/video/backlight/pwm_bl.c > > > > > +++ b/drivers/video/backlight/pwm_bl.c > > > > > @@ -273,15 +273,15 @@ static int pwm_backlight_probe(struct platform_device *pdev) > > > > > pb->pwm = devm_pwm_get(&pdev->dev, NULL); > > > > > if (IS_ERR(pb->pwm)) { > > > > > ret = PTR_ERR(pb->pwm); > > > > > - if (ret == -EPROBE_DEFER) > > > > > - goto err_alloc; > > > > > > > > > > dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n"); > > > > > pb->legacy = true; > > > > > pb->pwm = pwm_request(data->pwm_id, "pwm-backlight"); > > > > > if (IS_ERR(pb->pwm)) { > > > > > dev_err(&pdev->dev, "unable to request legacy PWM\n"); > > > > > - ret = PTR_ERR(pb->pwm); > > > > > + if (ret != -EPROBE_DEFER) > > > > > + ret = PTR_ERR(pb->pwm); > > > > > + > > > > > goto err_alloc; > > > > > } > > > > > } > > > > > > > > > > which is not tested and may add an extra non-valid error log. > > > > > > > > This is a little risky in my opinion. Not only does it print two error > > > > messages for non-legacy platforms (that would be another regression if > > > > you want to be nit-picking), but it is subtly buggy. If you have a > > > > system with multiple PWM providers, you could end up failing the first > > > > pwm_get() with -EPROBE_DEFER but then continue to the legacy case, and > > > > this could succeed because data->pwm_id == 0, and that other provider > > > > could be exporting the PWM with this ID. If I remember correctly this > > > > was one of the reasons why the offending commit was merged in the first > > > > place. > > > > > > Just for the record, when I proposed this fix to Nicolas, I clearly > > > stated that this was not the way to go, and that fixing the offending > > > platforms to use PWM lookup table was the only sane solution, though I > > > didn't thought about the invalid PWM id case leading to buggy behavior. > > > > As chance would have it, this bubbled to the top of my inbox today: > > > > http://patchwork.ozlabs.org/patch/483993/ > > AFAICT, this is not valid either. This patch is assuming -EPROBE_DEFER > can only be returned in the DT case, which is not the case: it is also > returned if the PWMs were declared with a lookup table but the driver > is not registered yet (module not loaded, or driver registration > taking place after the PWM backlight driver). Right, the non-DT, slightly less legacy case... > If we were about to differentiate the missing PWM definition from > the missing driver case, we should do something like this [1]. > > Best Regards, > > Boris > > [1]http://code.bulix.org/2oozbq-89125 Haha, I came up with exactly this earlier and I've been trying to think of ways in which it could potentially break. Thierry --- >8 --- From f7fee34e0c414b4268c59e97937c51e0c91a74cf Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Mon, 5 Oct 2015 14:38:32 +0200 Subject: [PATCH] pwm: Return -ENODEV if no PWM lookup match is found When looking up a PWM using the lookup table, assume that all entries will have been added already, so failure to find a match means that no corresponding entry has been registered. This fixes an issue where -EPROBE_DEFER would be returned if the PWM lookup table is empty. After this fix, -EPROBE_DEFER is reserved for situations where no provider has yet registered for a matching entry. Signed-off-by: Thierry Reding Reviewed-by: Boris Brezillon --- drivers/pwm/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index 3f9df3ea3350..94e5af123660 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -719,8 +719,10 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id) } } - if (!chosen) + if (!chosen) { + pwm = ERR_PTR(-ENODEV); goto out; + } chip = pwmchip_find_by_name(chosen->provider); if (!chip)