On Wed, Nov 30, 2022 at 04:21:37PM +0100, Uwe Kleine-König wrote: > Hello, > > I forgot about this series and was remembered when I talked to Conor > Dooley about how .get_state() should behave in an error case. > > Compared to (implicit) v1, sent with Message-Id: 20220916151506.298488-1-u.kleine-koenig@xxxxxxxxxxxxxx > I changed: > > - Patch #1 which does the prototype change now just adds "return 0" to > all implementations and so gets simpler and doesn't change behaviour. > The adaptions to the different .get_state() implementations are split > out into individual patches to ease review. > - One minor inconsistency fixed in "pwm: Handle .get_state() failures" > that I noticed while looking into this patch. > - I skipped changing sun4i.c as I don't know how to handle the error > there. Someone might want to have a look. (That's not ideal, but it's > not worse than the same issue before this series.) > > In v1 Thierry had the concern: > > | That raises the question about what to do in these cases. If we return > | an error, that could potentially throw off consumers. So perhaps the > | closest would be to return a disabled PWM? Or perhaps it'd be up to the > | consumer to provide some fallback configuration for invalidly configured > | or unconfigured PWMs. > > .get_state() is only called in pwm_device_request on a pwm_state that a > consumer might see. Before my series a consumer might have seen a > partial modified pwm_state (because .get_state() might have modified > .period, then stumbled and returned silently). The last patch ensures > that this partial modification isn't given out to the consumer. Instead > they now see the same as if .get_state wasn't implemented at all. I'm wondering why we didn't see a compiler warning about mistyped function prototypes in some drivers. P.S. The series is good thing to do, thank you. -- With Best Regards, Andy Shevchenko
