[PATCH v12 1/2] pwm: add microchip soft ip corePWM driver

Conor Dooley conor.dooley at microchip.com
Wed Nov 30 03:15:10 PST 2022


On Wed, Nov 30, 2022 at 11:37:55AM +0100, Uwe Kleine-König wrote:
> Hello Conor,

> > > get_state() returns void though, is it valid behaviour to wait for the
> > > timeout there?
> 
> There was an approach to change that, see
> https://lore.kernel.org/linux-pwm/20220916151506.298488-1-u.kleine-koenig@pengutronix.de
> 
> I need to send a v2.

Ahh, yeah. That looks like a better idea. I'd much rather be able to
return an actual error.

> > > I had a check in the core code and found some places where the call in
> > > looks like:
> > > 	struct pwm_state s1, s2; 
> > > 	chip->ops->get_state(chip, pwm, &s1);
> > > In this case, exiting early would leave us with a completely wrong
> > > idead of the state, if it was to time out.
> > > 
> > > Either way, it seems like either way we would be misleading the caller
> > > of get_state() - perhaps the way around that is to do the wait & then
> > > just carry on with get_state()?
> > > In that scenario, you'd get the new settings where possible and the old ones
> > > otherwise.
> > > Returning if the timeout is hit would give you the new settings where possible
> > > & otherwise you'd get whatever was passed to get_state().
> > > I'm not really sure which of those two situations would be preferred?
> 
> Hmm, .get_state should not return the old state. We really want
> .get_state to return an error code. Maybe postpone that question until
> we have that?

If get_state() can return an error, there's no need for the question I
think. I'd rather return what's in the shadow registers *and* on the bus
or an error than an inconsistent state.

I'll send a v(N+1) based on the non-void get_state() at some point
soon-ish.

> > Apologies for bumping this, I was wondering if any thoughts on the
> > above? I'm not sure which is the lesser evil here (or if I have
> > misunderstood something).
> 
> That's fine. I'm sorry to be not more responsive. This development cycle
> is somehow crazy and there are so many open mails in my inbox ... :-\

Oh nw about that at all. I feel bad pinging stuff since I know everyone
is busy.

Thanks,
Conor.




More information about the linux-riscv mailing list