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

[Rob Herring]

On Mon, Aug 10, 2026 at 1:03 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
>
> On 07/08/2026 11:47 pm, Rob Herring wrote:
> > On Fri, Aug 07, 2026 at 04:25:11PM +0100, Peter Griffin wrote:
> >> Hi Will & Robin,
> >>
> >> Thank you both for your review feedback.
> >>
> >> On Mon, 27 Jul 2026 at 11:53, Robin Murphy <robin.murphy@xxxxxxx> 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?
> >
> > Shrug.
> >
> > Really, this is why we want SoC specific compatibles so work-arounds can
> > be added without DT updates. But we've generally avoided doing that for
> > SMMU for whatever reasons. Just make the property clearly sound like a
> > mistake, not a feature you might want to use. I'd keep the arm prefix
> > just so the next vendor thinks they can't use 'google' and creates the
> > same property with their vendor prefix.
>
> I dunno, I'd be inclined to keep it more vendor/SoC-specific and tied to
> the problem more than one (of potentially several) specific workaround -
> if we did ever want to support using the INSTCFG/PRIVCFG/MEMCFG
> overrides per their full architectural intent, they are per-StreamID
> controls so as such would really want to be encoded in an additional
> #iommu-cell (or at worst maybe a property on the client device node).
>
> Frankly for a workaround condition to just blanket-apply to every SMMU
> instance in a particular SoC, I'm honestly thinking that just whacking
> an of_machine_is_compatible() in the driver isn't necessarily the worst
> idea either - after all we do already have the ACPI equivalent of that
> for some of the HiSilicon stuff, it's just hidden in the IORT code (and
> OK it's used for the SMMU PMUs rather than the actual SMMU devices
> themselves, but still...)

Unless we need to avoid a DT update, I'd prefer adding an SoC specific
SMMU compatible which can use match data and avoid DT updates on
future quirks rather than using of_machine_is_compatible(). I view a
driver using of_machine_is_compatible() as a last resort.

Rob