#
5b4d995d |
| 12-Feb-2024 |
Thomas Zimmermann <tzimmermann@suse.de> |
video: Add helpers for decoding screen_info
[ Upstream commit 75fa9b7e375e35739663cde0252d31e586c6314a ]
The plain values as stored in struct screen_info need to be decoded before being used. Add h
video: Add helpers for decoding screen_info
[ Upstream commit 75fa9b7e375e35739663cde0252d31e586c6314a ]
The plain values as stored in struct screen_info need to be decoded before being used. Add helpers that decode the type of video output and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but only indicate the presence by storing 0x01 in orig_video_isVGA. The decoding logic in screen_info_video_type() takes this into account. It then follows similar code in vgacon's vgacon_startup() to detect the video type from the given values.
A call to screen_info_resources() returns all known resources of the given screen_info. The resources' values have been taken from existing code in vgacon and vga16fb. These drivers can later be converted to use the new interfaces.
v2: * return ssize_t from screen_info_resources() * don't call __screen_info_has_lfb() unnecessarily
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-2-tzimmermann@suse.de Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
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 ...
|
#
8b766b0f |
| 25-Feb-2022 |
Michal Suchanek <msuchanek@suse.de> |
sysfb: Enable boot time VESA graphic mode selection
Since switch to simplefb/simpledrm VESA graphic mode selection with vga= kernel parameter is no longer available with legacy BIOS.
The x86 realmo
sysfb: Enable boot time VESA graphic mode selection
Since switch to simplefb/simpledrm VESA graphic mode selection with vga= kernel parameter is no longer available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option FB_BOOT_VESA_SUPPORT is enabled.
This option is selected by vesafb but not simplefb/simpledrm.
To enable use of VESA modes with simplefb in legacy BIOS boot mode drop dependency of BOOT_VESA_SUPPORT on FB, also drop the FB_ prefix. Select the option from sysfb rather than the drivers that depend on it.
The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86 platform, move it from fbdev to x86 Kconfig.
Fixes: e3263ab389a7 ("x86: provide platform-devices for boot-framebuffers") Signed-off-by: Michal Suchanek <msuchanek@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/948c39940a4e99f5b43bdbcbe537faae71a43e1d.1645822213.git.msuchanek@suse.de
show more ...
|
#
a4a072d9 |
| 25-Feb-2022 |
Michal Suchanek <msuchanek@suse.de> |
sysfb: Make config option dependencies explicit
efifb and vesafb requires sysfb implicitly but this is not stated in Kconfig. Add the dependency.
With that all drivers that require sysfb depend on
sysfb: Make config option dependencies explicit
efifb and vesafb requires sysfb implicitly but this is not stated in Kconfig. Add the dependency.
With that all drivers that require sysfb depend on it so it can default to disabled.
Signed-off-by: Michal Suchanek <msuchanek@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/a0fa41e9186653e4c41ad0a28259e5cdc71b1f66.1645822213.git.msuchanek@suse.de
show more ...
|
#
dc4e8c07 |
| 27-Feb-2022 |
Shuai Xue <xueshuai@linux.alibaba.com> |
ACPI: APEI: explicit init of HEST and GHES in apci_init()
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to m
ACPI: APEI: explicit init of HEST and GHES in apci_init()
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage the estatus memory pool. On the other hand, ghes_init() relies on sdei_init() to detect the SDEI version and (un)register events. The dependencies are as follows:
ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init() ghes_init() => sdei_init()
HEST is not PCI-specific and initcall ordering is implicit and not well-defined within a level.
Based on above, remove acpi_hest_init() from acpi_pci_root_init() and convert ghes_init() and sdei_init() from initcalls to explicit calls in the following order:
acpi_hest_init() ghes_init() sdei_init()
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
424953cf |
| 28-Sep-2021 |
Arnd Bergmann <arnd@arndb.de> |
qcom_scm: hide Kconfig symbol
Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in:
aarch64-linux-ld: drivers/net/ipa/
qcom_scm: hide Kconfig symbol
Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'
ld.lld: error: undefined symbol: qcom_scm_is_available >>> referenced by adreno_gpu.c >>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in archive drivers/built-in.a
This can happen when CONFIG_ARCH_QCOM is disabled and we don't select QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd use a similar dependency here to what we have for QCOM_RPROC_COMMON, but that causes dependency loops from other things selecting QCOM_SCM.
This appears to be an endless problem, so try something different this time:
- CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' but that is simply selected by all of its users
- All the stubs in include/linux/qcom_scm.h can go away
- arm-smccc.h needs to provide a stub for __arm_smccc_smc() to allow compile-testing QCOM_SCM on all architectures.
- To avoid a circular dependency chain involving RESET_CONTROLLER and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement. According to my testing this still builds fine, and the QCOM platform selects this symbol already.
Acked-by: Kalle Valo <kvalo@codeaurora.org> Acked-by: Alex Elder <elder@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
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 ...
|
#
e8419c24 |
| 03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make SCMI transports configurable
Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack.
Mailbox and SMC are by default en
firmware: arm_scmi: Make SCMI transports configurable
Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack.
Mailbox and SMC are by default enabled if their related dependencies are satisfied.
While doing that move all SCMI related config options in their own dedicated submenu.
Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
#
71260b9a |
| 27-Jul-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
drivers/firmware: fix SYSFB depends to prevent build failures
The Generic System Framebuffers support is built when the COMPILE_TEST option is enabled. But this wrongly assumes that all the architec
drivers/firmware: fix SYSFB depends to prevent build failures
The Generic System Framebuffers support is built when the COMPILE_TEST option is enabled. But this wrongly assumes that all the architectures declare a struct screen_info.
This is true for most architectures, but at least the following do not: arc, m68k, microblaze, openrisc, parisc and s390.
By attempting to make this compile testeable on all architectures, it leads to linking errors as reported by the kernel test robot for parisc:
All errors (new ones prefixed by >>):
hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': (.init.text+0x24): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info'
To prevent these errors only allow sysfb to be built on systems that are going to need it, which are x86 BIOS and EFI.
The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because some of these architectures only declare a struct screen_info if EFI is enabled. And also, because the SYSFB code is only used for EFI on these architectures. For !EFI the "simple-framebuffer" device is registered by OF when parsing the Device Tree Blob (if a DT node for this was defined).
Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210727093015.1225107-1-javierm@redhat.com
show more ...
|
#
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 ...
|
#
c05b0796 |
| 21-May-2021 |
Etienne Carriere <etienne.carriere@linaro.org> |
firmware: arm_scmi: Add SMCCC discovery dependency in Kconfig
ARM_SCMI_PROTOCOL depends on either MAILBOX or HAVE_ARM_SMCCC_DISCOVERY, not MAILBOX alone. Fix the depedency in Kconfig file and driver
firmware: arm_scmi: Add SMCCC discovery dependency in Kconfig
ARM_SCMI_PROTOCOL depends on either MAILBOX or HAVE_ARM_SMCCC_DISCOVERY, not MAILBOX alone. Fix the depedency in Kconfig file and driver to reflect the same.
Link: https://lore.kernel.org/r/20210521134055.24271-1-etienne.carriere@linaro.org Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> [sudeep.holla: Minor tweaks to subject and change log] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
#
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 ...
|
#
2954a6f1 |
| 06-Apr-2021 |
He Ying <heying24@huawei.com> |
firmware: qcom-scm: Fix QCOM_SCM configuration
When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows:
drivers/firmware/qcom_scm-smc.o: In funct
firmware: qcom-scm: Fix QCOM_SCM configuration
When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows:
drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk': qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call': qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic': qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc'
Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration.
Fixes: 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
38ad957b |
| 21-Mar-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
firmware: stratix10-svc: build only on 64-bit ARM
The Stratix10 service layer and RCU drivers are useful only on Stratix10, so on ARMv8. Compile testing the RCU driver on 32-bit ARM fails:
drive
firmware: stratix10-svc: build only on 64-bit ARM
The Stratix10 service layer and RCU drivers are useful only on Stratix10, so on ARMv8. Compile testing the RCU driver on 32-bit ARM fails:
drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback': include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_179' declared with attribute error: FIELD_GET: type of reg too small for mask _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ... drivers/firmware/stratix10-rsu.c:96:26: note: in expansion of macro 'FIELD_GET' priv->status.version = FIELD_GET(RSU_VERSION_MASK,
Fixes: 4483397b0353 ("ARM: socfpga: drop ARCH_SOCFPGA") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reported-by: kernel test robot <lkp@intel.com> Acked-by: Richard Gong <richard.gong@linux.intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> --- v2: add Fixes tag
show more ...
|
#
4a9a1a56 |
| 11-Mar-2021 |
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> |
arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGA
Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and SoC-part. Up to a point that N5X uses the same DTSI as Agilex.
arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGA
Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and SoC-part. Up to a point that N5X uses the same DTSI as Agilex. From the Linux kernel point of view these are flavors of the same architecture so there is no need for three top-level arm64 architectures. Simplify this by merging all three architectures into ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries.
The side effect is that the INTEL_STRATIX10_SERVICE will now be available for both 32-bit and 64-bit Intel SoCFPGA, even though it is used only for 64-bit.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
show more ...
|
#
54da51a8 |
| 04-Dec-2020 |
Colin Ian King <colin.king@canonical.com> |
firmware: fix a spelling mistake "managament" -> "management" in Kconfig
There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Link:
firmware: fix a spelling mistake "managament" -> "management" in Kconfig
There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201204192250.1151316-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6b698713 |
| 29-Aug-2020 |
Helge Deller <deller@gmx.de> |
fw_cfg: Add support for parisc architecture
Signed-off-by: Helge Deller <deller@gmx.de>
|
#
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 ...
|
#
83a06a10 |
| 29-Jun-2020 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk"
This reverts commit c65822fef4adc0ba40c37a47337376ce75f7a7bc.
The initialization of Raspberry Pi 4's USB chip is now handled through a reset contr
Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk"
This reverts commit c65822fef4adc0ba40c37a47337376ce75f7a7bc.
The initialization of Raspberry Pi 4's USB chip is now handled through a reset controller. No need to directly call the firmware routine through a PCI quirk.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20200629161845.6021-7-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e5bfb21d |
| 18-May-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
SMCCC v1.0 lacked discoverability of version and features. To accelerate adoption of few mitigations and protect system
firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
SMCCC v1.0 lacked discoverability of version and features. To accelerate adoption of few mitigations and protect systems more rapidly from various vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION) which returns success on firmware compliant to SMCCC v1.1 and above.
This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for backward compatibility. Let us introduce a new hidden config for the same to build more features on top of SMCCC v1.1 and above.
While at it, also sort alphabetically the psci entry.
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-2-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
c65822fe |
| 05-May-2020 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
USB: pci-quirks: Add Raspberry Pi 4 quirk
On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideoCore. Inform V
USB: pci-quirks: Add Raspberry Pi 4 quirk
On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideoCore. Inform VideoCore that VL805 was just reset.
Also, as this creates a dependency between USB_PCI and VideoCore's firmware interface, and since USB_PCI can't be set as a module neither this can. Reflect that on the firmware interface Kconfg.
Link: https://lore.kernel.org/r/20200505161318.26200-5-nsaenzjulienne@suse.de Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
show more ...
|
#
231d901d |
| 05-Mar-2020 |
Richard Gong <richard.gong@intel.com> |
firmware: intel_stratix10_service: add depend on agilex
Add depend on Agilex for Intel Agilex SoC platform.
Signed-off-by: Richard Gong <richard.gong@intel.com> Acked-by: Moritz Fischer <mdf@kernel
firmware: intel_stratix10_service: add depend on agilex
Add depend on Agilex for Intel Agilex SoC platform.
Signed-off-by: Richard Gong <richard.gong@intel.com> Acked-by: Moritz Fischer <mdf@kernel.org> Link: https://lore.kernel.org/r/1583428346-13307-3-git-send-email-richard.gong@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
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 ...
|