All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng.Zhang@synaptics.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [Question] vendor-specific cpu enable-method
Date: Thu, 13 Sep 2018 10:29:46 +0800	[thread overview]
Message-ID: <20180913102946.41a43d88@xhacker.debian> (raw)
In-Reply-To: <CAK7LNASWfncdHRkRs=tq=TRaM+KUbb8bcMHMs8LiCgZzuFKCAg@mail.gmail.com>

On Thu, 13 Sep 2018 10:23:35 +0900 Masahiro Yamada wrote:

> Hello.
> 
> 
> Sorry if I am asking a stupid question.
> 
> 
> For arm64, there are only 2 cpu methods, psci and spin-table.
> 
> Why do we still allow vendor-specific methods upstreamed
> for arm 32bit ports?
> 
> To me, it looks like SoC vendors continue inventing
> different (but similar) ways to do the same thing.
> 
> It is a historical reason for old platforms.
> 
> However, if I look at Documentation/devicetree/bindings/arm/cpus.txt
> enable-method properties are still increasing.
> 
> 
> psci is available in arch/arm/kernel/psci_smp.c,
> but not all SoCs support the security extension.
> Is there a simpler one like spin-table available for arm32?

Per my understanding, spin-table is similar as the "pen" based
solution in arm32, both can't reliably support kexec, suspend etc...

> 
> If we force generic methods like psci or spin-table
> for new platforms, we can stop proliferated smp code.
> (Of course, we are just shifting the complexity
> from the kernel to firmware.)

psci is good but not all SoCs support secure extensions. spin-table
can't support kexec, suspend. Except prefer psci for news SoCs
with secure extensions, no better solutions AFAIK.

WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Olof Johansson <olof@lixom.net>, Rob Herring <robh+dt@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Question] vendor-specific cpu enable-method
Date: Thu, 13 Sep 2018 10:29:46 +0800	[thread overview]
Message-ID: <20180913102946.41a43d88@xhacker.debian> (raw)
In-Reply-To: <CAK7LNASWfncdHRkRs=tq=TRaM+KUbb8bcMHMs8LiCgZzuFKCAg@mail.gmail.com>

On Thu, 13 Sep 2018 10:23:35 +0900 Masahiro Yamada wrote:

> Hello.
> 
> 
> Sorry if I am asking a stupid question.
> 
> 
> For arm64, there are only 2 cpu methods, psci and spin-table.
> 
> Why do we still allow vendor-specific methods upstreamed
> for arm 32bit ports?
> 
> To me, it looks like SoC vendors continue inventing
> different (but similar) ways to do the same thing.
> 
> It is a historical reason for old platforms.
> 
> However, if I look at Documentation/devicetree/bindings/arm/cpus.txt
> enable-method properties are still increasing.
> 
> 
> psci is available in arch/arm/kernel/psci_smp.c,
> but not all SoCs support the security extension.
> Is there a simpler one like spin-table available for arm32?

Per my understanding, spin-table is similar as the "pen" based
solution in arm32, both can't reliably support kexec, suspend etc...

> 
> If we force generic methods like psci or spin-table
> for new platforms, we can stop proliferated smp code.
> (Of course, we are just shifting the complexity
> from the kernel to firmware.)

psci is good but not all SoCs support secure extensions. spin-table
can't support kexec, suspend. Except prefer psci for news SoCs
with secure extensions, no better solutions AFAIK.

  reply	other threads:[~2018-09-13  2:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13  1:23 [Question] vendor-specific cpu enable-method Masahiro Yamada
2018-09-13  1:23 ` Masahiro Yamada
2018-09-13  2:29 ` Jisheng Zhang [this message]
2018-09-13  2:29   ` Jisheng Zhang
2018-09-14  8:37   ` Masahiro Yamada
2018-09-14  8:37     ` Masahiro Yamada

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20180913102946.41a43d88@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.