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

["Peng Fan (OSS)" <peng.fan@oss.nxp.com>]

> 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 <clement.leger@bootlin.com>
> wrote:
> >
> > 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