linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] iommu/arm-smmu: Support buggy implemenations where all config accesses are secure
Date: Wed, 2 Oct 2013 11:44:47 +0100	[thread overview]
Message-ID: <20131002104447.GE28311@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20131001181709.GZ3315@alberich>

On Tue, Oct 01, 2013 at 07:17:09PM +0100, Andreas Herrmann wrote:
> On Tue, Oct 01, 2013 at 09:28:51AM -0400, Rob Herring wrote:
> > On 10/01/2013 07:39 AM, Andreas Herrmann wrote:
> > > In such a case we have to use secure aliases of some non-secure
> > > registers.
> > > 
> > > This behaviour is controlled via a flag in smmu->bugs. It is set
> > > based on DT information when probing an SMMU device.
> > 
> > Perhaps quirks would be a nicer word...
> 
> In fact it might be better to rename this as "options".
> For device isolation I had added a flag to indicate this in
> smmu->features.
> But it might be better to not mix hardware features with software
> features or options.

Yes, I also didn't like the mixing of hardware and software features, but I
couldn't think of a good way to separate them out. Sounds like you might be
on to something.

> So what do you (Will and Rob) think about a change like
> 
>  struct arm_smmu_device {
>    ...
> 
>  #define ARM_SMMU_FEAT_COHERENT_WALK     (1 << 0)
>  #define ARM_SMMU_FEAT_STREAM_MATCH      (1 << 1)
>  #define ARM_SMMU_FEAT_TRANS_S1          (1 << 2)
>  #define ARM_SMMU_FEAT_TRANS_S2          (1 << 3)
>  #define ARM_SMMU_FEAT_TRANS_NESTED      (1 << 4)
>          u32                             features;
> + #define ARM_SMMU_OPT_SECURE_CFG_ACCESS  (1 << 0)
> + #define ARM_SMMU_OPT_ISOLATE_DEVICES    (1 << 1)
> +        u32                             options;
>          int                             version;

I'm ok with this change, but it gets you guys off the hook with your broken
integration!

>    ...
>  }
> 
> DT property "calxeda,smmu-secure-cfg-access" would set
> ARM_SMMU_OPT_SECURE_CFG_ACCESS and
> DT property "linux,arm-smmu-isolate-devices" would set
> ARM_SMMU_OPT_ISOLATE_DEVICES.
> 
> (Maybe in future there will be more driver options. )

Yeah, and you could probably go all out with macros to generate this stuff
based on compatible string and OPT #define too.

Will

  reply	other threads:[~2013-10-02 10:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01 12:39 [PATCH 0/6] iommu/arm-smmu: Misc changes Andreas Herrmann
2013-10-01 12:39 ` [PATCH 1/6] iommu/arm-smmu: Switch to subsys_initcall for driver registration Andreas Herrmann
2013-10-01 12:39 ` [PATCH 2/6] iommu/arm-smmu: Refine check for proper size of mapped region Andreas Herrmann
2013-10-01 12:39 ` [PATCH 3/6] iommu/arm-smmu: Check for num_context_irqs > 0 to avoid divide by zero exception Andreas Herrmann
2013-10-01 12:39 ` [PATCH 4/6] iommu/arm-smmu: Print context fault information Andreas Herrmann
2013-10-01 12:39 ` [PATCH 5/6] iommu/arm-smmu: Clear global and context bank fault status registers Andreas Herrmann
2013-10-01 12:39 ` [PATCH 6/6] iommu/arm-smmu: Support buggy implemenations where all config accesses are secure Andreas Herrmann
2013-10-01 13:28   ` Rob Herring
2013-10-01 18:17     ` Andreas Herrmann
2013-10-02 10:44       ` Will Deacon [this message]
2013-10-01 15:50 ` [PATCH 0/6] iommu/arm-smmu: Misc changes Will Deacon
2013-10-01 18:20   ` Andreas Herrmann

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=20131002104447.GE28311@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).