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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Feb 2024 14:25:26 +0530
From: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
To: Will Deacon <will@...nel.org>
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 2/13/2024 7:17 PM, Will Deacon wrote:
> 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?

Since prefetch data stored in this table represent settings for the
ACTLR register, and doesn't exactly define the hardware (So in this
manner prefetch data won't exactly be a part of soc topology ?).
So it seemed apt not to use the device tree for storing the prefetch
property. Hence we reverted from the DT approach (initial proposal in
RFC to piggyback on iommus property to store prefetch settings) back to 
use driver for storing this data.

Some drivers use the same approach for storing their platform specific
data. Examples being
drivers/phy/qualcomm/phy-qcom-qmp-combo.c
drivers/soc/qcom/llcc-qcom.c
These drivers were taken as reference for storing platform specific 
ACTLR data.

Thanks & regards,
Bibek

> 
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ