firmware: thead: add CONFIG_MAILBOX dependency

Without this, the driver fails to build:

ld: drivers/firmware/thead,th1520-aon.o: in function `th1520_aon_call_rpc':
thead,th1520-aon.c:(.text+0x28):

firmware: thead: add CONFIG_MAILBOX dependency

Without this, the driver fails to build:

ld: drivers/firmware/thead,th1520-aon.o: in function `th1520_aon_call_rpc':
thead,th1520-aon.c:(.text+0x28): undefined reference to `mbox_send_message'
ld: drivers/firmware/thead,th1520-aon.o: in function `th1520_aon_deinit':
thead,th1520-aon.c:(.text+0x17e): undefined reference to `mbox_free_channel'
ld: drivers/firmware/thead,th1520-aon.o: in function `th1520_aon_init':
thead,th1520-aon.c:(.text+0x1d9): undefined reference to `mbox_request_channel_byname'

Fixes: e4b3cbd840e5 ("firmware: thead: Add AON firmware protocol driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Michal Wilczynski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...

firmware: thead: Add AON firmware protocol driver

The T-Head TH1520 SoC uses an E902 co-processor running Always-On (AON)
firmware to manage power, clock, and other system resources [1]. This
patch

firmware: thead: Add AON firmware protocol driver

The T-Head TH1520 SoC uses an E902 co-processor running Always-On (AON)
firmware to manage power, clock, and other system resources [1]. This
patch introduces a driver implementing the AON firmware protocol,
allowing the Linux kernel to communicate with the firmware via mailbox
channels. Through an RPC-based interface, the kernel can initiate power
state transitions, update resource configurations, and perform other
AON-related tasks.

[1]
Link: https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf

Signed-off-by: Michal Wilczynski <[email protected]>
Acked-by: Drew Fustini <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...

firmware: config: ti-sci: Default set to ARCH_K3 for the ti sci driver

With ARCH_K3=y we cannot enable TI_SCI_PROTOCOL=m because
ARCH_K3 selects TI_SCI_PROTOCOL.

Modify the logic to enable TI_SCI_P

firmware: config: ti-sci: Default set to ARCH_K3 for the ti sci driver

With ARCH_K3=y we cannot enable TI_SCI_PROTOCOL=m because
ARCH_K3 selects TI_SCI_PROTOCOL.

Modify the logic to enable TI_SCI_PROTOCOL by default when ARCH_K3=y
allowing us to submit a future patch to remove select on ARCH_K3 without
breaking existing users.

Signed-off-by: Guillaume La Roque <[email protected]>
Reviewed-by: Kevin Hilman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Nishanth Menon <[email protected]>

show more ...

firmware: add Exynos ACPM protocol driver

Alive Clock and Power Manager (ACPM) Message Protocol is defined for
the purpose of communication between the ACPM firmware and masters
(AP, AOC, ...). ACPM

firmware: add Exynos ACPM protocol driver

Alive Clock and Power Manager (ACPM) Message Protocol is defined for
the purpose of communication between the ACPM firmware and masters
(AP, AOC, ...). ACPM firmware operates on the Active Power Management
(APM) module that handles overall power activities.

ACPM and masters regard each other as independent hardware component and
communicate with each other using mailbox messages and shared memory.

This protocol driver provides the interface for all the client drivers
making use of the features offered by the APM. Add ACPM protocol support.

Signed-off-by: Tudor Ambarus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry

Fix ISCSI_IBFT Kconfig entry, replace tab with a space character.

Fixes: 138fe4e0697 ("Firmware: add iSCSI iBFT Support")
Signed-off-by: Prasad Pa

firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry

Fix ISCSI_IBFT Kconfig entry, replace tab with a space character.

Fixes: 138fe4e0697 ("Firmware: add iSCSI iBFT Support")
Signed-off-by: Prasad Pandit <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>

show more ...

video: Add helpers for decoding screen_info

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 framebuffe

video: Add helpers for decoding screen_info

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 <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

firmware: microchip: add PolarFire SoC Auto Update support

Add support for Auto Update reprogramming of the FPGA fabric on
PolarFire SoC, using the fw_upload mechanism a la the
intel-m10-bmc-sec-upd

firmware: microchip: add PolarFire SoC Auto Update support

Add support for Auto Update reprogramming of the FPGA fabric on
PolarFire SoC, using the fw_upload mechanism a la the
intel-m10-bmc-sec-update driver.

This driver only writes the image to the spi flash & performs
validation on it, as the entire FPGA becomes unusable during the actual
reprogramming of a bitstream. To initiate the reprogramming itself, a
device reset is required. The SBI SRST extension's "cold reboot" can
trigger such a device reset, provided corresponding support has been
enabled in the HSS (Hart Software Services), the provider of SBI runtime
services on PolarFire SoC.

While this is a driver responsible for the reprogramming of an FPGA,
there is no dynamic discovery of devices involved, as runtime
reconfiguration is not possible due to the device reset requirements.
Therefore FPGA manager subsystem is not used by this driver and the FPGA
subsystem maintainers were unwilling to accept it there.

Signed-off-by: Conor Dooley <[email protected]>

show more ...

firmware: arm_scpi: Move power-domain driver to the pmdomain dir

To simplify with maintenance let's move the Arm SCPI power-domain driver
to the new pmdomain directory. Note this is different from a

firmware: arm_scpi: Move power-domain driver to the pmdomain dir

To simplify with maintenance let's move the Arm SCPI power-domain driver
to the new pmdomain directory. Note this is different from and precedes
the new Arm SCMI protocol.

Signed-off-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>

show more ...

riscv, qemu_fw_cfg: Add support for RISC-V architecture

Qemu fw_cfg support was missing for RISC-V, which made it hard to do
proper vmcore dumps from qemu.

Add the missing RISC-V arch-defines.

You

riscv, qemu_fw_cfg: Add support for RISC-V architecture

Qemu fw_cfg support was missing for RISC-V, which made it hard to do
proper vmcore dumps from qemu.

Add the missing RISC-V arch-defines.

You can now do vmcore dumps from qemu. Add "-device vmcoreinfo" to the
qemu command-line. From the qemu monitor:
(qemu) dump-guest-memory vmcore

The vmcore can now be used, e.g., with the "crash" utility.

Acked-by: "Michael S. Tsirkin" <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Tested-by: Clément Léger <[email protected]>
Signed-off-by: Björn Töpel <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>

show more ...

firmware: qcom: move Qualcomm code into its own directory

We're getting more and more qcom specific .c files in drivers/firmware/
and about to get even more. Create a separate directory for Qualcomm

firmware: qcom: move Qualcomm code into its own directory

We're getting more and more qcom specific .c files in drivers/firmware/
and about to get even more. Create a separate directory for Qualcomm
firmware drivers and move existing sources in there.

Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Elliot Berman <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Maximilian Luz <[email protected]>
Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

firmware: qcom: qseecom: Add missing AUXILIARY_BUS dependency

The newly introduced QSEECOM driver fail to link if the system is built
without CONFIG_AUXILIARY_BUS, make sure it is selected.

Fixes:

firmware: qcom: qseecom: Add missing AUXILIARY_BUS dependency

The newly introduced QSEECOM driver fail to link if the system is built
without CONFIG_AUXILIARY_BUS, make sure it is selected.

Fixes: 00b1248606ba ("firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface")
Reported-by: Randy Dunlap <[email protected]>
Closes: https://lore.kernel.org/r/9f156fa6-e5aa-4cb2-ab2b-b67fd8fc4840%40infradead.org
Signed-off-by: Bjorn Andersson <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

firmware: Add support for Qualcomm UEFI Secure Application

On platforms using the Qualcomm UEFI Secure Application (uefisecapp),
EFI variables cannot be accessed via the standard interface in EFI
ru

firmware: Add support for Qualcomm UEFI Secure Application

On platforms using the Qualcomm UEFI Secure Application (uefisecapp),
EFI variables cannot be accessed via the standard interface in EFI
runtime mode. The respective functions return EFI_UNSUPPORTED. On these
platforms, we instead need to talk to uefisecapp. This commit provides
support for this and registers the respective efivars operations to
access EFI variables from the kernel.

Communication with uefisecapp follows the Qualcomm QSEECOM / Secure OS
conventions via the respective SCM call interface. This is also the
reason why variable access works normally while boot services are
active. During this time, said SCM interface is managed by the boot
services. When calling ExitBootServices(), the ownership is transferred
to the kernel. Therefore, UEFI must not use that interface itself (as
multiple parties accessing this interface at the same time may lead to
complications) and cannot access variables for us.

Signed-off-by: Maximilian Luz <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface

Add support for SCM calls to Secure OS and the Secure Execution
Environment (SEE) residing in the TrustZone (T

firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface

Add support for SCM calls to Secure OS and the Secure Execution
Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM
interface. This allows communication with Secure/TZ applications, for
example 'uefisecapp' managing access to UEFI variables.

For better separation, make qcom_scm spin up a dedicated child
(platform) device in case QSEECOM support has been detected. The
corresponding driver for this device is then responsible for managing
any QSEECOM clients. Specifically, this driver attempts to automatically
detect known and supported applications, creating a client (auxiliary)
device for each one. The respective client/auxiliary driver is then
responsible for managing and communicating with the application.

While this patch introduces only a very basic interface without the more
advanced features (such as re-entrant and blocking SCM calls and
listeners/callbacks), this is enough to talk to the aforementioned
'uefisecapp'.

Signed-off-by: Maximilian Luz <[email protected]>
Reviewed-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS based. The use of Linux on Itanium appears to be limited to
enthusiasts that occasionally boot a fresh Linux kernel to see whether
things are still working as intended, and perhaps to churn out some
distro packages that are rarely used in practice.

None of the original companies behind Itanium still produce or support
any hardware or software for the architecture, and it is listed as
'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
that contributed on behalf of those companies (nor anyone else, for that
matter) have been willing to support or maintain the architecture
upstream or even be responsible for applying the odd fix. The Intel
firmware team removed all IA-64 support from the Tianocore/EDK2
reference implementation of EFI in 2018. (Itanium is the original
architecture for which EFI was developed, and the way Linux supports it
deviates significantly from other architectures.) Some distros, such as
Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
dropped support years ago.

While the argument is being made [1] that there is a 'for the common
good' angle to being able to build and run existing projects such as the
Grid Community Toolkit [2] on Itanium for interoperability testing, the
fact remains that none of those projects are known to be deployed on
Linux/ia64, and very few people actually have access to such a system in
the first place. Even if there were ways imaginable in which Linux/ia64
could be put to good use today, what matters is whether anyone is
actually doing that, and this does not appear to be the case.

There are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors. GCC still supports IA-64
but its compile farm [3] no longer has any IA-64 machines. GLIBC would
like to get rid of IA-64 [4] too because it would permit some overdue
code cleanups. In summary, the benefits to the ecosystem of having IA-64
be part of it are mostly theoretical, whereas the maintenance overhead
of keeping it supported is real.

So let's rip off the band aid, and remove the IA-64 arch code entirely.
This follows the timeline proposed by the Debian/ia64 maintainer [5],
which removes support in a controlled manner, leaving IA-64 in a known
good state in the most recent LTS release. Other projects will follow
once the kernel support is removed.

[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
[1] https://lore.kernel.org/all/[email protected]/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/[email protected]/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: TingHan Shen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Curtis Malainey <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: YC Hung <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

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 <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/948c39940a4e99f5b43bdbcbe537faae71a43e1d.1645822213.git.msuchanek@suse.de

show more ...

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 <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/a0fa41e9186653e4c41ad0a28259e5cdc71b1f66.1645822213.git.msuchanek@suse.de

show more ...

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Acked-by: Alex Elder <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

firmware: qcom_scm: QCOM_SCM should depend on ARCH_QCOM

The Qualcomm Secure Channel Manager (SCM) is only present on Qualcomm
SoCs. All drivers using it select QCOM_SCM, and depend on ARCH_QCOM.
Un

firmware: qcom_scm: QCOM_SCM should depend on ARCH_QCOM

The Qualcomm Secure Channel Manager (SCM) is only present on Qualcomm
SoCs. All drivers using it select QCOM_SCM, and depend on ARCH_QCOM.
Until recently, QCOM_SCM was an invisible symbol, but this was changed
by adding loadable module support, exposing it to all ARM and ARM64
users. Hence add a dependency on ARCH_QCOM, to prevent asking the user
about this driver when configuring a kernel without Qualcomm SoC
support.

While at it, drop the dependency on ARM || ARM64, as that is implied by
HAVE_ARM_SMCCC.

Fixes: b42000e4b8741bf6 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module")
Fixes: 2954a6f12f250890 ("firmware: qcom-scm: Fix QCOM_SCM configuration")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/5cda77085c07dc2e8d2195507b287457cb2f09e9.1629807831.git.geert+renesas@glider.be

show more ...

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/[email protected]
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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 <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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 <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...