From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org, Gavin Schenk <g.schenk@eckelmann.de>,
kernel@pengutronix.de
Subject: Re: RFC: don't let drivers issue pwm_disable after pwm_config(pwm, 0, period)
Date: Thu, 27 Sep 2018 22:29:55 +0200 [thread overview]
Message-ID: <20180927202955.GA4184@ulmo> (raw)
In-Reply-To: <20180927182607.7onqymk5cde522kr@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
On Thu, Sep 27, 2018 at 08:26:07PM +0200, Uwe Kleine-König wrote:
> Hello Thierry,
>
> On Fri, Sep 21, 2018 at 06:02:30PM +0200, Uwe Kleine-König wrote:
> > On Tue, Sep 04, 2018 at 10:37:24PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Aug 20, 2018 at 11:52:21AM +0200, Uwe Kleine-König wrote:
> > > > On Thu, Aug 09, 2018 at 05:23:30PM +0200, Uwe Kleine-König wrote:
> > > > > On Thu, Aug 09, 2018 at 01:30:54PM +0200, Thierry Reding wrote:
> > > > > > I don't see how you could make that work. In practically all cases a
> > > > > > pwm_disable() would have to be assumed to cause the pin level to become
> > > > > > undefined. That makes it pretty much useless.
> > > > >
> > > > > Right, that's what I want. pwm_disable() should make no guarantees about
> > > > > the pin level. [...]
> > > > >
> > > > > > I agree that this is simpler and clearer. However it also significantly
> > > > > > reduces the flexibility of the API, and I'm not sure that it is enough.
> > > > > > Again, yes, for many cases this is sufficient, but it doesn't fully
> > > > > > expose the capabilities of hardware.
> > > > >
> > > > > Can you show me a use case that isn't possible to express with the
> > > > > suggested change in semantic?
> > > >
> > > > To get forward here the only missing points are:
> > > >
> > > > a) Your claim that this simplification looses expressive power.
> > > > b) Actually convert the users (assuming a) can be resolved)
> > > >
> > > > I cannot find a usecase that cannot be handled with the suggested change
> > > > in semantic. So can I lure you in explaining what setup you have in
> > > > mind?
> > >
> > > I'd really like to get forward here, so you feedback would be very
> > > welcome. What is the use case you have in mind when writing "it also
> > > significantly reduces the flexibility of the API, and I'm not sure that
> > > it is enough"?
> >
> > I'm a bit irritated that you don't continue to communicate here. On
> > August 9 I had the impression that we can discuss this topic to an end.
> > But as you stopped replying we unfortunately cannot :-|
>
> Seeing you reply on other topics I wonder what is the problem here. Can
> you at least quickly confirm that you received my mails?
Confirming that I'm receiving your emails. Sorry, but I haven't found
the necessary time to look at the details here any closer to continue
the discussion in a meaningful way.
I will hopefully get around to it within the next couple of days.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-09-27 20:29 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-06 15:51 RFC: don't let drivers issue pwm_disable after pwm_config(pwm, 0, period) Uwe Kleine-König
2018-08-09 11:30 ` Thierry Reding
2018-08-09 15:23 ` Uwe Kleine-König
2018-08-20 9:52 ` Uwe Kleine-König
2018-08-20 14:43 ` [PATCH 0/2] specify the pin state after pwm_disable as explicitly undefined Uwe Kleine-König
2018-08-20 14:43 ` [PATCH 1/2] pwm: document the pin state after pwm_disable() to be undefined Uwe Kleine-König
2018-10-09 7:34 ` Thierry Reding
2018-10-09 9:04 ` Uwe Kleine-König
2018-10-16 7:44 ` Boris Brezillon
2018-10-16 9:07 ` Uwe Kleine-König
2018-10-18 8:44 ` Uwe Kleine-König
2018-10-18 14:44 ` Thierry Reding
2018-10-18 20:43 ` Uwe Kleine-König
2018-10-18 15:06 ` Thierry Reding
2018-08-20 14:43 ` [PATCH 2/2] pwm: warn callers of pwm_apply_state() that expect a certain level after disabling Uwe Kleine-König
2018-09-04 20:37 ` RFC: don't let drivers issue pwm_disable after pwm_config(pwm, 0, period) Uwe Kleine-König
2018-09-21 16:02 ` Uwe Kleine-König
2018-09-27 18:26 ` Uwe Kleine-König
2018-09-27 20:29 ` Thierry Reding [this message]
2018-10-08 20:02 ` Uwe Kleine-König
2018-10-09 7:53 ` Thierry Reding
2018-10-09 9:35 ` Uwe Kleine-König
2018-10-10 12:26 ` Thierry Reding
2018-10-10 13:50 ` Vokáč Michal
2018-10-11 10:19 ` Uwe Kleine-König
2018-10-11 12:00 ` Thierry Reding
2018-10-11 13:15 ` Vokáč Michal
2018-10-12 9:45 ` Uwe Kleine-König
2018-10-12 10:11 ` Thierry Reding
2018-10-14 11:34 ` Uwe Kleine-König
2018-10-15 8:14 ` Uwe Kleine-König
2018-10-15 8:16 ` Uwe Kleine-König
2018-10-15 9:28 ` Thierry Reding
2018-10-15 9:22 ` Thierry Reding
2018-10-15 12:33 ` Uwe Kleine-König
2018-10-12 12:25 ` Vokáč Michal
2018-10-12 15:47 ` Uwe Kleine-König
2018-10-11 20:34 ` Uwe Kleine-König
2018-10-12 9:53 ` Thierry Reding
2018-10-12 10:00 ` Thierry Reding
2018-10-12 17:14 ` Uwe Kleine-König
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=20180927202955.GA4184@ulmo \
--to=thierry.reding@gmail.com \
--cc=g.schenk@eckelmann.de \
--cc=kernel@pengutronix.de \
--cc=linux-pwm@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).