Subject: Re: [PATCH 2/3] syscon: add support for "syscon-smc" compatible

On Fri, Jul 23, 2021 at 3:52 PM Clément Léger [off-list ref]
wrote:

quoted

System controllers can be placed under secure monitor control when
running under them. In order to keep existing code which accesses such
system controllers using a syscon, add support for "syscon-smc" compatible.

When enable, the syscon will handle this new compatible and look for
an "arm,smc-id" property to execute the appropriate SMC. A SMC regmap
is then created to forward register access to the secure monitor.

Signed-off-by: Clément Léger <clement.leger@bootlin.com>

I don't see anything wrong with the implementation,

I also vote for such an implementation. Such as we have a chip has a misc
register space, part as below:

44h USB Wake-up Control Register (DGO 10) (USB_WAKEUP) 
48h PTD Pads Compensation Cell Configuration Register
4Ch Lower CA35 TS Timer First Compare Value (TSTMR_CMP0_VAL_L)
50h Upper CA35 TS Timer First Compare Value
54h Lower CA35 TS Timer Second Compare value
58h Upper CA35 TS Timer Second Compare Value
5Ch CA35 Core0 Reset Vector Base Address (DGO 8) (RVBARADDR0) 
60h CA35 Core1 Reset Vector Base Address (DGO 9) (RVBARADDR1) 
64h Medium Quality Sound Configuration Register (MQS1_CF) 32 RW 0100_0000h

It contains several functions, we need protect 5Ch, 60h to avoid
Non-secure world modify it. Others could be directly used by Linux kernel.
But we could only hide the whole register space in secure world to make
5C/60h register not touch by linux.

We not find a good way to provide high-level interface for such
a misc register space, provide register level interface would make
it easy for various drivers to use.

Thanks,
Peng.


but this worries me

conceptually, because of the ways this might get abused:

- this creates one more way to keep device drivers hidden away
  behind firmware when they should be in the kernel. You can already
  do that with separate SMC calls, but adding an indirection makes it
  sneakier. If the 'registers' in here are purely

- This may be seen as an easy way out for firmware writers that just
   expose a bare register-level interface when the correct solution would
   be to create a high-level interface.

There is also a problem with locking: In the case that both firmware and
kernel have to access registers within a syscon area, you may need to have a
semaphore to protect an atomic sequence of accesses, but since the interface
only provides a single register load/store, there is no way for a kernel driver to
serialize against a firmware-internal driver.

        Arnd