On Fri, 04 Dec 2020, Thierry Reding wrote: > On Thu, Dec 03, 2020 at 09:41:42AM +0100, Uwe Kleine-König wrote: > > 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") > > Tested-by: Michael Walle <mich...@walle.cc> > > Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de> > > --- > > Hello Linus, > > > > Thierry (who usually sends PWM patches to you) didn't react to this > > patch sent to the pwm Mailinglist last week > > (https://lore.kernel.org/r/20201124212432.3117322-1-u.kleine-koe...@pengutronix.de) > > yet. > > > > Given v5.10 isn't far away any more and I don't know when Thierry will > > take a look and act, I'm sending this directly to you. The affected > > driver was new in 5.10-rc1 and at least once the unpatched driver > > created an oops: > > > > https://lavalab.kontron.com/scheduler/job/108#L950 > > > > Michael Walle who tested this patch is the original author of the > > driver. IMHO it would be good to have this fixed before 5.10. > > > > If you prefer a pull request, I can setup something (but I don't have > > access to Thierry's tree, so it will be for a repository that's new to > > you). > > > > Best regards > > Uwe > > > > drivers/pwm/pwm-sl28cpld.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > I thought I had seen you discuss this with Lee and gotten the impression > that you were going to respin this to move the platform_set_drvdata() to > an earlier point, which I think is the more correct approach. > > container_of() isn't exactly wrong, but it's really just papering over > the fact that platform_set_drvdata() is in the wrong place, so I'd > prefer a patch that does that instead. > > Now, I can no longer find a link to the discussion that I recall, so it > was either on IRC (where I don't have any logs) or I'm loosing my mind.
Don't worry, you are (probably!) still quite sane. The discussion happened over IRC. I highlighted my concerns, but Uwe didn't respond to them. This patch was the next time I saw anything on the subject. > I'll prepare a patch that moves platform_set_drvdata() for Michael to > test. If that works I'll send a PR with fixes to Linus early next week. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog