Re: [PATCHv2] drivers: bus: simple-pm-bus: Fix compatibility with simple-bus for auxdata
From: Rob Herring <robh+dt@kernel.org>
Date: 2021-01-19 18:29:35
Also in:
linux-arm-kernel, linux-omap, lkml
On Mon, Jan 18, 2021 at 2:41 AM Tony Lindgren [off-list ref] wrote:
* Arnd Bergmann [off-list ref] [210118 08:30]:quoted
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.quoted
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.quoted
omap2: I'll leave these for Tony to commentThe three hardest ones to update (because of PM dependencies): - PRM power managment interrupts that also pinctrl driver uses
I haven't looked at it, but can't one driver go find the other node and the interrupts it needs? There's nothing wrong with a driver looking outside 'its node' for information. Rob