On Tue, Nov 24, 2020 at 11:22:33PM +0100, Michael Walle wrote:
> Am 2020-11-24 22:24, schrieb Uwe Kleine-König:
> > Currently .get_state() and .apply() use dev_get_drvdata() on the struct
> > device related to the pwm chip. This only works after .probe() called
> > platform_set_drvdata() which in this driver happens only after
> > pwmchip_add() and so comes possibly too late.
> > 
> > Instead of setting the driver data earlier use the traditional
> > container_of approach as this way the driver data is conceptually and
> > computational nearer.
> > 
> > Fixes: 9db33d221efc ("pwm: Add support for sl28cpld PWM controller")
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> 
> I wasn't able to reproduce the original bug, it seems it is really
> timing/kernel/kernel config dependent. Thus I could only test if it
> still working and could not verify that the original bug is fixed.
> Nonetheless:
> 
> Tested-by: Michael Walle <michael@walle.cc>
> 
> 
> Btw. the backtrace is available here:
>   https://lavalab.kontron.com/scheduler/job/108#L950

This is triggered from deferred_probe_work, so my best guess is that
both the pwm-fan (here the consumer) and the pwm hardware driver were
probed in parallel with a timing that made pwm-fan hit the short window
when driver data was unset.

I wonder if we {sh,c}ould expand PWM_DEBUG to hit this kind of error.
E.g. let pwmchip_add() request and get_state each PWM.

Best regards
Uwe

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