[PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits

[Marek Vasut]

On 2/20/20 3:02 AM, Ang, Chee Hong wrote:
[...]
>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
>>> +u32 socfpga_secure_reg_read32(phys_addr_t reg_addr); void
>>> +socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr); void
>>> +socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val);
>>> +#else
>>> +#define socfpga_secure_reg_read32	readl
>>> +#define socfpga_secure_reg_write32	writel
>>> +#define socfpga_secure_reg_update32	clrsetbits_le32
>>> +#endif
>>
>> I think I don't understand how this is supposed to work. Would every place in U-
>> Boot have to be patched to call these functions now ?
> 
> Not every register access need this. Only those accessing registers in secure zone such
> as 'System Manager' registers need to call this. It's basically determine whether the driver
> should issue SMC/PSCI call if it's running in EL2 (non-secure) or access the registers directly
> by simply using readl/writel and etc if it's running in EL3 (secure).
> Accessing those registers in secure zone in non-secure mode (EL2) will cause SError exception.
> So we can determine this behaviour in compile time:
> SPL always running in EL3. So it just simply fallback to use readl/writel/clrsetbits_le32.
> 
> For U-Boot proper (SSBL), there are 2 scenarios:
> 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies that U-Boot proper will be
> running in EL2 (non-secure), then it will use SMC/PSCI calls to access the secure registers.
> 
> 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will be running in EL3 which
> will fall back to simply using the direct access functions (readl/writel and etc).

I would expect the standard IO accessors would or should handle this stuff ?