[PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature

[Daniel Mentz]

On Fri, Aug 7, 2026 at 8:25 AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Hi Will & Robin,
>
> Thank you both for your review feedback.
>
> On Mon, 27 Jul 2026 at 11:53, Robin Murphy <robin.murphy at arm.com> wrote:
> >
> > On 26/07/2026 2:16 pm, Will Deacon wrote:
> > > On Fri, Jul 24, 2026 at 01:39:41PM +0100, Peter Griffin wrote:
> > >> These two patches add support for a new "arm,instdata-override" DT property
> > >> that enables the override of the instruction/data attribute of incoming
> > >> traffic to Data by setting the INSTCFG override bits.
> > >>
> > >> It is intended to be specified when the smmu can't guarantee that these
> > >> attributes are provided correctly from the client device.
> > >
> > > This is going to need an in-tree user and a much more detailed
> > > description of what is being worked around before we consider this for
> > > inclusion.
>
> Regarding an in-tree user, I haven't sent the Device Tree (DT) patch
> yet for Laguna SoC which adds the smmu nodes and this property because
> 1) I want to land the initial SoC/board DT first
> 2) I want agreement on the DT property name. Currently I used
> "arm,instdata-override" which is what downstream used. However, since
> this is intended to work around silicon errata something like
> "google,lga-instcfg-data-override" might be more appropriate?
>
> For Laguna SoC the first in-tree user of this is the amb_smmu smmu
> instance which is used by the Synopsis dwc3 IP. The Laguna dwc3 glue
> driver is already upstream at drivers/usb/dwc3/dwc3-google.c
>
> > >
> > > In particular, if a particular client is emitting data reads as
> > > instructions, then a better work around would be to avoid mapping its
> > > domains using IOMMU_NOEXEC. But I can't tell what's going on from the
> > > limited description provided here.
> >
> > Unless it's also emitting the privileged bit and thus falling foul of
> > the implicit Unpriv-W -> Priv-XN rule, but then we also have the means
> > to deal with devices which actually do that themselves (hello pl330...),
> > so that would seemingly only leave the case of some innocent piece of
> > AMBA-interfaced IP which doesn't expect to need special attributes, but
> > the system integrator has gone out of their way to tie the AxPROT bits
> > to some wacky value, which I would put in "erratum workaround" territory.
> >
>
> You're correct Robin. It is an erratum workaround for the Laguna SoC
> due to some custom usage of the AxPROT bits which differs from the
> standard ARM SMMU handling for Privileged/Unprivileged and
> Instruction/Data transaction attributes. The effect is all
> transactions appear to the SMMU as "Privileged Instruction" accesses.
> The software workaround in this series enables the SMMU's INSTCFG
> override feature to ignore the incoming value and treat all SMMU
> transactions as "Data".

Due to the specific integration of the MMU-700 in this system,
AxPROT[2] is always 1 on all TBU subordinate interfaces, regardless of
whether the transaction is an instruction or data transaction.
Consequently, client devices have no control over AxPROT[2] on the
input side of SMMU. AxPROT[0] (privileged vs. unprivileged) remains
unaffected. As Robin suggested, the override is required to avoid
inadvertently triggering F_PERMISSION faults due to the VMSAv8-64
requirement that EL0-writable regions are treated as Privileged
Execute-Never (PXN)

Drivers are already avoiding IOMMU_NOEXEC. I prefer handling this via
the SMMU configuration rather than patching individual client drivers,
as this is an integration issue, not a client device issue.