On 1/17/19 7:25 AM, Dmitry Osipenko wrote:
> 16.01.2019 23:50, Navneet Kumar пишет:
>> Use PTB_ASID instead of SMMU_CONFIG to flush smmu.
>> PTB_ASID can be accessed from non-secure mode, SMMU_CONFIG cannot be.
>> Using SMMU_CONFIG could pose a problem when kernel doesn't have secure
>> mode access enabled from boot.
>>
>> Signed-off-by: Navneet Kumar <navne...@nvidia.com>
>> ---
>> drivers/iommu/tegra-smmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>> index ee4d8a8..fa175d9 100644
>> --- a/drivers/iommu/tegra-smmu.c
>> +++ b/drivers/iommu/tegra-smmu.c
>> @@ -235,7 +235,7 @@ static inline void smmu_flush_tlb_group(struct
>> tegra_smmu *smmu,
>>
>> static inline void smmu_flush(struct tegra_smmu *smmu)
>> {
>> - smmu_readl(smmu, SMMU_CONFIG);
>> + smmu_readl(smmu, SMMU_PTB_ASID);
>> }
>>
>> static int tegra_smmu_alloc_asid(struct tegra_smmu *smmu, unsigned int *idp)
>>
>
> Driver writes to SMMU_CONFIG during of the probing. Looks like it's better to
> drop this patch for now and make it part of a complete solution that will add
> proper support for a stricter insecure-mode platforms.
>
Thanks for the comment Dmitry. On secure platforms, writing to SMMU_CONFIG will
be a no-op and
will pose no harm. Having this patch is important because it fixes the flushing
behavior on
such platforms, which is critical.
I propose to keep this patch as is, however, i can add more explanation to the
commit message,
stating the case of probe and how it will not have any ill effects. Pls
ACK/NACK, and i shall post
a V2.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
