Pull EFI fix from Ard Biesheuvel:
"Avoid spurious warnings about unknown boot parameters"
* tag 'efi-urgent-for-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi: fix return value of __setup handlers
pstore_dump() is *always* invoked in atomic context (nowadays in an RCU
read-side critical section, before that under a spinlock).
It doesn't make sense to try to use semaphores here.
This is mostly a revert of commit ea84b580b9 ("pstore: Convert buf_lock
to semaphore"), except that two parts aren't restored back exactly as they
were:
- keep the lock initialization in pstore_register
- in efi_pstore_write(), always set the "block" flag to false
- omit "is_locked", that was unnecessary since
commit 959217c84c ("pstore: Actually give up during locking failure")
- fix the bailout message
The actual problem that the buggy commit was trying to address may have
been that the use of preemptible() in efi_pstore_write() was wrong - it
only looks at preempt_count() and the state of IRQs, but __rcu_read_lock()
doesn't touch either of those under CONFIG_PREEMPT_RCU.
(Sidenote: CONFIG_PREEMPT_RCU means that the scheduler can preempt tasks in
RCU read-side critical sections, but you're not allowed to actively
block/reschedule.)
Lockdep probably never caught the problem because it's very rare that you
actually hit the contended case, so lockdep always just sees the
down_trylock(), not the down_interruptible(), and so it can't tell that
there's a problem.
Fixes: ea84b580b9 ("pstore: Convert buf_lock to semaphore")
Cc: stable@vger.kernel.org
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220314185953.2068993-1-jannh@google.com
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: e3263ab389 ("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
From commit e147133a42 ("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>
Qualcomm driver updates for v5.18
This refactors the Qualcomm mdt file loader, to partially decouple it
from the SCM peripheral-authentication-service. This is needed as newer
platforms, such as the Qualcomm SM8450, require the metadata to remain
accessible to TrustZone during a longer time. This is followed by the
introduction of remoteproc drivers for SM8450 (Snapdragon 8 Gen 1).
It changes the way hardware version differences are handled in the LLCC
driver and introduces support for Qualcomm SM8450. While updating the dt
binding for LLCC it also introduces the missing SM8350 compatible.
The ocmem and aoss drivers gains missing put_device() calls and rpmpd
gains a missing check for kcalloc() failure.
The SPM driver is updated to avoid instantiating the SPM cpuidle devices
if the CPUs aren't controlled by SPM, such as when Snapdragon 8916
operates in 32-bit mode without PSCI.
The RPM power-domain driver gains MSM8226 support.
Lastly the socinfo driver gains knowledge about a few new SoCs and
PMICs.
* tag 'qcom-drivers-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (37 commits)
soc: qcom: rpmpd: Add MSM8226 support
dt-bindings: power: rpmpd: Add MSM8226 to rpmpd binding
soc: qcom: mdt_loader: Fix split-firmware condition
dt-bindings: arm: msm: Add LLCC compatible for SM8450
dt-bindings: arm: msm: Add LLCC compatible for SM8350
soc: qcom: llcc: Add configuration data for SM8450 SoC
soc: qcom: llcc: Update register offsets for newer LLCC HW
soc: qcom: llcc: Add missing llcc configuration data
soc: qcom: llcc: Add write-cache cacheable support
soc: qcom: llcc: Update the logic for version info extraction
soc: qcom: llcc: Add support for 16 ways of allocation
soc: qcom: socinfo: Add some more PMICs and SoCs
firmware: qcom: scm: Add support for MC boot address API
firmware: qcom: scm: Drop cpumask parameter from set_boot_addr()
firmware: qcom: scm: Simplify set_cold/warm_boot_addr()
cpuidle: qcom-spm: Check if any CPU is managed by SPM
remoteproc: qcom: pas: Add SM8450 remoteproc support
dt-bindings: remoteproc: qcom: pas: Add SM8450 PAS compatibles
remoteproc: qcom: pas: Carry PAS metadata context
soc: qcom: mdt_loader: Extract PAS operations
...
Link: https://lore.kernel.org/r/20220301042055.1804859-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When "dump_apple_properties" is used on the kernel boot command line,
it causes an Unknown parameter message and the string is added to init's
argument strings:
Unknown kernel command line parameters "dump_apple_properties
BOOT_IMAGE=/boot/bzImage-517rc6 efivar_ssdt=newcpu_ssdt", will be
passed to user space.
Run /sbin/init as init process
with arguments:
/sbin/init
dump_apple_properties
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc6
efivar_ssdt=newcpu_ssdt
Similarly when "efivar_ssdt=somestring" is used, it is added to the
Unknown parameter message and to init's environment strings, polluting
them (see examples above).
Change the return value of the __setup functions to 1 to indicate
that the __setup options have been handled.
Fixes: 58c5475aba ("x86/efi: Retrieve and assign Apple device properties")
Fixes: 475fb4e8b2 ("efi / ACPI: load SSTDs from EFI variables")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Octavian Purdila <octavian.purdila@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Link: https://lore.kernel.org/r/20220301041851.12459-1-rdunlap@infradead.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Pull ARM SoC fixes from Arnd Bergmann:
"The code changes address mostly minor problems:
- Several NXP/FSL SoC driver fixes, addressing issues with error
handling and compilation
- Fix a clock disabling imbalance in gpcv2 driver.
- Arm Juno DMA coherency issue
- Trivial firmware driver fixes for op-tee and scmi firmware
The remaining changes address issues in the devicetree files:
- A timer regression for the OMAP devkit8000, which has to use the
alternative timer.
- A hang in the i.MX8MM power domain configuration
- Multiple fixes for the Rockchip RK3399 addressing issues with sound
and eMMC
- Cosmetic fixes for i.MX8ULP, RK3xxx, and Tegra124"
* tag 'soc-fixes-5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits)
ARM: tegra: Move panels to AUX bus
soc: imx: gpcv2: Fix clock disabling imbalance in error path
soc: fsl: qe: Check of ioremap return value
soc: fsl: qe: fix typo in a comment
soc: fsl: guts: Add a missing memory allocation failure check
soc: fsl: guts: Revert commit 3c0d64e867
soc: fsl: Correct MAINTAINERS database (SOC)
soc: fsl: Correct MAINTAINERS database (QUICC ENGINE LIBRARY)
soc: fsl: Replace kernel.h with the necessary inclusions
dt-bindings: fsl,layerscape-dcfg: add missing compatible for lx2160a
dt-bindings: qoriq-clock: add missing compatible for lx2160a
ARM: dts: Use 32KiHz oscillator on devkit8000
ARM: dts: switch timer config to common devkit8000 devicetree
tee: optee: fix error return code in probe function
arm64: dts: imx8ulp: Set #thermal-sensor-cells to 1 as required
arm64: dts: imx8mm: Fix VPU Hanging
ARM: dts: rockchip: fix a typo on rk3288 crypto-controller
ARM: dts: rockchip: reorder rk322x hmdi clocks
firmware: arm_scmi: Remove space in MODULE_ALIAS name
arm64: dts: agilex: use the compatible "intel,socfpga-agilex-hsotg"
...
TI Driver updates for v5.18
* Fixups for k3-ringacc, smartreflex, tisci, wkup_m3_ipc
* Device detection for am62x.
* tag 'ti-driver-soc-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
soc: ti: k3-socinfo: Add AM62x JTAG ID
soc: ti: wkup_m3_ipc: Fix IRQ check in wkup_m3_ipc_probe
firmware: ti_sci: inproper error handling of ti_sci_probe
firmware: ti_sci: Fix compilation failure when CONFIG_TI_SCI_PROTOCOL is not defined
soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
soc: ti: k3-ringacc: Use devm_bitmap_zalloc() when applicable
Link: https://lore.kernel.org/r/20220228120655.wobd72acngl2bz6k@ecard
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When the "block" flag is false, the old code would sometimes still call
check_var_size(), which wrongly tells ->query_variable_store() that it can
block.
As far as I can tell, this can't really materialize as a bug at the moment,
because ->query_variable_store only does something on X86 with generic EFI,
and in that configuration we always take the efivar_entry_set_nonblocking()
path.
Fixes: ca0e30dcaa ("efi: Add nonblocking option to efi_query_variable_store()")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20220218180559.1432559-1-jannh@google.com
The get_boot_hartid_from_fdt() function currently returns U32_MAX
for failure case which is not correct because U32_MAX is a valid
hartid value. This patch fixes the issue by returning error code.
Cc: <stable@vger.kernel.org>
Fixes: d7071743db ("RISC-V: Add EFI stub support.")
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Arm SCMI firmware interface updates for v5.18
Few main additions include:
- Support for OPTEE based SCMI transport to enable using SCMI service
provided by OPTEE on some platforms
- Support for atomic SCMI transports which enables few SCMI transactions
to be completed in atomic context. This involves other refactoring work
associated with it. It also marks SMC and OPTEE as atomic transport as
the commands are completed once the return.
- Support for polling mode in SCMI VirtIO transport in order to support
atomic operations
- Support for atomic clock operations based on availability of atomic
capability in the underlying SCMI transport
Other changes involves some trace and log enhancements and miscellaneous
bug fixes.
* tag 'scmi-updates-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (28 commits)
clk: scmi: Support atomic clock enable/disable API
firmware: arm_scmi: Add support for clock_enable_latency
firmware: arm_scmi: Add atomic support to clock protocol
firmware: arm_scmi: Support optional system wide atomic-threshold-us
dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional property
firmware: arm_scmi: Add atomic mode support to virtio transport
firmware: arm_scmi: Review virtio free_list handling
firmware: arm_scmi: Add a virtio channel refcount
firmware: arm_scmi: Disable ftrace for Clang Thumb2 builds
firmware: arm_scmi: Add new parameter to mark_txdone
firmware: arm_scmi: Add atomic mode support to smc transport
firmware: arm_scmi: Add support for atomic transports
firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret
firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret
firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag
firmware: arm_scmi: Make smc transport use common completions
firmware: arm_scmi: Add configurable polling mode for transports
firmware: arm_scmi: Use new trace event scmi_xfer_response_wait
include: trace: Add new scmi_xfer_response_wait event
firmware: arm_scmi: Refactor message response path
...
Link: https://lore.kernel.org/r/20220222201742.3338589-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
i.MX drivers update for 5.18:
- Drop LS1021A device check from soc-imx driver as it's unneeded since
commit commit 4ebd29f916 ("soc: imx: Register SoC device only on
i.MX boards").
- Add support for power domains provided by the VPU blk-ctrl on the
i.MX8MQ.
- Add resource owner management API which will be used to check whether
M4 is under control of Linux.
- Add VPU MU resources support into SCU power domain driver.
- Support DT overlay for WEIM bus driver with OF reconfiguration
notifier handler.
* tag 'imx-drivers-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
bus: imx-weim: add DT overlay support for WEIM bus
firmware: imx: scu-pd: imx8q: add vpu mu resources
firmware: imx: add get resource owner api
soc: imx: imx8m-blk-ctrl: add i.MX8MQ VPU blk-ctrl
dt-bindings: power: imx8mq: add defines for VPU blk-ctrl domains
soc: imx: Remove Layerscape check
Link: https://lore.kernel.org/r/20220222075226.160187-1-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
An SCMI agent can be configured system-wide with a well-defined atomic
threshold: only SCMI synchronous command whose latency has been advertised
by the SCMI platform to be lower or equal to this configured threshold will
be considered for atomic operations, when requested and if supported by the
underlying transport at all.
Link: https://lore.kernel.org/r/20220217131234.50328-6-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Currently SCMI VirtIO channels are marked with a ready flag and related
lock to track channel lifetime and support proper synchronization at
shutdown when virtqueues have to be stopped.
This leads to some extended spinlocked sections with IRQs off on the RX
path to keep hold of the ready flag and does not scale well especially when
SCMI VirtIO polling mode will be introduced.
Add an SCMI VirtIO channel dedicated refcount to track active users on both
the TX and the RX path and properly enforce synchronization and cleanup at
shutdown, inhibiting further usage of the channel once freed.
Link: https://lore.kernel.org/r/20220217131234.50328-2-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Skalkin <igor.skalkin@opensynergy.com>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Arm SCMI fix for v5.17
A simple fix to remove space in the MODULE_ALIAS name used in the
SCMI driver as userspace expect no spaces in these names.
* tag 'scmi-fix-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Remove space in MODULE_ALIAS name
Link: https://lore.kernel.org/r/20220214144245.2376150-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add resource owner management API, this API could be used to check
whether M4 is under control of Linux.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The SMC calling convention designates R0-R7 as input registers in
AArch32 mode, and this conflicts with the compiler's use of R7 as a
frame pointer when building in Thumb2 mode. Generally, we don't enable
the frame pointer, and GCC happily enables the -pg profiling hooks
without them. However, Clang refuses, and errors out with the message
below:
drivers/firmware/arm_scmi/smc.c:152:2: error: write to reserved register 'R7'
arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
^
include/linux/arm-smccc.h:550:4: note: expanded from macro 'arm_smccc_1_1_invoke'
arm_smccc_1_1_smc(__VA_ARGS__); \
^
Let's just disable ftrace for the compilation unit when building this
configuration.
Link: https://lore.kernel.org/r/20220203082204.1176734-11-ardb@kernel.org
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Arm SCMI firmware interface updates for v5.17
Couple of main additions:
- Support for OPTEE based SCMI transport to enable using SCMI service
provided by OPTEE on some platforms
- Support for atomic SCMI transports which enables few SCMI transactions
to be completed in atomic context. This involves other refactoring work
associated with it. It also marks SMC and OPTEE as atomic transport as
the commands are completed once the return
Other changes involves some trace and log enhancements and a miscellaneous
bug fix.
* tag 'scmi-updates-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Add new parameter to mark_txdone
firmware: arm_scmi: Add atomic mode support to smc transport
firmware: arm_scmi: Add support for atomic transports
firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret
firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret
firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag
firmware: arm_scmi: Make smc transport use common completions
firmware: arm_scmi: Add configurable polling mode for transports
firmware: arm_scmi: Use new trace event scmi_xfer_response_wait
include: trace: Add new scmi_xfer_response_wait event
firmware: arm_scmi: Refactor message response path
firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms
firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer
firmware: arm_scmi: optee: Drop the support for the OPTEE shared dynamic buffer
firmware: arm_scmi: optee: Fix missing mutex_init()
firmware: arm_scmi: Make virtio Version_1 compliance optional
firmware: arm_scmi: Add optee transport
dt-bindings: arm: Add OP-TEE transport for SCMI
firmware: arm_scmi: Review some virtio log messages
It looks like the old QCOM_SCM_BOOT_SET_ADDR API is broken on some
MSM8916 firmware versions that implement the newer SMC32 calling
convention. It just returns -EINVAL no matter which arguments are
being passed.
This does not cause any problems downstream because it first tries
to use the new multi-cluster API replacement which is working fine.
Implement support for the multi-cluster variant of the SCM call
by attempting it first but still fallback to the old call in case
of an error. Also, to be absolutely sure only use the multi-cluster
variant with the SMC calling convention since older platforms should
not need this.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211201130505.257379-5-stephan@gerhold.net
qcom_scm_set_cold/warm_boot_addr() currently take a cpumask parameter,
but it's not very useful because at the end we always set the same entry
address for all CPUs. This also allows speeding up probe of
cpuidle-qcom-spm a bit because only one SCM call needs to be made to
the TrustZone firmware, instead of one per CPU.
The main reason for this change is that it allows implementing the
"multi-cluster" variant of the set_boot_addr() call more easily
without having to rely on functions that break in certain build
configurations or that are not exported to modules.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211201130505.257379-4-stephan@gerhold.net
The qcom_scm_set_cold/warm_boot_addr() implementations have a lot of
functionality that is actually not used.
For example, set_warm_boot_addr() caches the last used entry address
and skips making the SCM call when the entry address is unchanged.
But there is actually just a single call of qcom_scm_set_warm_boot_addr()
in the whole kernel tree, which always configures the entry address
to cpu_resume_arm().
Simplify this by having a single qcom_scm_set_boot_addr() function
for both cold and warm boot address. This is totally sufficient for
the functionality supported in the mainline tree.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211201130505.257379-3-stephan@gerhold.net
Starting with Qualcomm SM8450, some new security enhancements has been
done in the secure world, which results in the requirement to keep the
metadata segment accessible by the secure world from init_image() until
auth_and_reset().
Introduce a "PAS metadata context" object that can be passed to
init_image() for tracking the mapped memory and a related release
function for client drivers to release the mapping once either
auth_and_reset() has been invoked or in error handling paths on the way
there.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220128025513.97188-2-bjorn.andersson@linaro.org
[airlied: add two missing Kconfig]
drm-misc-next for v5.18:
UAPI Changes:
- Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL.
Cross-subsystem Changes:
- Assorted dt bindings updates.
- Fix vga16fb vga checking on x86.
- Fix extra semicolon in rwsem.h's _down_write_nest_lock.
- Assorted small fixes to agp and fbdev drivers.
- Fix oops in creating a udmabuf with 0 pages.
- Hot-unplug firmware fb devices on forced removal
- Reqquest memory region in simplefb and simpledrm, and don't make the ioresource as busy.
Core Changes:
- Mock a drm_plane in drm-plane-helper selftest.
- Assorted bug fixes to device logging, dbi.
- Use DP helper for sink count in mst.
- Assorted documentation fixes.
- Assorted small fixes.
- Move DP headers to drm/dp, and add a drm dp helper module.
- Move the buddy allocator from i915 to common drm.
- Add simple pci and platform module init macros to remove a lot of boilerplate from some drivers.
- Support microsoft extension for HMDs and specialized monitors.
- Improve edid parser's deep color handling.
- Add type 7 timing support to edid parser.
- Add a weak backpointer to the ttm_bo from ttm_resource
- Add 3 eDP panels.
Driver Changes:
- Add support for HDMI and JZ4780 to ingenic.
- Add support for higher DP/eDP bitrates to nouveau.
- Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge drivers.
- Convert and revert exynos dsi support to bridge driver.
- Add vcc supply regulator support for sn65dsi83.
- More conversion of bridge/chipone-icn6211 to atomic.
- Remove conflicting fb's from stm, and add support for new hw version.
- Add device link in parade-ps8640 to fix suspend/resume.
- Update Boe-tv110c9m init sequence.
- Add wide screen support to AST2600.
- Fix omapdrm implicit dma_buf fencing.
- Add support for multiple overlay planes to vkms.
- Convert bridge/anx7625 to atomic, add HDCP support,
add eld support for audio, and fix HPD.
- Add driver for ChromeOS privacy screen.
- Handover display from firmware to vc4 more gracefully, and support nomodeset.
- Add flexible and ycbcr pixel formats to stm/ltdc.
- Convert exynos mipi dsi to atomic.
- Add initial dual core group GPUs support to panfrost.
- No longer add exclusive fence in amdgpu as shared fence.
- Add CSC and full range supoprt to vc4.
- Shutdown the display on system shutdown and unbind.
- Add Multi-Inno Technology MI0700S4T-6 simple panel.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/456a23c6-7324-7543-0c45-751f30ef83f7@linux.intel.com
Fix qcom_scm_call(), qcom_scm_call_atomic,
and qcom_scm_cpu_power_down() kernel-doc comment to remove
remove warnings found by running scripts/kernel-doc, which
is caused by using 'make W=1'.
drivers/firmware/qcom_scm.c:191: warning: Function parameter or member
'res' not described in 'qcom_scm_call'
drivers/firmware/qcom_scm.c:191: warning: Excess function parameter
'svc_id' description in 'qcom_scm_call'
drivers/firmware/qcom_scm.c:191: warning: Excess function parameter
'cmd_id' description in 'qcom_scm_call'
drivers/firmware/qcom_scm.c:219: warning: Excess function parameter
'svc_id' description in 'qcom_scm_call_atomic'
drivers/firmware/qcom_scm.c:219: warning: Excess function parameter
'cmd_id' description in 'qcom_scm_call_atomic'
drivers/firmware/qcom_scm.c:360: warning: Function parameter or member
'flags' not described in 'qcom_scm_cpu_power_down'
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211230141245.29444-1-yang.lee@linux.alibaba.com
Aditya reports [0] that his recent MacbookPro crashes in the firmware
when using the variable services at runtime. The culprit appears to be a
call to QueryVariableInfo(), which we did not use to call on Apple x86
machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
firmware fairly recently, and QueryVariableInfo() (along with
UpdateCapsule() et al) was added in EFI v2.00.
The only runtime service introduced in EFI v2.00 that we actually use in
Linux is QueryVariableInfo(), as the capsule based ones are optional,
generally not used at runtime (all the LVFS/fwupd firmware update
infrastructure uses helper EFI programs that invoke capsule update at
boot time, not runtime), and not implemented by Apple machines in the
first place. QueryVariableInfo() is used to 'safely' set variables,
i.e., only when there is enough space. This prevents machines with buggy
firmwares from corrupting their NVRAMs when they run out of space.
Given that Apple machines have been using EFI v1.10 services only for
the longest time (the EFI v2.0 spec was released in 2006, and Linux
support for the newly introduced runtime services was added in 2011, but
the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
let's avoid the EFI v2.0 ones on all Apple x86 machines.
[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
Cc: <stable@vger.kernel.org>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reported-by: Aditya Garg <gargaditya08@live.com>
Tested-by: Orlando Chamberlain <redecorating@protonmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Aditya Garg <gargaditya08@live.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215277
The kernel is aligned at SEGMENT_SIZE and this is the size populated in the PE
headers:
arch/arm64/kernel/efi-header.S: .long SEGMENT_ALIGN // SectionAlignment
EFI_KIMG_ALIGN is defined as: (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN :
THREAD_ALIGN)
So it depends on THREAD_ALIGN. On newer builds this message started to appear
even though the loader is taking into account the PE header (which is stating
SEGMENT_ALIGN).
Fixes: c32ac11da3 ("efi/libstub: arm64: Double check image alignment at entry")
Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This patchset allows to have a single kernel for sv39 and sv48 without
being relocatable.
The idea comes from Arnd Bergmann who suggested to do the same as x86,
that is mapping the kernel to the end of the address space, which allows
the kernel to be linked at the same address for both sv39 and sv48 and
then does not require to be relocated at runtime.
This implements sv48 support at runtime. The kernel will try to boot
with 4-level page table and will fallback to 3-level if the HW does not
support it. Folding the 4th level into a 3-level page table has almost
no cost at runtime.
Note that kasan region had to be moved to the end of the address space
since its location must be known at compile-time and then be valid for
both sv39 and sv48 (and sv57 that is coming).
* riscv-sv48-v3:
riscv: Explicit comment about user virtual address space size
riscv: Use pgtable_l4_enabled to output mmu_type in cpuinfo
riscv: Implement sv48 support
asm-generic: Prepare for riscv use of pud_alloc_one and pud_free
riscv: Allow to dynamically define VA_BITS
riscv: Introduce functions to switch pt_ops
riscv: Split early kasan mapping to prepare sv48 introduction
riscv: Move KASAN mapping next to the kernel mapping
riscv: Get rid of MAXPHYSMEM configs
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
By adding a new 4th level of page table, give the possibility to 64bit
kernel to address 2^48 bytes of virtual address: in practice, that offers
128TB of virtual address space to userspace and allows up to 64TB of
physical memory.
If the underlying hardware does not support sv48, we will automatically
fallback to a standard 3-level page table by folding the new PUD level into
PGDIR level. In order to detect HW capabilities at runtime, we
use SATP feature that ignores writes with an unsupported mode.
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Pull virtio updates from Michael Tsirkin:
"virtio,vdpa,qemu_fw_cfg: features, cleanups, and fixes.
- partial support for < MAX_ORDER - 1 granularity for virtio-mem
- driver_override for vdpa
- sysfs ABI documentation for vdpa
- multiqueue config support for mlx5 vdpa
- and misc fixes, cleanups"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (42 commits)
vdpa/mlx5: Fix tracking of current number of VQs
vdpa/mlx5: Fix is_index_valid() to refer to features
vdpa: Protect vdpa reset with cf_mutex
vdpa: Avoid taking cf_mutex lock on get status
vdpa/vdpa_sim_net: Report max device capabilities
vdpa: Use BIT_ULL for bit operations
vdpa/vdpa_sim: Configure max supported virtqueues
vdpa/mlx5: Report max device capabilities
vdpa: Support reporting max device capabilities
vdpa/mlx5: Restore cur_num_vqs in case of failure in change_num_qps()
vdpa: Add support for returning device configuration information
vdpa/mlx5: Support configuring max data virtqueue
vdpa/mlx5: Fix config_attr_mask assignment
vdpa: Allow to configure max data virtqueues
vdpa: Read device configuration only if FEATURES_OK
vdpa: Sync calls set/get config/status with cf_mutex
vdpa/mlx5: Distribute RX virtqueues in RQT object
vdpa: Provide interface to read driver features
vdpa: clean up get_config_size ret value handling
virtio_ring: mark ring unused on error
...
An initialised kobject must be freed using kobject_put() to avoid
leaking associated resources (e.g. the object name).
Commit fe3c606843 ("firmware: Fix a reference count leak.") "fixed"
the leak in the first error path of the file registration helper but
left the second one unchanged. This "fix" would however result in a NULL
pointer dereference due to the release function also removing the never
added entry from the fw_cfg_entry_cache list. This has now been
addressed.
Fix the remaining kobject leak by restoring the common error path and
adding the missing kobject_put().
Fixes: 75f3e8e47f ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
Cc: stable@vger.kernel.org # 4.6
Cc: Gabriel Somlo <somlo@cmu.edu>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211201132528.30025-3-johan@kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
