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

[Robin Murphy <robin.murphy@arm.com>]

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@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?
> 
> 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...)

Thanks,
Robin.