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
next prev parent 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).