Re: Access controllers: differentiate between access checks and grants?

[Gatien CHEVALLIER <gatien.chevallier@foss.st.com>]

Hello,

On 7/4/25 12:41, Ahmad Fatoum wrote:
> Hi Oleksii,
> 
> On 7/4/25 12:07, Oleksii Moisieiev wrote:
>>> Quoting access-controllers.yaml:
>>>
>>>     Access controllers are typically used to set/read the permissions of a
>>>     hardware block and grant access to it.
>>>

To be honest, I would like to separate the "set" permissions aspect from
this property before it's used in too many context because it makes it
impossible to distinguish whether we use this property for setting a
controller configuration in a secure context e.g: TEE at boot and only
granting access to a peripheral.
Granting access may include acquisition of some resources but these
resources should not be the controller configuration itself. Here's an
attempt [1] that did not receive feedback yet to add a dedicated
pattern property for setting configurations.

I'd be grateful if you guys can provide me feedback on this.

>>> I am afraid that having the exact same binding for both granting and
>>> checking accesses complicates matters:
>>>
>>>     1) Harder to reason about device trees: Does this property actually
>>>        modify hardware state or not?
>>   From my standpoint driver should decide this. The main purpose of the
>> device-tree is to provide information, not runtime data.
> 
> It's an aspect of the hardware if a device is accessible or not.
> We have status and secure-status for example for devices strictly
> partitioned for either normal or secure world.
> There is also prior art for restricting usage of nodes, e.g.
> protect-exec for SRAM or read-only for NVMEM.
> 
> So this is not misaligned with existing practice.
> 
>>>     2) More difficult migration: If access granting is added initially to
>>>        Linux, but later moved into the secure world. How to reflect in
>>>        the DT that the access controller has become read-only and that the
>>>        driver should not attempt writes?
>> This sounds to me more as runtime configuration. I mean that in this
>> case we should handle 2 device-trees:
>> - configuration where HW didn't migrate to the Secure World
>> - configuration where read-only access is needed.
> 
> A migrated device tree might still want to describe the access
> controller, e.g. so the probe of devices known to be off limits can be
> skipped. Then we are back at square one of defining a binding on how to
> differentiate between an access controller that does modification and
> one that only does access checks.
> 
>>> My suggestion would be adding an `access-checks-only;` or similar
>>> property for access controllers that are read-only.
>>>
> 
>>> access-checks-only could be that way.
>>>
>> I've taken this example from [1]:
>>             access-controllers = <&aips5
>>                   IMX8MP_AIPSTZ_HIFI4
>>                   IMX8MP_AIPSTZ_MASTER
>>                   (IMX8MP_AIPSTZ_MPL | IMX8MP_AIPSTZ_MTW | IMX8MP_AIPSTZ_MTR)
>>               >;
>> What if just define some *_RO flag and add it for example with u-boot?
>>> Thoughts?
> 
> As extra cell or as value that's OR'd into the last cell with the flags?
> An extra cell would be an option, but I rather think it's a property
> of the controller if it's read-only or not and not of the consumers?
> 

IMO, adding an extra cell (simple boolean value) dedicated to this
purpose for your case is a good idea. The bindings states that it's
used to grant access to a hardware block. Whether the "granting"
process is just checking or having to acquire some resources is up
to each controller. Does that seem fair to you? It should address
both 1) and 2).

> Thanks,
> Ahmad
>

>>>
>>> [1]:
>>> https://lore.kernel.org/all/20250610160152.1113930-1-laurentiumihalcea111@gmail.com/
>>>
>>> Thanks,
>>> Ahmad
>>>
>>>
>>>
>>> --
>>> Pengutronix e.K.                       |                             |
>>> Steuerwalder Str. 21                   | http://www.pengutronix.de/  |
>>> 31137 Hildesheim, Germany              | Phone: +49-5121-206917-0    |
>>> Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-5555 |
>>>
> 

[1]:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250523-access-controllers-conf-v3-1-4382e69819cf@foss.st.com/

(I'm sorry I can't find the kernel lore link even using filters on the
URL)

Best regards,
Gatien