linux-kernel - Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1

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]

Date:   Tue, 16 Jul 2019 16:47:07 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Vivek Gautam <vivek.gautam@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Sibi Sankar <sibis@...eaurora.org>
Subject: Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1

Quoting Vivek Gautam (2019-06-12 02:26:20)
> 
> 
> On 6/11/2019 4:51 AM, Stephen Boyd wrote:
> > hardware signal like the NS bit and/or the Execution Level. Hopefully
> > it's a config and then our difference from MTP can be minimized.
> 
> I don't think SMMU limits any such programming of SIDs. It's a design 
> decision
> to program few SIDs in TZ/Hyp and allocate the corresponding context banks
> and create respective mappings. You should be able to see these SMR 
> configurations
> before kernel boots up. I use a simple T32 command -
> 
> smmu.add "<name>" <smmu_type> <base_address>
> smmu.streammaptable <name>
> 
> e.g. for sdm845 apps_smmu
> 
> smmu.add "apps" MMU500 a:0x15000000
> smmu.StreamMapTable apps
> 
> This dumps all the information regarding the smmu.

Preferably I can see this by using devmem instead of jtag and T32. Do
you know the address of the register? Otherwise I'll go dig into the
documentation and try to figure it out.

> 
> >
> > As far as I can tell, HLOS on SDM845 has always used GPI (yet another
> > DMA engine) to do the DMA transfers. And the GPI is the hardware block
> > that uses the SID of 0x6d6 above, so putting that into iommus for the
> > geniqup doesn't make any sense given that GPI is another node. Can you
> > confirm this is the case? Furthermore, the SID of 0x6c3 sounds untested?
> > Has it ever been generated on SDM845 MTP?
> 
> I will get back with this information.
> 

Any update?