From: Daniel Thompson <daniel.thompson@linaro.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee@kernel.org>, Jingoo Han <jingoohan1@gmail.com>,
linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] backlight: pwm_bl: Drop support for legacy PWM probing
Date: Thu, 17 Nov 2022 11:06:25 +0000 [thread overview]
Message-ID: <Y3YVsaO38g9EUgHq@maple.lan> (raw)
In-Reply-To: <20221117102814.vdgixgfq4pr77fly@pengutronix.de>
On Thu, Nov 17, 2022 at 11:28:14AM +0100, Uwe Kleine-König wrote:
> On Thu, Nov 17, 2022 at 10:14:01AM +0000, Daniel Thompson wrote:
> > On Thu, Nov 17, 2022 at 08:21:51AM +0100, Uwe Kleine-König wrote:
> > > There is no in-tree user left which relies on legacy probing. So drop
> > > support for it which removes another user of the deprecated
> > > pwm_request() function.
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >
> > I have to take the "no in-tree user" on faith since I'm not familiar
> > enough with PWM history to check that. However from a backlight
> > point-of-view it looks like a nice tidy up:
> > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
>
> Probably "in-tree provider" would have been the better term. You can
> convince you about that:
>
> $ git grep -l platform_pwm_backlight_data | xargs grep pwm_id
>
> That is, no machine used pwm_id to make the legacy lookup necessary.
Thanks for that. pwm_request() seems so old that my intuition about
how device APIs in Linux work misled me and I completely missed that
the consumption of pwm_id at the call site was the key to the source
navigation here.
> Who will pick up this patch? Should I resend for s/user/provider/?
Lee Jones should hoover this up. Normally I only pick up backlight
patches when Lee's on holiday ;-).
No need to resend on my account. I interpreted the original
description as "provider" anyway, I just didn't know how best to
search for them.
Daniel.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org, Jingoo Han <jingoohan1@gmail.com>,
Lee Jones <lee@kernel.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH] backlight: pwm_bl: Drop support for legacy PWM probing
Date: Thu, 17 Nov 2022 11:06:25 +0000 [thread overview]
Message-ID: <Y3YVsaO38g9EUgHq@maple.lan> (raw)
In-Reply-To: <20221117102814.vdgixgfq4pr77fly@pengutronix.de>
On Thu, Nov 17, 2022 at 11:28:14AM +0100, Uwe Kleine-König wrote:
> On Thu, Nov 17, 2022 at 10:14:01AM +0000, Daniel Thompson wrote:
> > On Thu, Nov 17, 2022 at 08:21:51AM +0100, Uwe Kleine-König wrote:
> > > There is no in-tree user left which relies on legacy probing. So drop
> > > support for it which removes another user of the deprecated
> > > pwm_request() function.
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >
> > I have to take the "no in-tree user" on faith since I'm not familiar
> > enough with PWM history to check that. However from a backlight
> > point-of-view it looks like a nice tidy up:
> > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
>
> Probably "in-tree provider" would have been the better term. You can
> convince you about that:
>
> $ git grep -l platform_pwm_backlight_data | xargs grep pwm_id
>
> That is, no machine used pwm_id to make the legacy lookup necessary.
Thanks for that. pwm_request() seems so old that my intuition about
how device APIs in Linux work misled me and I completely missed that
the consumption of pwm_id at the call site was the key to the source
navigation here.
> Who will pick up this patch? Should I resend for s/user/provider/?
Lee Jones should hoover this up. Normally I only pick up backlight
patches when Lee's on holiday ;-).
No need to resend on my account. I interpreted the original
description as "provider" anyway, I just didn't know how best to
search for them.
Daniel.
next prev parent reply other threads:[~2022-11-17 11:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 7:21 [PATCH] backlight: pwm_bl: Drop support for legacy PWM probing Uwe Kleine-König
2022-11-17 7:21 ` Uwe Kleine-König
2022-11-17 10:14 ` Daniel Thompson
2022-11-17 10:14 ` Daniel Thompson
2022-11-17 10:28 ` Uwe Kleine-König
2022-11-17 10:28 ` Uwe Kleine-König
2022-11-17 11:06 ` Daniel Thompson [this message]
2022-11-17 11:06 ` Daniel Thompson
2022-11-17 11:54 ` Lee Jones
2022-11-17 11:54 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y3YVsaO38g9EUgHq@maple.lan \
--to=daniel.thompson@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jingoohan1@gmail.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.