linux-kernel - Re: [PATCH v9 4/5] iommu/arm-smmu: add ACTLR data and support for SM8550

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240213134714.GC28926@willie-the-truck>
Date: Tue, 13 Feb 2024 13:47:14 +0000
From: Will Deacon <will@...nel.org>
To: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
Cc: robin.murphy@....com, joro@...tes.org, dmitry.baryshkov@...aro.org,
	konrad.dybcio@...aro.org, jsnitsel@...hat.com,
	quic_bjorande@...cinc.com, mani@...nel.org,
	quic_eberman@...cinc.com, robdclark@...omium.org,
	u.kleine-koenig@...gutronix.de, robh@...nel.org,
	vladimir.oltean@....com, quic_pkondeti@...cinc.com,
	quic_molvera@...cinc.com, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, krzysztof.kozlowski+dt@...aro.org,
	saravanak@...gle.com
Subject: Re: [PATCH v9 4/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550

On Tue, Jan 23, 2024 at 08:15:42PM +0530, Bibek Kumar Patro wrote:
> Add ACTLR data table for SM8550 along with support for
> same including SM8550 specific implementation operations.
> 
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 90 ++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 6004c6d9a7b2..db15b1eade97 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -23,6 +23,86 @@
> 
>  #define CPRE			(1 << 1)
>  #define CMTLB			(1 << 0)
> +#define PREFETCH_SHIFT		8
> +#define PREFETCH_DEFAULT	0
> +#define PREFETCH_SHALLOW	(1 << PREFETCH_SHIFT)
> +#define PREFETCH_MODERATE	(2 << PREFETCH_SHIFT)
> +#define PREFETCH_DEEP		(3 << PREFETCH_SHIFT)
> +#define PREFETCH_SWITCH_GFX	(5 << 3)
> +
> +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
> +	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +	{ 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
> +	{ 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
> +	{ 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
> +	{ 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
> +	{ 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +	{ 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +	{ 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +	{ 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +	{ 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +	{ 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },

[...]

Isn't this effectively hard-coding the topology of the SoC in the driver?
Wouldn't it better describing higher-level prefetch properties in the DT
nodes corresponding to the upstream devices?

Looking back at the prior revisions of this series, it seems like others
were in favour of this approach, so if that's the general consensus, then
so be it. But is this _really_ what we want in the SMMU driver? It would
be good to have an Ack from Robin and a DT maintainer on this mechanism.

It just all feels a bit like a step back into the bad old world of
platform data to me, where we end up trying to maintain a bunch of random
constants that supposedly make things faster for somebody :/

Will