Historically DSI PHY bindings landed to the display/msm subdir, however
they describe PHYs and as such they should be in the phy/ subdir.
Follow the example of other Qualcomm display-related PHYs (HDMI, eDP)
and move bindings for the Qualcomm DSI PHYs to the correct subdir.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/709008/
Link: https://lore.kernel.org/r/20260305-msm-dsi-phy-v1-1-0a99ac665995@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The driver references CWB array from SM8650, but should use the Eliza
specific, which has different register space sizes. This should not
have noticeable impact on function but is indeed confusing, since the
Eliza table is used for .cwb_count.
Fixes: 0eb707bbc7 ("drm/msm/dpu: Add support for Eliza SoC")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/715623/
Link: https://lore.kernel.org/r/20260331161156.211623-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Due to historical reasons we ended up with dummy values being specified
for MST-related interfaces some of them had INTF_NONE, others had
non-existing DP controller indices. Those workarounds are no longer
necessary. Fix types and indices for all DP-MST related INTF instances.
The only exception is INTF_3 on SC8180X, which has unique design. It can
be used either with INTF_0 / DP0 or with INTF_4 / DP1. This interface is
left with the dummy value until somebody implements necessary bits for
that platform.
Co-developed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/713988/
Link: https://lore.kernel.org/r/20260325-fix-dp-mst-interfaces-v1-1-186d1de3fa1b@oss.qualcomm.com
Support for using a single CTL for flushing both interfaces was not in
use since the MDP5 driver dropped support for dual DSI configurations in
the commit df3c789994 ("drm/msm/mdp5: drop split display support").
Having the MDP 3.x support migrated to the DPU driver the single CTL
flush is applicable to the platforms suspproted by the MDP5 driver. Drop
it alltogether.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/713916/
Link: https://lore.kernel.org/r/20260325-mdp5-drop-single-flush-v1-1-862a38b4d2ec@oss.qualcomm.com
On the Asus PRIME X670E-PRO WIFI, the driver reports a constant value of
zero for T_Sensor. On this board, the register for T_Sensor is at a
different address, as found by experimentation and confirmed by
comparison to an independent temperature reading.
* sensor disconnected: -62.0°C
* ambient temperature: +22.0°C
* held between fingers: +30.0°C
Introduce SENSOR_TEMP_T_SENSOR_ALT1 to support the PRIME X670E-PRO WIFI
without causing a regression for other 600-series boards
Fixes: e0444758dd ("hwmon: (asus-ec-sensors) add PRIME X670E-PRO WIFI")
Signed-off-by: Corey Hickey <bugfood-c@fatooh.org>
Link: https://lore.kernel.org/r/20260331215414.368785-1-bugfood-ml@fatooh.org
[groeck: Fixed typo, updated Fixes: reference]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
set_id_regs creates a GIC3 guest when possible, and then proceeds
to write the ID registers as if they were not affected by the presence
of a GIC. As it turns out, ID_AA64PFR1_EL1 is the proof of the
contrary.
KVM now makes a point in exposing the GIC support to the guest,
no matter what userspace says (userspace such as QEMU is known to
write silly things at times).
Accommodate for this level of nonsense by teaching set_id_regs about
fields that are mutable, and only compare registers that have been
re-sanitised first.
Reported-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260401103611.357092-17-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Although the AArch32 ID regs are architecturally UNKNOWN when AArch32
isn't supported at any EL, KVM makes a point in making them RAZ.
Therefore, advertising GICv3 in ID_PFR1_EL1 must be gated on AArch32
being supported at least at EL0.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: a258a383b9 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE")
Reported-by: Mark Brown <broonie@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260401103611.357092-16-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Userspace can set the timer PPI numbers way before a GIC has been
created, leading to odd behaviours on GICv5 as we'd accept non
architectural PPI numbers.
Move the v5 check into timer_irqs_are_valid(), which aligns the
behaviour with the pre-v5 GICs, and is also guaranteed to run
only once a GIC has been configured.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 9491c63b6c ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Link: https://patch.msgid.link/20260401103611.357092-14-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
The vgic-v5 code added some evaluations of the timers in a helper funtion
(kvm_cpu_has_pending_timer()) that is called to determine whether
the vcpu can wake-up.
But looking at the timer there is wrong:
- we want to see timers that are signalling an interrupt to the
vcpu, and not just that have a pending interrupt
- we already have kvm_arch_vcpu_runnable() that evaluates the
state of interrupts
- kvm_cpu_has_pending_timer() really is about WFIT, as the timeout
does not generate an interrupt, and is therefore distinct from
the point above
As a consequence, revert these changes and teach vgic_v5_has_pending_ppi()
about checking for pending HW interrupts instead.
Fixes: 9491c63b6c ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Link: https://patch.msgid.link/20260401103611.357092-13-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
The newly introduced arch_timer_context::direct field is a bit pointless,
as it is always set on timers that are... err... direct, while
we already have a way to get to that by doing a get_map() operation.
Additionally, this field is:
- only set when get_map() is called
- never cleared
and the single point where it is actually checked doesn't call get_map()
at all.
At this stage, it is probably better to just kill it, and rely on
get_map() to give us the correct information.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 9491c63b6c ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Link: https://patch.msgid.link/20260401103611.357092-12-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
The way the effective priority mask is compared to the priority of
an interrupt to decide whether to wake-up or not, is slightly odd,
and breaks at the limits.
This could result in spurious wake-ups that are undesirable.
Make the computed priority mask comparison a strict inequality, so
that interrupts that have the same priority as the mask are not
signalled.
Fixes: 933e5288fa ("KVM: arm64: gic-v5: Check for pending PPIs")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Link: https://patch.msgid.link/20260401103611.357092-10-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Finalizing the PPI state is done without holding any lock, which
means that two vcpus can race against each other and have one zeroing
the state while another one is setting it, or even maybe using it.
Fixing this is done by:
- holding the config lock while performing the initialisation
- checking if SW_PPI has already been advertised, meaning that
we have already completed the initialisation once
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 8f1fbe2fd2 ("KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask")
Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
Link: https://patch.msgid.link/20260401103611.357092-7-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Although we are OK with rewriting idregs at finalize time, resetting
the guest's cpuif (GICv3) or redistributor (GICv3) addresses once
we start running the guest is a pretty bad idea.
Move back this initialisation to vgic creation time.
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: a258a383b9 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE")
Link: https://patch.msgid.link/20260323174713.3183111-1-maz@kernel.org
Link: https://patch.msgid.link/20260401103611.357092-2-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Wi-Fi now works with this patch, relevant firmware and
qcom,snoc-host-cap-skip-quirk
qcom,snoc-host-cap-skip-quirk has not been approved/merged in mainline,
so it is not included here.
ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001
ath10k_snoc 18800000.wifi: qmi fw_version 0x20060285 fw_build_timestamp 2020-10-12 23:35 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c4-00645-QCAHLSWMTPLZ-1.336037.2
ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0
ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
ath10k_snoc 18800000.wifi: htt-ver 3.83 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-11-87217b15fefb@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Also include other supporting msm drm nodes, gpio and backlight
Co-developed-by: Amir Dahan <system64fumo@tuta.io>
Signed-off-by: Amir Dahan <system64fumo@tuta.io>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-10-87217b15fefb@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the multicolor status LED in the phone's notch.
Signed-off-by: Amir Dahan <system64fumo@tuta.io>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-8-87217b15fefb@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
uart9 is debug serial on USB SBU1/2
UART RX is SBU1 and UART TX is SBU2 of the USB-C port).
1.8V Logic Level
Tested using pololu usb07a https://www.pololu.com/product/2585
and CH340 USB-UART
uart6 is bluetooth
Bluetooth: hci0: setting up wcn399x
Bluetooth: hci0: QCA Product ID :0x0000000a
Bluetooth: hci0: QCA SOC Version :0x40010214
Bluetooth: hci0: QCA ROM Version :0x00000201
Bluetooth: hci0: QCA Patch Version:0x00000001
Bluetooth: hci0: QCA controller version 0x02140201
Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
Bluetooth: hci0: QCA Downloading qca/judyln/crnv21.bin
Bluetooth: hci0: QCA setup on UART is completed
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-6-87217b15fefb@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add paths for Qualcomm firmware, including:
ipa, modem, venus, gpu
GPU and bluetooth are confirmed working, others may need more
testing/fixes
But regardless they will need the firmware paths specified here
and firmware added upstream before they will work, so might as well
get started on it now.
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-2-87217b15fefb@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The two Type-C ports found on Glymur CRD are DisplayPort alternate mode
capable. Everything is in place already for the USB, but for DisplayPort
the controllers need to be enabled.
So enable the related DisplayPort controller for each of these two
ports. Also define the supported link frequencies for each output.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260330-glymur-enable-displayport-v1-1-1543ad6dac3a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
If io_parse_restrictions() fails, it ends up clearing any restrictions
currently set. The intent is only to clear whatever it already applied,
but it ends up clearing everything, including whatever settings may have
been applied in a copy-on-write fashion already. Ensure that those are
retained.
Link: https://lore.kernel.org/io-uring/CAK8a0jzF-zaO5ZmdOrmfuxrhXuKg5m5+RDuO7tNvtj=kUYbW7Q@mail.gmail.com/
Reported-by: antonius <bluedragonsec2023@gmail.com>
Fixes: ed82f35b92 ("io_uring: allow registration of per-task restrictions")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Commit 9618908026 addressed one case of ctx->rings being potentially
accessed while a resize is happening on the ring, but there are still
a few others that need handling. Add a helper for retrieving the
rings associated with an io_uring context, and add some sanity checking
to that to catch bad uses. ->rings_rcu is always valid, as long as it's
used within RCU read lock. Any use of ->rings_rcu or ->rings inside
either ->uring_lock or ->completion_lock is sane as well.
Do the minimum fix for the current kernel, but set it up such that this
basic infra can be extended for later kernels to make this harder to
mess up in the future.
Thanks to Junxi Qian for finding and debugging this issue.
Cc: stable@vger.kernel.org
Fixes: 79cfe9e59c ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS")
Reviewed-by: Junxi Qian <qjx1298677004@gmail.com>
Tested-by: Junxi Qian <qjx1298677004@gmail.com>
Link: https://lore.kernel.org/io-uring/20260330172348.89416-1-qjx1298677004@gmail.com/
Signed-off-by: Jens Axboe <axboe@kernel.dk>
for 7.1, please pull the following:
- Rafal provides a complete description of the PCIe Root Complex nodes
in order to silence a number of dtc warnings
- Rosen provides the necessary NVMEM properties to allow describing the
WAN device MAC address from NVRAM, also adds better LEDs, USB GPIOs
and Wi-Fi buttons for the Linksys EA9200 router
- Linus completes the BCA devices description by adding the I2C block
and fixing interrupts for the DMA block on 63138 and 6878
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmnBjUcACgkQh9CWnEQH
BwQuSw//UCaVf2xSvFi8/XT6SQrfHvPEoZX0AUJWZG2SUVh1YkTJdsWBDVcQErLN
wwPxOK65q0a7XCA+BdRIAt9W5Boa5kO9zrwpwUXRKBupdbIDH67wxkQV2e73Ne3Z
FsBqTiOqlNCj8I7f4lzy/uP0/uHR5Nvyh4N4rHRj+hb20dFtOJOeXuMyo+FRIf+f
alVRFgLJi4P3SxCBsj6xUmR7p2l51MYhVZ/Ind0QwP9ZGBcOg0jfi4EUe07jnolb
twO9EFPVi/QMVHOnMGmJMz+oDX7Z882SjObB2FHOQPXDbsnONjfW782dwT8VObjM
vbsyfoH68AtTqbkZ/MXWEJeWYxVI/UQjrvRFkXVCqYpb3B7foo/fDCLi/5wnYMyE
BYza7w4DxVix4jwdfVeXcIb+wjVt7hrvNb6r+zIx5yHdA9oEiNfkJ1DajsCn50co
E/+XYq/9r9HxnkK3YkYr3ZLxvxqdXFLpnUaVtarWF3XQbDRqV5931kXfhp9VOO8T
wHHGiiHi7j2ELh9d38GMaZ95O3KV+3LUaTMHhGN7CKNi7G6gIGVRPVpmI9Ej7nc0
1g0fRKKKkPFA4aqG6FLWvYzjujoS9+ERRmYBPL3Zt2DXbEASCL2dw1p7eHM5fbu9
R56SXGhjc05e71DOs/yy5aHInC7RCCowMjVUC4IXRHRNBtAH3bw=
=ITzn
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmnNLNcACgkQmmx57+YA
GNlGeRAApKrehO59bFAZ3d+VW5rX6jhnY//egiYGse2j7NWsR9pgKTBSLHzSqwob
k5/ZDtrUxjWyt7AtNcB3FKa2eZPO6AZPZ0j0lIFPXARmOPJM+qy0aJHlgA3gFbht
adkz8nlpkVddS2dLlK+TXnmcLpmnAlBULZ4QbsvDyasWFKyacbm8z8ry+M6e4IXB
Y+1Jc/hPE8xIozMZ0OWL8yfh4rnCUsOolJif3kK5REX+rCrgOci7U3bEq93BLMb6
/jY1cSSxXXG7w3S/VPZgcqHTJpzMuKLUL0shH3j4rboaproBtvJ7i0280EGPVlwQ
cFDn6gi0GQ15eHinPsfYrGZCfXBDRYF2w/hiTivT0HHdwXcQIZCW5JaVqmhSf6SL
vWA1hfIZwgk4CyRa+ESHfG/vLRMPfqqEgjXpNc44sl8I0TRHubj+cHpqpZKYqYNY
DbE8WbcsEfCe4ROhMQu9nKIFTodgV8UhvxkcDuIhO5CslQaTyXiMMofWSBR6rdQN
ZIfoZ/WQYDgtzTlKCeIKryjE7Ii6vp55Th1Iyzj054qssSjVSH6/yfOCuXyfKZxP
tnznRvtZ2be422BchyPlTYIGErOWMfaJHZVnVmEnQ/DaosfSdh6PvJ1Aep1sF7UL
XIN7VWfQTbefrfFJXEU9dhKqCDEN4FFMVhkWRuIQJ0VMBqZZJYI=
=KEH/
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-7.1/devicetree' of https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM-based SoCs Device Tree updates
for 7.1, please pull the following:
- Rafal provides a complete description of the PCIe Root Complex nodes
in order to silence a number of dtc warnings
- Rosen provides the necessary NVMEM properties to allow describing the
WAN device MAC address from NVRAM, also adds better LEDs, USB GPIOs
and Wi-Fi buttons for the Linksys EA9200 router
- Linus completes the BCA devices description by adding the I2C block
and fixing interrupts for the DMA block on 63138 and 6878
* tag 'arm-soc/for-7.1/devicetree' of https://github.com/Broadcom/stblinux:
ARM: dts: BCM5301X: EA9200: specify partitions
ARM: dts: BCM5301X: EA9200: add LEDs
ARM: dts: BCM5301X: EA9200: add USB GPIOs
ARM: dts: BCM5301X: EA9200: add WiFi button
ARM: dts: broadcom: bcm2835-rpi: Move non simple-bus nodes to root level
ARM: dts: bcm63148: Add I2C block
ARM: dts: bcm63138: Add I2C block
ARM: dts: bcm6878: Add I2C bus block
ARM: dts: bcm6855: Add I2C bus blocks
ARM: dts: bcm6846: Add I2C bus block
ARM: dts: bcm63138: Fix DMA IRQ
ARM: dts: bcm6878: Fix PL081 DMA block IRQ
ARM: dts: BCM5301X: AC5300: set WAN MAC from nvram
ARM: dts: BCM5301X: AC3100: set WAN MAC from nvram
ARM: dts: BCM5301X: panamera: set WAN MAC from nvram
ARM: dts: BCM5301X: EA9200: set WAN MAC from nvram
ARM: dts: BCM5301X: add root pcie bridges
ARM: dts: BCM5301X: Drop extra NAND controller compatible
ARM: dts: BCM5301X: Describe PCIe controllers fully
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Implement arm64 support for the 'unoptimized' static call variety, which
routes all calls through a trampoline that performs a tail call to the
chosen function, and wire it up for use when kCFI is enabled. This works
around an issue with kCFI and generic static calls, where the prototypes
of default handlers such as __static_call_nop() and __static_call_ret0()
don't match the expected prototype of the call site, resulting in kCFI
false positives [0].
Since static call targets may be located in modules loaded out of direct
branching range, this needs an ADRP/LDR pair to load the branch target
into R16 and a branch-to-register (BR) instruction to perform an
indirect call.
Unlike on x86, there is no pressing need on arm64 to avoid indirect
calls at all cost, but hiding it from the compiler as is done here does
have some benefits:
- the literal is located in .rodata, which gives us the same robustness
advantage that code patching does;
- no D-cache pollution from fetching hash values from .text sections.
From an execution speed PoV, this is unlikely to make any difference at
all.
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will McVicker <willmcvicker@google.com>
Reported-by: Carlos Llamas <cmllamas@google.com>
Closes: https://lore.kernel.org/all/20260311225822.1565895-1-cmllamas@google.com/ [0]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Enable the configuration of EVM so that it requires that asymmetric
signatures it accepts are of version 3 (sigv3). To enable this, introduce
bit 3 (value 0x0008) that the user may write to EVM's securityfs policy
configuration file 'evm' for sigv3 enforcement.
Mention bit 3 in the documentation.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIG on RSA, ECDSA,
ECRDSA, and SM2 signatures.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Defining a policy rule with the "appraise_type=imasig" option allows
either v2 or v3 signatures. Defining an IMA appraise rule with the
"appraise_type=sigv3" option requires a file sigv3 signature.
Define a new appraise type: IMA_SIGV3_REQUIRED
Example: appraise func=BPRM_CHECK appraise_type=sigv3
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Acked-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Instead of directly verifying the signature of a file data hash,
signature v3 verifies the signature of the ima_file_id structure
containing the file data hash.
To disambiguate the signature usage, the ima_file_id structure also
includes the hash algorithm and the type of data (e.g. regular file
hash or fs-verity root hash).
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Acked-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Define asymmetric_verify_v3() to calculate the hash of the struct
ima_file_id, before calling asymmetric_verify() to verify the
signature.
Move and update the existing calc_file_id_hash() function with a
simpler, self contained version. In addition to the existing hash
data and hash data length arguments, also pass the hash algorithm.
Suggested-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Acked-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
cpu_possible_mask is set early during boot based on information from the
firmware. After that it remains read only and is never changed. Therefore
there is no need to acquire the CPU-hotplug lock while reading it.
Remove cpus_read_*() while accessing cpu_possible_mask.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260401121334.xeMOSC1v@linutronix.de
When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls
kobject_put(&dbs_data->attr_set.kobj).
The kobject release callback cpufreq_dbs_data_release() calls
gov->exit(dbs_data) and kfree(dbs_data), but the current error path
then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a
double free.
Keep the direct kfree(dbs_data) for the gov->init() failure path, but
after kobject_init_and_add() has been called, let kobject_put() handle
the cleanup through cpufreq_dbs_data_release().
Fixes: 4ebe36c94a ("cpufreq: Fix kobject memleak")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260401024535.1395801-1-lgs201920130244@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Replace the naked intel_uncore_read*() with intel_de_read*()
in the MCHBAR code.
v2: Rebase due to intel_uncore_read64_2x32()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260331154259.24600-12-ville.syrjala@linux.intel.com
