Re: [PATCH 16/16] ARM: dts: renesas: r9a06g032: Describe the EIP-150 block

Hello Rob,

Sorry for the late answer.

On 07/04/2026 at 14:33:56 -05, Rob Herring <[email protected]> wrote:

> On Fri, Mar 27, 2026 at 09:09:38PM +0100, Miquel Raynal (Schneider Electric) wrote:
>> The EIP-150 is composed of 3 blocks:
>> * An interrupt controller named EIP-201 AIC
>>     - fed by a clock coming from the EIP-150
>>     - connected to the main GIC
>> * A random number generator named EIP-76
>>     - fed by a clock coming from the EIP-150
>>     - signalling interrupts through the AIC
>> * A public key accelerator engine named EIP-28
>>     - Fed by a clock coming from the EIP-150
>>     - Signalling interrupts through the AIC
>> 
>> Signed-off-by: Miquel Raynal (Schneider Electric) <[email protected]>
>> ---
>>  arch/arm/boot/dts/renesas/r9a06g032.dtsi | 42 ++++++++++++++++++++++++++++++++
>>  1 file changed, 42 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
>> index f4f760aff28b..6aaa93ed03d6 100644
>> --- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
>> +++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
>> @@ -8,6 +8,7 @@
>>  
>>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>>  #include <dt-bindings/clock/r9a06g032-sysctrl.h>
>> +#include <dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h>
>>  
>>  / {
>>  	compatible = "renesas,r9a06g032";
>> @@ -170,6 +171,47 @@ usb@2,0 {
>>  			};
>>  		};
>>  
>> +		eip150: bus@40040000 {
>> +			compatible = "inside-secure,safexcel-eip150", "simple-pm-bus";
>> +			clocks = <&sysctrl R9A06G032_HCLK_CRYPTO_EIP150>;
>> +			#clock-cells = <0>;
>> +			clock-map = <&sysctrl R9A06G032_HCLK_CRYPTO_EIP150>;
>
> I don't get why you need clock-map here. Why can't you just put this 
> clock in each child node?

From a pure fonctional point of view it would work of course, but that's
IMO not an accurate representation of the hardware.

The EIP-150 is a single IP block with one clock input from the SoC
perspective. The children don't have independent wires to the clock
controller (sysctrl). The clock is routed through the container and
distributed internally.

I made the assumption that form a hardware point of view, container
nodes (like the EIP-150) somehow share a close design philosophy with
connectors wrt. the access of the upper resources.

Also, since nexus nodes are an established DT pattern, it felt like we
should bridge the gap on the clock side, hence this proposal.

Can you please confirm whether this is okay to pursue in this path or if
you really think we should stick to a simpler representation?

Thanks,
Miquèl