From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
Clemens Gruber <clemens.gruber@pqgruber.com>,
linux-pwm@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
David Jander <david@protonic.nl>
Subject: Re: [PATCH v4 1/4] pwm: pca9685: Switch to atomic API
Date: Fri, 11 Dec 2020 09:33:55 +0100 [thread overview]
Message-ID: <X9Mu8zrJjFTe6fJq@ulmo> (raw)
In-Reply-To: <20201210203926.ouzrq3ff5k6zhlvt@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
On Thu, Dec 10, 2020 at 09:39:26PM +0100, Uwe Kleine-König wrote:
> Hello Thierry,
>
> On Thu, Dec 10, 2020 at 06:10:45PM +0100, Thierry Reding wrote:
> > Like I said, that's not what I was saying. I was merely saying that if
> > there aren't any use-cases that current users rely on that would be
> > broken by using this simpler implementation, then I'm okay with it, even
> > if it's less flexible than a more complicated implementation. It should
> > be possible to determine what the current users are by inspecting device
> > trees present in the kernel. Anything outside the kernel isn't something
> > we need to consider, as usual.
>
> If "users in mainline" is the criteria that's a word.
I didn't say "users in mainline", I said "use-cases". What I don't want
to happen is for this change under discussion to break any existing use-
cases of any existing users in the kernel. I said that we can determine
what the existing users are by looking at which device trees use the
compatible strings that the driver matches on.
> So you agree we remove the following drivers?:
>
> - pwm-hibvt.c
> Last driver specific change in Feb 2019, no mainline user
> - pwm-sprd.c
> Last driver specific change in Aug 2019, no mainline user
No, that's an extrapolation of what I was saying above. Drivers with no
apparent users are a separate topic, so don't conflate it with the issue
at hand.
While it's certainly unfortunate that these don't seem to be used, I see
no reason why we should remove them. They don't create much of a
maintenance burden, so I'm fine with keeping them in the hopes that
users may still show up at some point.
> Most PWMs are added to cpu.dtsi files with status = "disabled", I wonder
> if it makes sense to check the machine.dts files if some of the PMWs are
> completely unused. Do you consider status = "okay" a use that we have to
> retain even if the node has no phandle?
A PWM controller may be in use via sysfs even if it has no phandle.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-12-11 8:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 19:36 [PATCH v4 1/4] pwm: pca9685: Switch to atomic API Clemens Gruber
2020-12-07 19:36 ` [PATCH v4 2/4] pwm: pca9685: Set full OFF bits in probe Clemens Gruber
2020-12-07 19:36 ` [PATCH v4 3/4] pwm: pca9685: Support staggered output ON times Clemens Gruber
2020-12-07 19:38 ` [PATCH v4 4/4] dt-bindings: pwm: pca9685: Add nxp,staggered-outputs property Clemens Gruber
2020-12-07 22:00 ` [PATCH v4 1/4] pwm: pca9685: Switch to atomic API Uwe Kleine-König
2020-12-07 22:34 ` Sven Van Asbroeck
2020-12-07 23:24 ` Clemens Gruber
2020-12-08 9:17 ` Uwe Kleine-König
2020-12-07 23:13 ` Clemens Gruber
2020-12-08 9:10 ` Uwe Kleine-König
2020-12-08 10:12 ` Clemens Gruber
2020-12-08 13:44 ` Thierry Reding
2020-12-08 14:44 ` Sven Van Asbroeck
2020-12-08 16:57 ` Thierry Reding
2020-12-08 18:15 ` Sven Van Asbroeck
2020-12-08 20:25 ` Uwe Kleine-König
2020-12-08 18:26 ` Uwe Kleine-König
2020-12-08 20:54 ` Clemens Gruber
2020-12-09 17:02 ` Thierry Reding
2020-12-10 9:01 ` Uwe Kleine-König
2020-12-10 17:10 ` Thierry Reding
2020-12-10 20:39 ` Uwe Kleine-König
2020-12-11 8:33 ` Thierry Reding [this message]
2020-12-11 10:34 ` Uwe Kleine-König
2020-12-14 14:28 ` Thierry Reding
2020-12-14 16:09 ` Clemens Gruber
2020-12-14 16:27 ` Sven Van Asbroeck
2020-12-14 16:44 ` Sven Van Asbroeck
2020-12-10 20:54 ` Clemens Gruber
2020-12-10 21:37 ` Sven Van Asbroeck
2020-12-07 23:22 ` Sven Van Asbroeck
2020-12-07 23:56 ` Clemens Gruber
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=X9Mu8zrJjFTe6fJq@ulmo \
--to=thierry.reding@gmail.com \
--cc=clemens.gruber@pqgruber.com \
--cc=david@protonic.nl \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=thesven73@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.