Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44 |
|
#
75ed63d9 |
| 28-May-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: clean up Kconfig dependencies on CONFIG_EFI
Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the
efi: clean up Kconfig dependencies on CONFIG_EFI
Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface.
So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment.
Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
9db69df4 |
| 12-May-2022 |
TingHan Shen <tinghan.shen@mediatek.com> |
firmware: mediatek: Add adsp ipc protocol interface
Some of mediatek processors contain the Tensilica HiFix DSP for audio processing.
The communication between Host CPU and DSP firmware is taking p
firmware: mediatek: Add adsp ipc protocol interface
Some of mediatek processors contain the Tensilica HiFix DSP for audio processing.
The communication between Host CPU and DSP firmware is taking place using a shared memory area for message passing.
ADSP IPC protocol offers (send/recv) interfaces using mediatek-mailbox APIs.
We use two mbox channels to implement a request-reply protocol.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Signed-off-by: TingHan Shen <tinghan.shen@mediatek.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Curtis Malainey <cujomalainey@chromium.org> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Reviewed-by: YC Hung <yc.hung@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220512082215.3018-2-tinghan.shen@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65 |
|
#
f6bc909e |
| 13-Sep-2021 |
Simon Trimmer <simont@opensource.cirrus.com> |
firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs
wm_adsp originally provided firmware loading on some audio DSP and was implemented as an ASoC codec driver. However, the
firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs
wm_adsp originally provided firmware loading on some audio DSP and was implemented as an ASoC codec driver. However, the firmware loading now covers a wider range of DSP cores and peripherals containing them, beyond just audio. So it needs to be available to non-audio drivers. All the core firmware loading support has been moved into a new driver cs_dsp, leaving only the ASoC-specific parts in wm_adsp.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210913160057.103842-17-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13 |
|
#
8633ef82 |
| 25-Jun-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
drivers/firmware: consolidate EFI framebuffer setup for all arches
The register_gop_device() function registers an "efi-framebuffer" platform device to match against the efifb driver, to have an ear
drivers/firmware: consolidate EFI framebuffer setup for all arches
The register_gop_device() function registers an "efi-framebuffer" platform device to match against the efifb driver, to have an early framebuffer for EFI platforms.
But there is already support to do exactly the same by the Generic System Framebuffers (sysfb) driver. This used to be only for X86 but it has been moved to drivers/firmware and could be reused by other architectures.
Also, besides supporting registering an "efi-framebuffer", this driver can register a "simple-framebuffer" allowing to use the siple{fb,drm} drivers on non-X86 EFI platforms. For example, on aarch64 these drivers can only be used with DT and doesn't have code to register a "simple-frambuffer" platform device when booting with EFI.
For these reasons, let's remove the register_gop_device() duplicated code and instead move the platform specific logic that's there to sysfb driver.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
show more ...
|
#
d391c582 |
| 25-Jun-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
drivers/firmware: move x86 Generic System Framebuffers support
The x86 architecture has generic support to register a system framebuffer platform device. It either registers a "simple-framebuffer" i
drivers/firmware: move x86 Generic System Framebuffers support
The x86 architecture has generic support to register a system framebuffer platform device. It either registers a "simple-framebuffer" if the config option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device.
But the code is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory.
This will allow to also support the simple{fb,drm} drivers on non-x86 EFI platforms, such as aarch64 where these drivers are only supported with DT.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210625130947.1803678-2-javierm@redhat.com
show more ...
|
#
b42000e4 |
| 06-Jul-2021 |
John Stultz <john.stultz@linaro.org> |
firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM"
firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to ensure that drivers that call into the qcom_scm driver are also built as modules. While not ideal in some cases its the only safe way I can find to avoid build errors without having those drivers select QCOM_SCM and have to force it on (as QCOM_SCM=n can be valid for those drivers).
Reviving this now that Saravana's fw_devlink defaults to on, which should avoid loading troubles seen before.
Acked-by: Kalle Valo <kvalo@codeaurora.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20210707045320.529186-1-john.stultz@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
show more ...
|
Revision tags: v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39 |
|
#
e7818584 |
| 21-May-2021 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_ffa: Add initial FFA bus support for device enumeration
The Arm FF for Armv8-A specification has concept of endpoints or partitions. In the Normal world, a partition could be a VM when
firmware: arm_ffa: Add initial FFA bus support for device enumeration
The Arm FF for Armv8-A specification has concept of endpoints or partitions. In the Normal world, a partition could be a VM when the Virtualization extension is enabled or the kernel itself.
In order to handle multiple partitions, we can create a FFA device for each such partition on a dedicated FFA bus. Similarly, different drivers requiring FFA transport can be registered on the same bus. We can match the device and drivers using UUID. This is mostly for the in-kernel users with FFA drivers.
Link: https://lore.kernel.org/r/20210521151033.181846-2-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
Revision tags: v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
8dc24866 |
| 23-Nov-2020 |
Linus Walleij <linus.walleij@linaro.org> |
Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"
This reverts commit d0511b5496c03cdbcda55a9b57c32cdd751920ed.
After some time it was noticed that the Tegra18
Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"
This reverts commit d0511b5496c03cdbcda55a9b57c32cdd751920ed.
After some time it was noticed that the Tegra186 among others were experiencing problems when making this into a module.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
#
d0511b54 |
| 05-Nov-2020 |
John Stultz <john.stultz@linaro.org> |
firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM"
firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to ensure that drivers that call into the qcom_scm driver are also built as modules. While not ideal in some cases its the only safe way I can find to avoid build errors without having those drivers select QCOM_SCM and have to force it on (as QCOM_SCM=n can be valid for those drivers).
Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Kalle Valo <kvalo@codeaurora.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <maz@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Maulik Shah <mkshah@codeaurora.org> Cc: Lina Iyer <ilina@codeaurora.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-arm-msm@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-gpio@vger.kernel.org Link: https://lore.kernel.org/r/20201106042710.55979-3-john.stultz@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8 |
|
#
66d90f6e |
| 07-Sep-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Enable building as a single module
Now, with all the plumbing in place to enable building scmi as a module instead of built-in modules, let us enable the same.
Link: https://lor
firmware: arm_scmi: Enable building as a single module
Now, with all the plumbing in place to enable building scmi as a module instead of built-in modules, let us enable the same.
Link: https://lore.kernel.org/r/20200907195046.56615-5-sudeep.holla@arm.com Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
Revision tags: v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
f2ae9706 |
| 18-May-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: smccc: Refactor SMCCC specific bits into separate file
In order to add newer SMCCC v1.1+ functionality and to avoid cluttering PSCI firmware driver with SMCCC bits, let us move the SMCCC s
firmware: smccc: Refactor SMCCC specific bits into separate file
In order to add newer SMCCC v1.1+ functionality and to avoid cluttering PSCI firmware driver with SMCCC bits, let us move the SMCCC specific details under drivers/firmware/smccc/smccc.c
We can also drop conduit and smccc_version from psci_operations structure as SMCCC was the sole user and now it maintains those.
No functionality change in this patch though.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-6-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9 |
|
#
9a434cee |
| 07-Jan-2020 |
Elliot Berman <eberman@codeaurora.org> |
firmware: qcom_scm: Dynamically support SMCCC and legacy conventions
Dynamically support SMCCCC and legacy conventions by detecting which convention to use at runtime. qcom_scm_call_atomic and qcom_
firmware: qcom_scm: Dynamically support SMCCC and legacy conventions
Dynamically support SMCCCC and legacy conventions by detecting which convention to use at runtime. qcom_scm_call_atomic and qcom_scm_call can then be moved in qcom_scm.c and use underlying convention backend as appropriate. Thus, rename qcom_scm-64,-32 to reflect that they are backends for -smc and -legacy, respectively.
Also add support for making SCM calls earlier than when SCM driver probes to support use cases such as qcom_scm_set_cold_boot_addr. Support is added by lazily initializing the convention and guarding the query with a spin lock. The limitation of these early SCM calls is that they cannot use DMA, as in the case of >4 arguments for SMC convention and any non-atomic call for legacy convention.
Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-18-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
show more ...
|
#
02248981 |
| 07-Jan-2020 |
Elliot Berman <eberman@codeaurora.org> |
firmware: qcom_scm-32: Use SMC arch wrappers
Use SMC arch wrappers instead of inline assembly.
Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.ne
firmware: qcom_scm-32: Use SMC arch wrappers
Use SMC arch wrappers instead of inline assembly.
Tested-by: Brian Masney <masneyb@onstation.org> # arm32 Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Link: https://lore.kernel.org/r/1578431066-19600-10-git-send-email-eberman@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
show more ...
|
Revision tags: v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
389711b3 |
| 21-Aug-2019 |
Marek Behún <marek.behun@nic.cz> |
firmware: Add Turris Mox rWTM firmware driver
This adds a driver to communicate with the firmware running on the secure processor of the Turris Mox router, enabling the kernel to retrieve true rando
firmware: Add Turris Mox rWTM firmware driver
This adds a driver to communicate with the firmware running on the secure processor of the Turris Mox router, enabling the kernel to retrieve true random numbers from the Entropy Bit Generator and to read some information burned into eFuses when device was manufactured:
and to sign messages with the ECDSA private key burned into each Turris Mox device when manufacturing.
This also adds support to read other information burned into eFuses: - serial number - board version - MAC addresses - RAM size - ECDSA public key (this is not read directly from eFuses, rather it is computed by the firmware as pair to the burned private key)
The source code of the firmware is open source and can be found at https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi
The firmware is also able to, on demand, sign messages with the burned ECDSA private key, but since Linux's akcipher API is not yet stable (and therefore not exposed to userspace via netlink), this functionality is not supported yet.
Link: https://lore.kernel.org/r/20190822014318.19478-3-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
4526ebbc |
| 03-Sep-2019 |
Richard Gong <richard.gong@intel.com> |
firmware: add Intel Stratix10 remote system update driver
The Intel Remote System Update (RSU) driver exposes interfaces access through the Intel Service Layer to user space via sysfs interface. The
firmware: add Intel Stratix10 remote system update driver
The Intel Remote System Update (RSU) driver exposes interfaces access through the Intel Service Layer to user space via sysfs interface. The RSU interfaces report and control some of the optional RSU features on Intel Stratix 10 SoC.
The RSU feature provides a way for customers to update the boot configuration of a Intel Stratix 10 SoC device with significantly reduced risk of corrupting the bitstream storage and bricking the system.
Signed-off-by: Richard Gong <richard.gong@intel.com> Reviewed-by: Alan Tull <atull@kernel.org> Link: https://lore.kernel.org/r/1567516701-26026-3-git-send-email-richard.gong@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
4cb5d9ec |
| 10-Apr-2019 |
Thierry Reding <treding@nvidia.com> |
firmware: Move Trusted Foundations support
Move the Trusted Foundations support out of arch/arm/firmware and into drivers/firmware where most other firmware support implementations are located.
Sig
firmware: Move Trusted Foundations support
Move the Trusted Foundations support out of arch/arm/firmware and into drivers/firmware where most other firmware support implementations are located.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
e720a6c8 |
| 10-Apr-2019 |
Ulf Hansson <ulf.hansson@linaro.org> |
drivers: firmware: psci: Move psci to separate directory
Some following changes extends the PSCI driver with some additional files. Avoid to continue cluttering the toplevel firmware directory and
drivers: firmware: psci: Move psci to separate directory
Some following changes extends the PSCI driver with some additional files. Avoid to continue cluttering the toplevel firmware directory and first move the PSCI files into a PSCI sub-directory.
Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2 |
|
#
7ca5ce89 |
| 13-Nov-2018 |
Richard Gong <richard.gong@intel.com> |
firmware: add Intel Stratix10 service layer driver
Some features of the Intel Stratix10 SoC require a level of privilege higher than the kernel is granted. Such secure features include FPGA programm
firmware: add Intel Stratix10 service layer driver
Some features of the Intel Stratix10 SoC require a level of privilege higher than the kernel is granted. Such secure features include FPGA programming. In terms of the ARMv8 architecture, the kernel runs at Exception Level 1 (EL1), access to the features requires Exception Level 3 (EL3).
The Intel Stratix10 SoC service layer provides an in kernel API for drivers to request access to the secure features. The requests are queued and processed one by one. ARM’s SMCCC is used to pass the execution of the requests on to a secure monitor (EL3).
The header file stratix10-sve-client.h defines the interface between service providers (FPGA manager is one of them) and service layer.
The header file stratix10-smc.h defines the secure monitor call (SMC) message protocols used for service layer driver in normal world (EL1) to communicate with secure monitor SW in secure monitor exception level 3 (EL3).
Signed-off-by: Richard Gong <richard.gong@intel.com> Signed-off-by: Alan Tull <atull@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13 |
|
#
edbee095 |
| 07-Oct-2018 |
Dong Aisheng <aisheng.dong@nxp.com> |
firmware: imx: add SCU firmware driver support
The System Controller Firmware (SCFW) is a low-level system function which runs on a dedicated Cortex-M core to provide power, clock, and resource mana
firmware: imx: add SCU firmware driver support
The System Controller Firmware (SCFW) is a low-level system function which runs on a dedicated Cortex-M core to provide power, clock, and resource management. It exists on some i.MX8 processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
This patch implements the SCU firmware IPC function and the common message sending API sc_call_rpc.
Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Jassi Brar <jassisinghbrar@gmail.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
show more ...
|
Revision tags: v4.18.12, v4.18.11 |
|
#
8e5cddd1 |
| 26-Sep-2018 |
Stuart Hayes <stuart.w.hayes@gmail.com> |
firmware: dcdbas: Move dcdbas to drivers/platform/x86
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Andy
firmware: dcdbas: Move dcdbas to drivers/platform/x86
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
show more ...
|
#
c48e2ffd |
| 26-Sep-2018 |
Stuart Hayes <stuart.w.hayes@gmail.com> |
firmware: dell_rbu: Move dell_rbu to drivers/platform/x86
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by:
firmware: dell_rbu: Move dell_rbu to drivers/platform/x86
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
show more ...
|
Revision tags: v4.18.10, v4.18.9 |
|
#
76582671 |
| 12-Sep-2018 |
Rajan Vaja <rajanv@xilinx.com> |
firmware: xilinx: Add Zynqmp firmware driver
This patch is adding communication layer with firmware. Firmware driver provides an interface to firmware APIs. Interface APIs can be used by any driver
firmware: xilinx: Add Zynqmp firmware driver
This patch is adding communication layer with firmware. Firmware driver provides an interface to firmware APIs. Interface APIs can be used by any driver to communicate to PMUFW(Platform Management Unit). All requests go through ATF.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com> Signed-off-by: Jolly Shah <jollys@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
show more ...
|
Revision tags: v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7 |
|
#
aa4f886f |
| 28-Mar-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add basic driver infrastructure for SCMI
The SCMI is intended to allow OSPM to manage various functions that are provided by the hardware platform it is running on, including pow
firmware: arm_scmi: add basic driver infrastructure for SCMI
The SCMI is intended to allow OSPM to manage various functions that are provided by the hardware platform it is running on, including power and performance functions. SCMI provides two levels of abstraction, protocols and transports. Protocols define individual groups of system control and management messages. A protocol specification describes the messages that it supports. Transports describe the method by which protocol messages are communicated between agents and the platform.
This patch adds basic infrastructure to manage the message allocation, initialisation, packing/unpacking and shared memory management.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
#
ad6eb31e |
| 08-Jan-2018 |
James Morse <james.morse@arm.com> |
firmware: arm_sdei: Add driver for Software Delegated Exceptions
The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS
firmware: arm_sdei: Add driver for Software Delegated Exceptions
The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI.
Add the code for detecting the SDEI version and the framework for registering and unregistering events. Subsequent patches will add the arch-specific backend code and the necessary power management hooks.
Only shared events are supported, power management, private events and discovery for ACPI systems will be added by later patches.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|