linux-kernel - Re: [PATCH v2 2/2] soc: rockchip: Fix compile-testing SoC drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 25 Apr 2022 19:09:54 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Brian Norris <briannorris@...omium.org>,
        Heiko Stuebner <heiko@...ech.de>, Arnd Bergmann <arnd@...db.de>
Cc:     linux-kernel@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
        linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] soc: rockchip: Fix compile-testing SoC drivers

On 2022-04-25 18:17, Brian Norris wrote:
> Similar to commit 7f94b69ece51 ("ARM: ixp4xx: fix compile-testing soc
> drivers").
> 
> drivers/soc/rockchip/Kconfig makes plenty of provision for configuring
> drivers either for ARCH_ROCKCHIP or for COMPILE_TEST. But
> drivers/soc/Makefile pulls the rug out from under us, by refusing to
> build anything if we specified COMPILE_TEST but not ARCH_ROCKCHIP.
> 
> Currently, I'm not aware of anything that breaks without this patch, but
> it certainly makes for confusing builds (CONFIG_ROCKCHIP_PM_DOMAINS=y,
> but we didn't actually compile the driver?) and leaves room for future
> error (I have pending patches that break confusingly with COMPILE_TEST=y
> even though their Kconfig dependencies seem correct [1]).
> 
> Defer to drivers/soc/rockchip/{Makefile,Kconfig} to do the right thing.
> 
> We also need to force ARM/ARM64 dependencies for ROCKCHIP_PM_DOMAINS,
> because it uses ARM-specific macros (dsb()).

FWIW, those dsb()s could be replaced with generic wmb()s, assuming their 
purpose is to complete the previous write before polling for the result 
(TBH it's questionable whether that serves any practical purpose given 
the ordering rules for Device memory, but I doubt these are critical 
performance bottlenecks so there doesn't seem to be any real harm in 
being super-conservative). At worst they could be swapped for generic 
mb() with no functional change at all, but it seems even harder to 
justify why that might need to be.

Robin.

> [1] e.g.,
> https://lore.kernel.org/linux-rockchip/20220405184816.RFC.2.I2d73b403944f0b8b5871a77585b73f31ccc62999@changeid/
> [RFC PATCH 2/2] PM / devfreq: rk3399_dmc: Block PMU during transitions
> 
> Signed-off-by: Brian Norris <briannorris@...omium.org>
> ---
> 
> Changes in v2:
>   * Depend on ARM||ARM64
> 
>   drivers/soc/Makefile         | 2 +-
>   drivers/soc/rockchip/Kconfig | 1 +
>   2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index fd7717d597fc..4c91705a8bb3 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -23,7 +23,7 @@ obj-y				+= pxa/
>   obj-y				+= amlogic/
>   obj-y				+= qcom/
>   obj-y				+= renesas/
> -obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
> +obj-y				+= rockchip/
>   obj-$(CONFIG_SOC_SAMSUNG)	+= samsung/
>   obj-$(CONFIG_SOC_SIFIVE)	+= sifive/
>   obj-y				+= sunxi/
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index aff2f7e95237..785e1798d286 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -25,6 +25,7 @@ config ROCKCHIP_IODOMAIN
>   config ROCKCHIP_PM_DOMAINS
>   	bool "Rockchip generic power domain"
>   	depends on PM
> +	depends on ARM || ARM64
>   	select PM_GENERIC_DOMAINS
>   	help
>   	  Say y here to enable power domain support.