Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case

[Boris Brezillon <boris.brezillon@collabora.com>]

On Mon, 18 Mar 2024 11:31:05 +0000
Steven Price <steven.price@arm.com> wrote:

> On 18/03/2024 08:58, Boris Brezillon wrote:
> > Putting a hard dependency on CONFIG_PM is not possible because of a
> > circular dependency issue, and it's actually not desirable either. In
> > order to support this use case, we forcibly resume at init time, and
> > suspend at unplug time.
> > 
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202403031944.EOimQ8WK-lkp@intel.com/
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>  
> 
> Reviewed-by: Steven Price <steven.price@arm.com>
> 
> > ---
> > Tested by faking CONFIG_PM=n in the driver (basically commenting
> > all pm_runtime calls, and making the panthor_device_suspend/resume()
> > calls unconditional in the panthor_device_unplug/init() path) since
> > CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I
> > can't be 100% sure this will work correctly on a platform that has
> > CONFIG_PM=n.  
> 
> The same - I can't test this properly :(
> 
> Note that the other option (which AFAICT doesn't cause any problems) is
> to "select PM" rather than depend on it - AIUI the 'select' dependency
> is considered in the opposite direction by kconfig so won't cause the
> dependency loop.

Doesn't seem to work with COMPILE_TEST though? I mean, we need
something like

	depends on ARM || ARM64 || (COMPILE_TEST && PM)
	...
	select PM

but kconfig doesn't like that

drivers/gpu/drm/panthor/Kconfig:3:error: recursive dependency detected!
drivers/gpu/drm/panthor/Kconfig:3:	symbol DRM_PANTHOR depends on
PM kernel/power/Kconfig:183:	symbol PM is selected by DRM_PANTHOR

which id why I initially when for a depends on PM


> Of course if there is actually anyone who has a
> platform which can be built !CONFIG_PM then that won't help. But the
> inability of anyone to actually properly test this configuration does
> worry me a little.

Well, as long as it doesn't regress the PM behavior, I think I'm happy
to take the risk. Worst case scenario, someone complains that this is
not working properly when they do the !PM bringup :-).