Re: RFC: don't let drivers issue pwm_disable after pwm_config(pwm, 0, period)

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hello Thierry,

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"?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |