Re: [PATCHv2] drivers: bus: simple-pm-bus: Fix compatibility with simple-bus for auxdata
From: Tony Lindgren <tony@atomide.com>
Date: 2021-01-18 08:42:49
Also in:
linux-arm-kernel, linux-omap, lkml
* Arnd Bergmann [off-list ref] [210118 08:30]:
On Mon, Jan 18, 2021 at 8:33 AM Tony Lindgren [off-list ref] wrote:quoted
After converting am335x to probe devices with simple-pm-bus I noticed that we are not passing auxdata for of_platform_populate() like we do with simple-bus. While device tree using SoCs should no longer need platform data, there are still quite a few drivers that still need it as can be seen with git grep OF_DEV_AUXDATA. We want to have simple-pm-bus be usable as a replacement for simple-bus also for cases where OF_DEV_AUXDATA is still needed. Let's fix the issue by passing auxdata as platform data to simple-pm-bus. That way the SoCs needing this can pass the auxdata with OF_DEV_AUXDATA. And let's pass the auxdata for omaps to fix the issue for am335x. As an alternative solution, adding simple-pm-bus handling directly to drivers/of/platform.c was considered, but we would still need simple-pm-bus device driver. So passing auxdata as platform data seems like the simplest solution. Fixes: 5a230524f879 ("ARM: dts: Use simple-pm-bus for genpd for am3 l4_wkup") Signed-off-by: Tony Lindgren <tony@atomide.com> --- Changes since v1: Updated description, added devicetree list to CcThis looks fine to me for now Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks for the review.
But I think we should take the time to discuss how to phase out auxdata over time. There are still a number of users, but it's not that many in the end. For some of them I see a clear solution, for other ones I do not:
Yes agreed we should remove the auxdata use.
omap2: I'll leave these for Tony to comment
The three hardest ones to update (because of PM dependencies): - PRM power managment interrupts that also pinctrl driver uses - The enable/disable of clockdomain autoidle that at least ti-sysc uses - Smartreflex PM dependencies to voltage controller For the ones above, I'll try to come up with something eventually. The others should be just straight forward driver updates needed. The hsmmc dependencies would be ideally fixed by moving to use sdhci driver, but at least custom voltage handling and sdio support needs work. Regards, Tony