mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-10-28 20:03:05 +00:00
No description
- C 96.8%
- Assembly 0.9%
- Rust 0.7%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
f938b29d27
The main addition is a unified userspace interface for SCMI irrespective
of the underlying transport and along with some changed to refactor the
SCMI stack probing sequence.
1. SCMI unified userspace interface
This is to have a unified way of testing an SCMI platform firmware
implementation for compliance, fuzzing etc., from the perspective of
the non-secure OSPM irrespective of the underlying transport supporting
SCMI. It is just for testing/development and not a feature intended fo
use in production.
Currently an SCMI Compliance Suite[1] can only work by injecting SCMI
messages using the mailbox test driver only which makes it transport
specific and can't be used with any other transport like virtio,
smc/hvc, optee, etc. Also the shared memory can be transport specific
and it is better to even abstract/hide those details while providing
the userspace access. So in order to scale with any transport, we need
a unified interface for the same.
In order to achieve that, SCMI "raw mode support" is being added through
debugfs which is more configurable as well. A userspace application
can inject bare SCMI binary messages into the SCMI core stack; such
messages will be routed by the SCMI regular kernel stack to the backend
platform firmware using the configured transport transparently. This
eliminates the to know about the specific underlying transport
internals that will be taken care of by the SCMI core stack itself.
Further no additional changes needed in the device tree like in the
mailbox-test driver.
[1] https://gitlab.arm.com/tests/scmi-tests
2. Refactoring of the SCMI stack probing sequence
On some platforms, SCMI transport can be provide by OPTEE/TEE which
introduces certain dependency in the probe ordering. In order to address
the same, the SCMI bus is split into its own module which continues to
be initialized at subsys_initcall, while the SCMI core stack, including
its various transport backends (like optee, mailbox, virtio, smc), is
now moved into a separate module at module_init level.
This allows the other possibly dependent subsystems to register and/or
access SCMI bus well before the core SCMI stack and its dependent
transport backends.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmPKvdkACgkQAEG6vDF+
4pgB0g//eU5S0aTgt8XlwDmdjeu+mNrj68QHKINq9CS7PmBs37So0IdLJ+CpqJlo
VSmk2kI5oLWz/u3N92QQY9RXM4hvO95kiPKuyO8NsoPWrfjBZH3rKcgEpRquZjrt
TdBUPd2aqoKhFqkUzxs5lNEZOV/R6mm0q+i9dD4RIRKP9Tjrlm3jYDSMFnW3/QMJ
OR3Ub0e/4Lj3QyNUxrUqwpdjTiAqXimCW7LWZ2fwY5kPxcL4wedAfQS3zGa5m8Wk
htqRTXmYtSVKAZ/oFUPDOHuZUNqn0ZdNI7guEPgzo90+pJs0yQUQf/wtc+X9quXZ
/FUGaVSTzlvcl1MPJPTPQ9d7dJH8lR0+nxzovkBSoMX/tNByuVtBUpNiclu8seob
CqbywRtASkd0g6dKHHEIylwj0FpRSYBLJEcE6jXhxfvXt+sCDZbDSUpWaGGZnNqO
oj8FhEmRk/t/d+ZEkn6MlRgy5uiJSv4GstNQ5V/ZSz3vhp1u2Sl7y8xAcuVsqXyH
Dok6iM9GoSdskCdSICk5iA2ESC5s+1IiDd2PnSwWz+yj9HbmWKwU0nKgRRWvDUZh
jJYWAvcwuh3SQ/sN/FNTVsxQt/x5V3L/K7oe2o983l0Lq8k9WB0mEBAyRidxAlVj
TpfXbe9CDqJtoF85Bslb7eS++iGADkVvmWAqjqUQddFQR++Dj2w=
=yLSu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmPQQ0QACgkQmmx57+YA
GNlYsRAAr/qGRRSiOtTYZi0yPmSuGCYb4xORbJHS00gD3aRzrehtsf//av4WyeyM
cGpeR/2OIa66/M7wIjKM7lHXBdzFxLgwAM9DkexVwY1i7w6ExDZFClX7UhlgmwiM
LbsApqHYW/DhAnOBL7SXPQkDIcTifURvOZCOJ0NJg5HOn+DeRP5UPEE5Xbqt0+yc
JUnKC2eqN15G/BWJCWtmfZVXwMKtWB8ScU2HJeoEjjH7d31XvWvw5z0upyhlEQvb
lqhFgKftEY+boEfbz86AoZoBY8EWFdqB8RvcNOmReU8hyequjnrK/ykQq9EAAMmo
LbxNkW72zN727ji3O7onX8zWjqYLKjV3FC/cuNah//USQa8nPvq4atXf+D7my0fC
Rm9ZF3ztHQjTgMVlmm/uAU3c4BxEcwHMnppEoYvxa23ErSt+hp2aJvfDfseMAYFW
2iie4KAR03WeHnspYioa88PHj83SeT9AsHxf+PCdXkXgzl74HDVrt/8gpLQMmu4Q
BTkwTF3QvEry5c6uF7yI/oOuQq06Y03miN5GEQKtqTIIpn3g/tJs0GJot0nUPZ0f
xJJ+mlOcoc76zwaDARcGJO0yzX9qJt4I+/HS39BLvMt2EfbZ3IXlSsQu7esd5p2V
6xokmygD5rZY92CMd3SPpJ4xRBHUN6PIFb1GUyJmg9xoghDwjXs=
=jvm3
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v6.3
The main addition is a unified userspace interface for SCMI irrespective
of the underlying transport and along with some changed to refactor the
SCMI stack probing sequence.
1. SCMI unified userspace interface
This is to have a unified way of testing an SCMI platform firmware
implementation for compliance, fuzzing etc., from the perspective of
the non-secure OSPM irrespective of the underlying transport supporting
SCMI. It is just for testing/development and not a feature intended fo
use in production.
Currently an SCMI Compliance Suite[1] can only work by injecting SCMI
messages using the mailbox test driver only which makes it transport
specific and can't be used with any other transport like virtio,
smc/hvc, optee, etc. Also the shared memory can be transport specific
and it is better to even abstract/hide those details while providing
the userspace access. So in order to scale with any transport, we need
a unified interface for the same.
In order to achieve that, SCMI "raw mode support" is being added through
debugfs which is more configurable as well. A userspace application
can inject bare SCMI binary messages into the SCMI core stack; such
messages will be routed by the SCMI regular kernel stack to the backend
platform firmware using the configured transport transparently. This
eliminates the to know about the specific underlying transport
internals that will be taken care of by the SCMI core stack itself.
Further no additional changes needed in the device tree like in the
mailbox-test driver.
[1] https://gitlab.arm.com/tests/scmi-tests
2. Refactoring of the SCMI stack probing sequence
On some platforms, SCMI transport can be provide by OPTEE/TEE which
introduces certain dependency in the probe ordering. In order to address
the same, the SCMI bus is split into its own module which continues to
be initialized at subsys_initcall, while the SCMI core stack, including
its various transport backends (like optee, mailbox, virtio, smc), is
now moved into a separate module at module_init level.
This allows the other possibly dependent subsystems to register and/or
access SCMI bus well before the core SCMI stack and its dependent
transport backends.
* tag 'scmi-updates-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (31 commits)
firmware: arm_scmi: Clarify raw per-channel ABI documentation
firmware: arm_scmi: Add per-channel raw injection support
firmware: arm_scmi: Add the raw mode co-existence support
firmware: arm_scmi: Call raw mode hooks from the core stack
firmware: arm_scmi: Reject SCMI drivers when configured in raw mode
firmware: arm_scmi: Add debugfs ABI documentation for raw mode
firmware: arm_scmi: Add core raw transmission support
firmware: arm_scmi: Add debugfs ABI documentation for common entries
firmware: arm_scmi: Populate a common SCMI debugfs root
debugfs: Export debugfs_create_str symbol
include: trace: Add platform and channel instance references
firmware: arm_scmi: Add internal platform/channel identifiers
firmware: arm_scmi: Move errors defs and code to common.h
firmware: arm_scmi: Add xfer helpers to provide raw access
firmware: arm_scmi: Add flags field to xfer
firmware: arm_scmi: Refactor scmi_wait_for_message_response
firmware: arm_scmi: Refactor polling helpers
firmware: arm_scmi: Refactor xfer in-flight registration routines
firmware: arm_scmi: Split bus and driver into distinct modules
firmware: arm_scmi: Introduce a new lifecycle for protocol devices
...
Link: https://lore.kernel.org/r/20230120162152.1438456-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
History
|
|
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.