* [Question] vendor-specific cpu enable-method @ 2018-09-13 1:23 ` Masahiro Yamada 0 siblings, 0 replies; 6+ messages in thread From: Masahiro Yamada @ 2018-09-13 1:23 UTC (permalink / raw) To: linux-arm-kernel 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? 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.) Am I missing something? -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Question] vendor-specific cpu enable-method @ 2018-09-13 1:23 ` Masahiro Yamada 0 siblings, 0 replies; 6+ messages in thread From: Masahiro Yamada @ 2018-09-13 1:23 UTC (permalink / raw) To: linux-arm-kernel Cc: Russell King, Olof Johansson, Arnd Bergmann, Rob Herring, Linux Kernel Mailing List 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? 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.) Am I missing something? -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Question] vendor-specific cpu enable-method 2018-09-13 1:23 ` Masahiro Yamada @ 2018-09-13 2:29 ` Jisheng Zhang -1 siblings, 0 replies; 6+ messages in thread From: Jisheng Zhang @ 2018-09-13 2:29 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] vendor-specific cpu enable-method @ 2018-09-13 2:29 ` Jisheng Zhang 0 siblings, 0 replies; 6+ messages in thread From: Jisheng Zhang @ 2018-09-13 2:29 UTC (permalink / raw) To: Masahiro Yamada Cc: linux-arm-kernel, Olof Johansson, Rob Herring, Russell King, Arnd Bergmann, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Question] vendor-specific cpu enable-method 2018-09-13 2:29 ` Jisheng Zhang @ 2018-09-14 8:37 ` Masahiro Yamada -1 siblings, 0 replies; 6+ messages in thread From: Masahiro Yamada @ 2018-09-14 8:37 UTC (permalink / raw) To: linux-arm-kernel Hi. 2018-09-13 11:29 GMT+09:00 Jisheng Zhang <Jisheng.Zhang@synaptics.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... Right. spin-table is based on pen-based implementation, and just a back-up plan in case psci is not available for some reasons. >> >> 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. OK, psci is preferred if it is available. Otherwise, ... vendor specific code. Thanks. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Question] vendor-specific cpu enable-method @ 2018-09-14 8:37 ` Masahiro Yamada 0 siblings, 0 replies; 6+ messages in thread From: Masahiro Yamada @ 2018-09-14 8:37 UTC (permalink / raw) To: Jisheng Zhang Cc: linux-arm-kernel, Olof Johansson, Rob Herring, Russell King, Arnd Bergmann, Linux Kernel Mailing List Hi. 2018-09-13 11:29 GMT+09:00 Jisheng Zhang <Jisheng.Zhang@synaptics.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... Right. spin-table is based on pen-based implementation, and just a back-up plan in case psci is not available for some reasons. >> >> 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. OK, psci is preferred if it is available. Otherwise, ... vendor specific code. Thanks. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-14 8:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2018-09-13 2:29 ` Jisheng Zhang 2018-09-14 8:37 ` Masahiro Yamada 2018-09-14 8:37 ` Masahiro Yamada
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.