archive mirror
 help / color / mirror / Atom feed
From: "Peng Fan (OSS)" <>
To: "Arnd Bergmann" <>,
	"Clément Léger" <>
Cc: Lee Jones <>,
	Rob Herring <>, Mark Brown <>,
	Greg Kroah-Hartman <>,
	"Rafael J. Wysocki" <>,
	DTML <>,
	Linux Kernel Mailing List <>,
	Sudeep Holla <>,
	Alexandre Belloni <>
Subject: RE: [PATCH 2/3] syscon: add support for "syscon-smc" compatible
Date: Sat, 24 Jul 2021 12:36:27 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> 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 <>
> 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 <>
> 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.


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

  parent reply	other threads:[~2021-07-24 12:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 13:52 [PATCH 0/3] add SMC based regmap driver for secure syscon access Clément Léger
2021-07-23 13:52 ` [PATCH 1/3] regmap: add regmap using ARM SMCCC Clément Léger
2021-07-23 14:43   ` Mark Brown
2021-07-23 15:53     ` Clément Léger
2021-07-23 16:37       ` Mark Brown
2021-07-23 13:52 ` [PATCH 2/3] syscon: add support for "syscon-smc" compatible Clément Léger
2021-07-23 15:27   ` Lee Jones
2021-07-23 15:56     ` Clément Léger
2021-07-23 16:07   ` Arnd Bergmann
2021-07-23 16:41     ` Mark Brown
2021-07-24 12:36     ` Peng Fan (OSS) [this message]
2021-07-24  7:00   ` kernel test robot
2021-07-23 13:52 ` [PATCH 3/3] dt-bindings: mfd: add "syscon-smc" YAML description Clément Léger
2021-07-29 21:19   ` Rob Herring
2021-07-30  7:21     ` Clément Léger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).