Received: by 10.223.148.5 with SMTP id 5csp6429358wrq; Wed, 17 Jan 2018 13:39:38 -0800 (PST) X-Google-Smtp-Source: ACJfBouw8qsmekAMGDRrdv3jdxZeBd16V63TR5SwwUn+YIetmGOdm+BYNX/BBXWaqkBZFz1e4iNV X-Received: by 10.84.199.194 with SMTP id d2mr3377138plh.343.1516225178251; Wed, 17 Jan 2018 13:39:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516225178; cv=none; d=google.com; s=arc-20160816; b=Cyqh24YplaAguh9M4qNmi+Yn/SO6qF1Nak0wlLeFdYNEB+gR4W8+fyvoXYgggXOCPj uPQoR6BktxNcI+wVzvD5TE7CNTN1nqpqrW4KHBwzk0Pj73YJc73IHdXXZ9cdB+Nf2tkO JhNi5OTNU+R8ffpXgnNXWHgidtvSPeZpIyv+Zwhbpl54y/oWRuguiws1GPmPL4Khx4VU PXH/Grjk6duFG212xtxa/hm8foablmdg1gdxDSpo32N+liAkmLG+DH+RY9gnLY3u5OB1 HWCRvZ/DkCy1HORUhPCXtMqApbL2jtkfUU3Qzsk8vYAS6NZKSYhErfTlWTaFJ3OcfSxe GayQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=SQVa39mu5K0T/hM/p/IfTuXywdy5N+nY5Tjn3NY5J64=; b=iY7+OAF1U+/RKSVC360Os/BsJQlBqO5ilFWNwhmXzWqd1TsLSsnwEyO5G7n7qBpFRu a468kRBr+Aw5PCANT57VhKbnuoA6S3DCPTd3YWzGH4z13x0S0sD/5sDa6fY7Ps3pWTpP Y6fTE2MT1mfLUiyS1tI1KvoaUY2NpbSLQvSxJS95ghZXRhAFg7unf4DNHISWQReqNE3g Y7ORuKkdJ/zplgfU6/3LDzfRfRgjxCRDTCLTFYbhIa2F6Vc1nEUA/9Lpbk2TU9uGq+oT +jDh9C1mQNLUv0MzPbxc4ueQKwupr/K4G/EnT2KqAxrmK8+zsUJyeTa2GMIPTHoS/1qy Hr6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=LGAx0kbU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w18si4655661pgm.799.2018.01.17.13.39.23; Wed, 17 Jan 2018 13:39:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=LGAx0kbU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753406AbeAQViZ (ORCPT + 99 others); Wed, 17 Jan 2018 16:38:25 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:40925 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752778AbeAQViX (ORCPT ); Wed, 17 Jan 2018 16:38:23 -0500 Received: by mail-wm0-f68.google.com with SMTP id v123so18718505wmd.5 for ; Wed, 17 Jan 2018 13:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=SQVa39mu5K0T/hM/p/IfTuXywdy5N+nY5Tjn3NY5J64=; b=LGAx0kbU+sqOe6WZRorsXQczbqyeRwV2qO5HPn4nzjAdcRtp+7jF7n3b8JPEVv8I3A /oraAyrRN0WBM/praAMKYID0/+zZ216ZLV+VSeFblcUtxddKEefnkuKj7TWxZC3r5pov oMzUIwoe+gb6rOeR75tczdcWwwMrbK6M1YW20= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=SQVa39mu5K0T/hM/p/IfTuXywdy5N+nY5Tjn3NY5J64=; b=cTHBVHxEMw1DgjJgaRFvgh2FgNzOSIcuxze/P4dusQiJxpc6/vm817gu6PpnKcs+Z7 aYQK7HJ1B1p/5PN7xuM6OJqQaG050FvST6Bpnye4s/bS/0VSO5BrgLdraQXpigvVxOn8 LDYutk56lAfeR6nSg3VDHDY1T5JgPiob6hgSw9NsdstivVbF/zZQHz9dnDGWUeQzf/ps 7lVCEUc94DaMNcx+/sBkxF5mOGNEwCzAr+PNsMBDP4ajgV7mfZ+JII1t0QTFSlboaICj 8lO2Sxef2sDTK2E6WJtXDbGSQtjAeHKybJcUQbJhBraFIStbs0TeOwMDfbzWe8fVWrTU yWEQ== X-Gm-Message-State: AKwxytdFvV8Ma3/DEK1yofOo7YN/wS0vVkyAigjnnnpzyWMJRMo07eIs DwLBUzDTwlJC6ztIFd5uba/b5G5z X-Received: by 10.80.158.169 with SMTP id a38mr4849935edf.72.1516225102384; Wed, 17 Jan 2018 13:38:22 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:56e6:0:e4bc:76a0:8042:669e]) by smtp.gmail.com with ESMTPSA id y3sm2975257edb.1.2018.01.17.13.38.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jan 2018 13:38:21 -0800 (PST) Date: Wed, 17 Jan 2018 22:38:19 +0100 From: Daniel Vetter To: Daniel Thompson Cc: Daniel Vetter , DRI Development , LKML , Lee Jones , Jingoo Han , Daniel Vetter Subject: Re: [PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1 Message-ID: <20180117213819.GB2759@phenom.ffwll.local> Mail-Followup-To: Daniel Thompson , DRI Development , LKML , Lee Jones , Jingoo Han , Daniel Vetter References: <20180117140159.27611-1-daniel.vetter@ffwll.ch> <20180117140159.27611-3-daniel.vetter@ffwll.ch> <7adf519b-68fa-e1c5-c001-68bf52f7e0b7@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7adf519b-68fa-e1c5-c001-68bf52f7e0b7@linaro.org> X-Operating-System: Linux phenom 4.14.0-1-amd64 User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks a lot for your comments. On Wed, Jan 17, 2018 at 04:47:41PM +0000, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > Leaking driver internal tracking into the already massively confusing > > backlight power tracking is really confusing. > > > > Stop that by allocating a tiny driver private data structure instead. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Signed-off-by: Daniel Vetter > > --- > > drivers/video/backlight/pandora_bl.c | 26 +++++++++++++++++++------- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/video/backlight/pandora_bl.c b/drivers/video/backlight/pandora_bl.c > > index a186bc677c7d..6bd159946a47 100644 > > --- a/drivers/video/backlight/pandora_bl.c > > +++ b/drivers/video/backlight/pandora_bl.c > > @@ -35,11 +35,15 @@ > > #define MAX_VALUE 63 > > #define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE) > > -#define PANDORABL_WAS_OFF BL_CORE_DRIVER1 > > +struct pandora_private { > > + unsigned old_state; > > +#define PANDORABL_WAS_OFF 1 > > Nit, but we using old_state like a bitfield so, BIT(0)? > > > > +}; > > static int pandora_backlight_update_status(struct backlight_device *bl) > > { > > int brightness = bl->props.brightness; > > + struct pandora_private *priv = bl_get_data(bl); > > u8 r; > > if (bl->props.power != FB_BLANK_UNBLANK) > > @@ -53,7 +57,7 @@ static int pandora_backlight_update_status(struct backlight_device *bl) > > brightness = MAX_USER_VALUE; > > if (brightness == 0) { > > - if (bl->props.state & PANDORABL_WAS_OFF) > > + if (priv->old_state & PANDORABL_WAS_OFF) > > goto done; > > /* first disable PWM0 output, then clock */ > > @@ -66,7 +70,7 @@ static int pandora_backlight_update_status(struct backlight_device *bl) > > goto done; > > } > > - if (bl->props.state & PANDORABL_WAS_OFF) { > > + if (priv->old_state & PANDORABL_WAS_OFF) { > > /* > > * set PWM duty cycle to max. TPS61161 seems to use this > > * to calibrate it's PWM sensitivity when it starts. > > @@ -93,9 +97,9 @@ static int pandora_backlight_update_status(struct backlight_device *bl) > > done: > > if (brightness != 0) > > - bl->props.state &= ~PANDORABL_WAS_OFF; > > + priv->old_state 0; > > else > > - bl->props.state |= PANDORABL_WAS_OFF; > > + priv->old_state = PANDORABL_WAS_OFF; > > Well, we were using it like a bitfield until this bit... I had a simple boolean first (because that's all we neeed), but that made the code less readable. Should I s/1/true/ in the #define? The entire C99 bool tends to be a bit a bikeshed sometimes :-) > > > > return 0; > > } > > @@ -109,15 +113,23 @@ static int pandora_backlight_probe(struct platform_device *pdev) > > { > > struct backlight_properties props; > > struct backlight_device *bl; > > + struct pandora_private *priv; > > u8 r; > > + priv = devm_kmalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > > + if (!priv) { > > + dev_err(&pdev->dev, "failed to allocate driver private data\n"); > > + return -ENOMEM; > > + } > > + > > memset(&props, 0, sizeof(props)); > > props.max_brightness = MAX_USER_VALUE; > > props.type = BACKLIGHT_RAW; > > bl = devm_backlight_device_register(&pdev->dev, pdev->name, &pdev->dev, > > - NULL, &pandora_backlight_ops, &props); > > + priv, &pandora_backlight_ops, &props); > > if (IS_ERR(bl)) { > > dev_err(&pdev->dev, "failed to register backlight\n"); > > + kfree(priv); > > Why can't we rely on devres for cleanup? Argh, I had kmalloc first and then changed to devm_kmalloc. The kfree here needs to go indeed. Cheers, Daniel > > > > return PTR_ERR(bl); > > } > > @@ -126,7 +138,7 @@ static int pandora_backlight_probe(struct platform_device *pdev) > > /* 64 cycle period, ON position 0 */ > > twl_i2c_write_u8(TWL_MODULE_PWM, 0x80, TWL_PWM0_ON); > > - bl->props.state |= PANDORABL_WAS_OFF; > > + priv->old_state = PANDORABL_WAS_OFF; > > bl->props.brightness = MAX_USER_VALUE; > > backlight_update_status(bl); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch