All of lore.kernel.org
 help / color / mirror / Atom feed
From: thunder.leizhen@huawei.com (leizhen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding
Date: Tue, 17 Jun 2014 15:50:20 +0800	[thread overview]
Message-ID: <539FF33C.7020007@huawei.com> (raw)
In-Reply-To: <20140616163930.GX16758@arm.com>

On 2014/6/17 0:39, Will Deacon wrote:
> On Thu, Jun 12, 2014 at 06:08:12AM +0100, Zhen Lei wrote:
>> This patch adds a description of private properties for the Hisilicon
>> System MMU architecture.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index f284b99..75b1351 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -15,6 +15,7 @@ conditions.
>>                          "arm,smmu-v2"
>>                          "arm,mmu-400"
>>                          "arm,mmu-500"
>> +                        "hisilicon,smmu-v1"
>>
>>                    depending on the particular implementation and/or the
>>                    version of the architecture implemented.
>> @@ -54,6 +55,21 @@ conditions.
>>                    aliases of secure registers have to be used during
>>                    SMMU configuration.
>>
>> +** Hisilicon SMMU private properties:
>> +
>> +- smmu-force-memtype : A list of StreamIDs which not translate address but
>> +                  translate attributes. The StreamIDs list here can not be
>> +                  used for map(translation) mode again.
>> +                  StreamID first, then the type list below:
>> +                  1, cahceable, WBRAWA, Normal outer and inner write-back
>> +                  2, non-cacheable, Normal outer and inner non-cacheable
>> +                  3, device, nGnRE
>> +                  others, bypass
>> +
>> +- smmu-bypass-vmid   : Specify which context bank is used for bypass mode.
>> +                  If omit, vmid=255 is default. If bypass and map mode can
>> +                  share a same S2CR, config vmid=0.
> 
> These don't feel like they belong in the device-tree to me. Is the list of
> StreamIDs described in smmu-force-memtype a property of the hardware
> configuration, or a software policy to allow you to generate cacheable
> traffic for particular masters?
> 
> Will
> 
> .
> 
OK, I will put these description into a sperate file, hisilicon,smmu.txt
and mark a reference to arm,smmu.txt

The latter case. Some masters driver want use cacheable(WB) attribute to access
memory, but the masters can not bring cacheable attribute. So, can not use
bypass(or transaction) mode. In fact, the master driver can use iommu_map to
create map and specify IOMMU_CACHE. But maybe the driver does not want to
map, if the memory access is very dynamically, frequently map and unmap will
decrease performance.

Actually, I think smmu-force-memtype maybe suitable for arm-smmu too. But now,
if nobody declear need it, I will just implement it in hisi-smmu.c

A big issue should be discussed now. When a master use bypass mode to access
memory, this means it can access all non-secure memory. So, if a master can
be operated in user mode, that means a user process can access any kernel
memory. In ARM smmu-v2 specification, SMMU_S2CRn.PRIVCFG is used for determine
output priviledge attribute. But if use bypass mode and output attribute is
Unprivileged, specification have no mention about where to decide memory access
is permitted or not. Do you think is a spec design bug or Implemention
defined, or find some description anywhere.

  reply	other threads:[~2014-06-17  7:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12  5:08 [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Zhen Lei
2014-06-12  5:08 ` [PATCH RFC v2 1/3] iommu/arm: Adjust code to facilitate support arm smmu variants Zhen Lei
2014-06-12  5:08 ` [PATCH RFC v2 2/3] iommu/hisilicon: Add support for Hisilicon Ltd. System MMU architecture Zhen Lei
2014-06-12  5:08 ` [PATCH RFC v2 3/3] documentation/iommu: Add description of Hisilicon SMMU private binding Zhen Lei
2014-06-16 16:39   ` Will Deacon
2014-06-17  7:50     ` leizhen [this message]
2014-06-17  9:11       ` Varun Sethi
2014-06-17  9:33       ` Will Deacon
2014-06-18  1:28         ` leizhen
2014-06-18 12:03           ` Varun Sethi
2014-06-18 12:34             ` leizhen
2014-06-18 13:32           ` Will Deacon
2014-06-19  1:58             ` leizhen
2014-06-16 16:37 ` [PATCH RFC v2 0/3] Add support for Hisilicon SMMU architecture Will Deacon
2014-06-17  6:32   ` leizhen
2014-06-17  9:27     ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539FF33C.7020007@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.