A received RAVE-SP frame contains protocol data followed by a
variant-specific one- or two-byte checksum. rave_sp_receive_frame() derives
a checksum pointer before proving that the frame contains the checksum,
then passes the checksum-inclusive length to handlers that index the
command, acknowledgment ID and event-data bytes or derive a reply payload
length.
Name those protocol field offsets, prove the checksum extent before
deriving the protocol-data length, pass only that data length to the
handlers, and require the complete event or reply prefix before consuming
it.
Fixes: 538ee27290 ("mfd: Add driver for RAVE Supervisory Processor")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://lore.kernel.org/all/20260706092337.78754-1-pengpeng@iscas.ac.cn/
Link: https://patch.msgid.link/20260720115523.99956-1-pengpeng@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
Most EL1 exceptions already call local_daif_mask() before returning,
with the exception of debug exception handlers which do not change
DAIF, and the IRQ/FIQ/Error handlers.
However, DAIF get masked in kernel_exit() in all cases when returning
from EL1 C handlers anyway.
Move this masking from assembly to C by calling local_daif_mask()
before irqentry_nmi_exit(). Unlike the raw DAIF masking helper,
local_daif_mask() invokes trace_hardirqs_off(), so it must execute
while RCU is still watching.
Remove the disable_daif assembly macro, as this was its only use.
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
When we resume from cpu_suspend() context tracking, specially,
ct_idle_exit() performs IRQ save/restore sequence. It doesn't cause
any functional issues since we have masked all exceptions prior
suspend and have not restored them. However, in case of pseudo-NMI PMR
can be set by firmware to arbitrary value, thus IRQ save/restore
routines manipulates this arbitrary value. Again, it doesn't cause any
issues since PMR variant of IRQ save helper carries a
__pmr_irqs_disabled_flags() guard.
Going forward __pmr_irqs_disabled_flags() guard will be gone and we
will call __pmr_local_irq_disable() unconditionally - that would cause
warning in case CONFIG_ARM64_DEBUG_PRIORITY_MASKING is set.
Initialize PMR to a value known to Linux on resume until the normal
exception restore path restores the saved DAIF and PMR state.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Commit 77345ef704 ("arm64: suspend: Use cpuidle context helpers
in cpu_suspend()") added cpuidle helpers to handle PMR manipulation
and restoration to ensure that the CPU receives interrupts when suspended
and pseudo-NMIs are enabled.
However, those helpers are called in between a pair of `local_daif_save()`
and `local_daif_restore()`, which already configure the PMR as expected.
Effectively, `arm_cpuidle_save_irq_context()` is a no-op here,
even when using pseudo-NMIs, and `arm_cpuidle_restore_irq_context()`
would not restore proper interrupt masking configuration early enough
if there were unexpected changes during suspend or resume.
(This can be observed with Trusted Firmware A (TF-A) at EL3 handling
suspend through PSCI. Even though it should not be the case, TF-A can
reset `ICC_PMR_EL1` during CPU_SUSPEND, thus resuming the kernel
with an inconsistent priority mask value on hardware implementing
more than the minimum number of priority levels, such as Morello.)
Thus : remove the cpuidle context helpers as they do not do anything,
but keep the comment mentioning the need for interrupts to reach the CPU
if we are using pseudo-NMIs.
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Sashiko AI has reported that if swsusp_mte_save_tags() for some reason
fails we return from swsusp_arch_suspend() with DAIF being masked -
that is not what we'd expect. Restore the saved DAIF state before
returning from the error path.
Fixes: ee11f332af ("arm64: mte: Save tags when hibernating")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
The arm64 hibernate code manages the exception masking in an unsound
way, leading to potential crashes and/or warnings during resume.
When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF
exceptions are masked (by virtue of `local_daif_save()`), and the
suspended image is saved assuming that all DAIF exceptions will remain
masked when the image is restored.
When a hibernation image is resumed by `swsusp_arch_resume()`, only
interrupts are masked (by virtue of `local_irq_disable()` in
`resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits
will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be
clear.
This means that there are two problems:
(1) It is possible to take Debug, SError, or pseudo-NMI exceptions
during the resume process. This is unsafe, as during the resume
process both the old ane new kernels will tranisently be in an
inconsistent state, and swsusp_arch_suspend_exit() won't retain
an executable mapping of any exception vectors.
Any exception taken here will be fatal and silent.
(2) When re-entering the resumed kernel, some DAIF bits will be clear
unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions
to be taken for a short period while the resumed kernel is not yet
in a consistent state.
This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING.
Avoid these issues by masking all DAIF exceptions during resume.
Fixes: 82869ac57b ("arm64: kernel: Add support for hibernate/suspend-to-disk")
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Masking DAIF around the write to MDSCR_EL1 doesn't do anything: we can
write to sysregs with interrupts unmasked, and writing to PSTATE is
not a context synchronization event so it does not synchronize it.
This is done in the context of a general interrupt handling cleanup,
so it does not address the missing context synchronization for the
MDSCR_EL1 write, staying consistent with the current state. This
should be addressed in a future patch.
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Last user of INIT_PSTATE_EL2 has gone with ae4b7e38e9 ("arm64: Allow
sticky E2H when entering EL1"), so remove it.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
The cluster-to-dentry calculation is performed as u32 and may overflow
and wrap around on large volumes. This can result in an incorrect
max_dentries value, causing readdir to stop early and omit directory
entries.
Cast nr_clusters to u64 before shifting to avoid the overflow.
Signed-off-by: Yang Wen <anmuxixixi@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
The memory allocated for struct sm501_devdata in sm501_pci_probe() and
sm501_plat_probe() is not freed by the corresponding remove functions
sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to
kfree().
Fixes: b6d6454fdb ("[PATCH] mfd: SM501 core driver")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Link: https://patch.msgid.link/20260720113836.73133-1-nihaal@cse.iitm.ac.in
Signed-off-by: Lee Jones <lee@kernel.org>
The Axiado AX3005 SPI controller is software-compatible with the
Synopsys DesignWare APB SSI 1.01a programming interface.
Document the "axiado,ax3005-spi" SoC-specific compatible with
"snps,dwc-ssi-1.01a" as its fallback. This preserves identification of
the AX3005 integration while allowing the controller to use the
existing DesignWare APB SSI support.
Signed-off-by: Swark Yang <syang@axiado.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260805-upstrea-ax3005-spi-v4-v4-1-5b8bc11cb841@axiado.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ssd130x_update_bl() runs for every SSD13xx panel, but it only works for
SSD130x and SSD132x: it writes the single global SSD13XX_CONTRAST (0x81)
command, which those two families expose. SSD133x has no such command --
it has three per-channel contrast registers (CONTRAST_A/B/C) that must be
scaled together -- so ssd130x_update_bl() has no effect on it.
Make backlight_ops.update_status a per-family choice. SSD130x and SSD132x
keep ssd130x_update_bl() because they share the SSD13XX_CONTRAST interface,
while SSD133x gets ssd133x_update_bl(), which drives the three channels
through ssd133x_set_contrast().
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260729053054.29374-3-amit.barzilai22@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
ssd133x_init() wrote the SSD133X_CONTRAST_A/B/C commands with magic hex
values (0x91/0x50/0x7d). These are a per-channel white-balance
calibration: the A/B/C channels drive sub-pixels whose OLED materials
differ in luminous efficiency, so the values set the white point at full
brightness.
Extract them into ssd133x_set_contrast(), which scales each channel by a
requested brightness via ssd130x_scale_contrast(), instead of writing the
calibration unconditionally. This makes the sequence readable, avoids
repetition, and is a prerequisite for wiring up an ssd133x backlight
controller that dims while preserving the white point.
Note this changes the ssd133x power-on brightness. Previously the init
wrote the calibration unscaled and ignored ssd130x->contrast, so the
panel always booted at full brightness. It now scales by the shared
default contrast of 127, i.e. half of MAX_CONTRAST (255). This is
intentional and matches ssd130x, whose contrast register also defaults
to 127 (mid-scale), so all families now power on at ~50% and report
props.brightness = 127 / max_brightness = 255 to userspace.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260729053054.29374-2-amit.barzilai22@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
MTK_GPHY_LED_TX_BLINK_SET and MTK_2P5GPHY_LED_TX_BLINK_SET are built
from the RX blink bits instead of the TX ones, so both TX masks are
identical to their RX counterparts. The TX bits they should be using,
MTK_PHY_LED_BLINK_{10,100,1000,2500}TX, are otherwise only referenced
by the per-speed branch of mtk_phy_led_hw_ctrl_set().
A TX trigger selected without a link trigger therefore programs the RX
blink bits, and the LED blinks on received traffic. The masks are also
used to decode the blink register in mtk_phy_led_hw_ctrl_get(), which
as a result cannot tell the two triggers apart: an RX-only
configuration reads back as RX and TX, and a TX-only configuration
reads back as neither.
Fixes: 7f9c320c98 ("net: phy: mediatek: Move LED helper functions into mtk phy lib")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260804113511.3371248-1-naseefkm@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
struct bvec_iter::bi_bvec_done is used an offset in the current bvec,
let's rename it accordingly for better clarity. I also plan to use it
for non-bvec based iteration in the future like dma-buf, so drop the
"bvec" part.
Suggested-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/4e4c21858705a200bd8848ffe4080522e3eb5c1c.1786018753.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Charles Keepax <ckeepax@opensource.cirrus.com> says:
This series reworks the SDCA HID code, the primary goals being to no
longer store runtime HID data in the DisCo data structures and remove
the need to pass the soundwire device into the ACPI parsing code.
To achieve this the HID device registration is moved to the IRQ work
flow rather than the ACPI work flow.
Also a few small issues are fixed up along the way, some formatting,
some missing cleanup/docs.
Link: https://patch.msgid.link/20260805124205.4152543-1-ckeepax@opensource.cirrus.com
Rather than passing the SoundWire slave into find_sdca_filesets(),
stash the swift table whilst processing sdca_dev_register(). This
allows us to completely remove the passing of the sdw_slave into
the ACPI parsing code.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-9-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing kernel doc for the function sdca_add_hid_device()
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SDCA code is currently missing a cleanup for HID devices when the
drivers are unbound. Add the missing HID cleanup as part of the IRQ
cleanup to mirror when the HID device is created.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add more error checking on the parsing of the HID DisCo and bring
the code more inline with the rest of the DisCo parsing.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The HID descriptors are defined at the function level in DisCo
and as such it makes more sense to parse and store them at
that level in the SDCA code. This shouldn't really make much
practical difference but is conceptually better and avoids
passing the function node down to the entity parsing code.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the SDCA code registers the HID device whilst parsing
the DisCo information. This necessitates storing the HID device
in the DisCo structs, which are intended to only store the parsed
DisCo. Having the HID device registered so early in the process
also causes some issues with cleaning up.
Update the code to register the HID device as the IRQs are handled,
this alleviates the previous concerns and brings the support inline
with the other SDCA event handling.
As part of this move the naming for the SDCA HID is also updated,
it saves some complexity around the passing of the SoundWire device
to include this in this patch. Update to using the dev_name for
the phys, which is more consistent with other HID users, and use
the actual function name/address for the HID name itself.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the now unused device pointer from
sdca_asoc_pde_poll_actual_ps().
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bring the entity_pde_event() error message slightly more in line with
the other SDCA error messages.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260805124205.4152543-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The resume clearance test skipped every other allocation, expecting an
interleaved clear/dirty layout. But the buddy allocator hands out blocks
contiguously, so this just allocated half the pages in one chunk and never
exercised gpu_buddy_reset_clear()'s force-merge of opposite-state buddies.
Allocate all pages into two lists instead and free one cleared, one dirty,
to build a truly interleaved pattern.
v2: Use for loops instead of do-while for the allocation loops (Jani Nikula)
Fixes: e3335ccbf4 ("drm/tests/gpu_buddy: add a new test case for buffer clearance during resume")
Reported-by: Sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260721114236.507578-1-Arunpravin.PaneerSelvam@amd.com?part=1
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Christian König <christian.koenig@amd.com>
Assisted-by: GitHub_Copilot:claude-opus-4.8
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260803065656.2960810-1-Arunpravin.PaneerSelvam@amd.com
Add ID_AA64MMFR2_EL1.BBM based BBML3 feature detection in
cpu_supports_bbml3() so that cpus with the feature would
not have to be added into MIDR based supports_bbml3_list.
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
[will: Tidy up cpu_supports_bbml3()]
Signed-off-by: Will Deacon <will@kernel.org>
- As bbml2_noabort is functionally equivalent to bbml3,
rename cpu/system_supports_bbml2_noabort to
cpu/system_supports_bbml3.
The ARM64 capability name is also renamed accordingly.
- As BBML2_NOABORT or the equivalent BBML3 is the
kernel requirement for setting up linear map with
block/contpte mappings and not BBML2, replace all
bbml2 references with bbml3.
FEAT_BBML3, is introduced as part of 2025 Architecture Extensions.
https://developer.arm.com/documentation/109697/2026_03/2025-Architecture-Extensions
No functional changes are introduced with this patch.
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add below cpus to the midr list, which supports
BBML2_NOABORT.
Cortex A520(AE)
Cortex A715
Cortex A720(AE)
Cortex A725
Neoverse N3
C1-Nano
C1-Pro
C1-Ultra
C1-Premium
C1-Ultra and C1-Premium both suffer from erratum 3683289,
where Break-Before-Make must be followed to avoid a livelock.
For both CPUs, the erratum is fixed from r1p1.
Hence we do not enable BBML2_NOABORT for CPU revisions <= r1p0.
The relevant SDENs are:
* C1-Ultra: https://developer.arm.com/documentation/111077/9-00/
* C1-Premium: https://developer.arm.com/documentation/111078/9-00/
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add cputype definitions for C1-Nano.
The definition can be found in C1-Nano TRM,
https://developer.arm.com/documentation/107753/0002
as part of MIDR_EL1 bit descriptions.
This is going to be used in the bbml3 support list.
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add cputype definitions for Cortex-A520AE.
The definition can be found in Cortex-A520AE TRM,
https://developer.arm.com/documentation/107726/0001/
as part of MIDR_EL1 bit descriptions.
This is going to be used in the bbml3 support list.
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
nxpwifi_uap_event_sta_assoc() exposes the association request IEs that
the firmware reports in the uAP association event, which the driver
copies into the fixed-size event_body[] buffer.
event->len is supplied by firmware and is not validated. A value smaller
than the header underflows the subtraction used for assoc_req_ies_len,
while a larger value can make the IE range extend beyond event_body[].
Subsequent IE parsing can then read past the adapter object.
Validate both bounds before using the firmware-reported length.
nxpwifi was derived from mwifiex before commit f0858bfc7d ("wifi:
mwifiex: bound uAP association event IEs to the event buffer") and
retains the same unchecked length. Apply the equivalent bounds check
here.
Fixes: 73b01e57ed ("wifi: nxp: add nxpwifi driver for IW61x")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com>
Link: https://patch.msgid.link/20260729082457.1897303-1-lilinmao@kylinos.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nxpwifi synchronous commands keep the caller-provided data buffer in
cmd_node->data_buf. Several callers pass stack-allocated objects there,
for example nxpwifi_get_chan_type() and the timeshare_coex debugfs
handlers.
If wait_event_interruptible_timeout() is interrupted or times out, the
caller can return and release that stack object while the command is still
current. nxpwifi_cancel_all_pending_cmd() deliberately keeps the current
command because a response may still arrive. A late firmware response can
then write through cmd_node->data_buf into the stale stack address.
After cancelling pending commands, detach the caller-owned buffer from the
still-current command under nxpwifi_cmd_lock.
Unlike the host command response path, several command response callbacks
do not tolerate a NULL data buffer. Most of them ignore it or check it
already, but nxpwifi_ret_sta_get_chan_info(),
nxpwifi_ret_sta_hs_wakeup_reason() and nxpwifi_ret_sta_robust_coex()
dereference it unconditionally, so let them discard a detached response.
No caller passes a NULL buffer to these commands today, so this only
affects the newly introduced detached state.
nxpwifi was derived from mwifiex before commit ef06882c7d ("wifi:
mwifiex: Detach sync cmd buffer on interrupted wait") and retains the same
lifetime bug. Apply the equivalent buffer detachment here.
Fixes: 73b01e57ed ("wifi: nxp: add nxpwifi driver for IW61x")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Link: https://patch.msgid.link/20260729124713.2849018-1-lilinmao@kylinos.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The memory allocated for buf is not freed in some of the error paths in
brcmf_sdio_read_control(). Fix that by adding vfree() calls.
Cc: stable@vger.kernel.org
Fixes: dd43a01c5c ("brcmfmac: use dynamically allocated control frame buffer")
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
[arend: rework as suggested by Johannes]
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260803093506.1647790-1-arend.vanspriel@broadcom.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Avoids errors like:
CFI failure at kthread+0x124/0x1cc (target: rsi_coex_scheduler_thread+0x0/0x1b4 [redpine_91x]; expected type: 0x89fb613d)
As seen in the aforementioned error this was tested using the downstream
redpine_91x driver found in the Librem 5's downstream source tree.
However, it appears that this driver is a modified version of the rsi
driver found in mainline Linux and as such I decided to port the changes
here too.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Link: https://patch.msgid.link/20260804-rsi-cfi-fix-v2-1-59679a520240@postmarketos.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
AP_VLAN interfaces are never passed to the driver, so setting default WMM
parameters on their links trips the check-sdata-in-driver warning in
drv_conf_tx(), as well as in the BSS_CHANGED_QOS link info notification.
Skip it, matching the existing AP_VLAN handling in this function.
Fixes: 2259d14499 ("wifi: mac80211: set default WMM parameters on all links")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://patch.msgid.link/20260804082608.2011433-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix various development-phase bugs, code quality, and logical issues
reported by the kernel test robot (using the Smatch static analysis tool).
The following addressable fixes are included:
- 11n.c & 11ax.c: Fix potential NULL pointer dereferences by correcting
logical operators (&& to ||) in 11n.c and hoisting the bss_desc
verification to the top of the function in 11ax.c.
- 11n.c: Fix a severe Use-After-Free (UAF) memory corruption during RCU
list traversal. Restore the proper list_for_each_entry_safe() loop
structure along with the required array index [i] within the locked
writer path.
- sdio.c: Fix a missing unwind resource cleanup pathway where a protocol
error branch returned directly via -EINVAL instead of using
'goto term_cmd', leaving the SDIO hardware state machine out of sync.
- main.h: Fix a signedness mismatch bug where nxpwifi_get_unused_bss_num()
could return -2 as an unsigned integer fallback.
- util.c: Remove a redundant and dead condition check (position <= 15)
which was always true for a 4-bit unsigned bit-field member variable.
- cfg80211.c: Clean up a dead unreachable 'return 0' at the bottom of the
switch-case logic.
- uap_txrx.c: Clean up mismatched and inconsistent indentations within the
handling of multicast RX forward paths.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608020855.QwN5n7i5-lkp@intel.com/
Assisted-by: Gemini:unknown-model
Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
Link: https://patch.msgid.link/20260803162741.438820-1-chunfan.chen@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
regcache_lookup_reg() bsearch()es the reg_defaults array, which requires
it to be sorted by ascending register address. Entries following a
descending step are never found, so regcache_reg_needs_sync() reports
that they need a sync and they are written to the device on every
regcache_sync() even when they were never touched.
Detect the misordering while reg_defaults is validated against the
register stride and sort the local copy. The check needs no new loop
and sort() only runs for the affected drivers, which are also warned
about.
Note that sort() is not stable, so for arrays with duplicated register
addresses it remains unspecified which entry is found.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260805132250.2637-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Morse Micro MM81x wireless devices can have either SDIO or USB
interfaces. Hence there is no point in asking the user about these
devices when configuring a kernel without MMC or USB support.
Fix this by making the core driver symbol invisible, and selecting it by
its users when needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/3415bda97c2faf7c56eff7fe79a91b218d0d6731.1786010705.git.geert+renesas@glider.be
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All supported NXP WiFi wireless adapters have an SDIO interface.
Hence there is no point in asking the user about these adapters when
configuring a kernel without MMC support.
Fix this by making the core driver symbol invisible, and selecting it by
its user when needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/aefb37d8398175cb2fb520cb5f725a85bcd3049d.1786010763.git.geert+renesas@glider.be
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For ath12k, add MultiPD support for AHB platforms. Other than that, just an
assortment of cleanups and minor bug fixes across ath6kl, ath10k, ath11k,
and ath12k.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCanD6QAAKCRAsFbugiYzL
e5bZAQCZ1l//G7lH+MkmGZwH0GavyIW080lhoG4TRJ6k2apRvwEA2jKq7vH8zWmQ
suLqJ7n8a2rXVG0cUtnhOmgsTOcqbwc=
=h/4C
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260803' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.3 (PR #2)
For ath12k, add MultiPD support for AHB platforms. Other than that, just an
assortment of cleanups and minor bug fixes across ath6kl, ath10k, ath11k,
and ath12k.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we look up registers in the defaults table we use a binary search,
and we have a regcache_sort_defaults() API to help drivers that constuct
their defaults tables on the fly. Unfortunately the lookup and the sort
don't use the same comparison function, and to make matters worse the
comparison function used during lookups is written for signed register
numbers rather than the unsigned ones we actually have so can produce
suprising results when some of the addresses have the top bit set.
Standardise on the more explicitly coded function to ensure consistent
results.
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260805-regmap-regcache-sort-v1-1-162186aad8b9@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
A moderately large set of fixes, but mostly unremarkable:
- A series of robustness fixes for the SOF code that came from testing.
- Fixes for user visible issues with some of the Qualcomm controls.
- Fixes to the register default tables in Cirrus drivers which ensure
correcy syncing on resume. This is a wider problem which will be
fixed with a regmap core change but I'd already applied these, the
rest of the fixes will come in the merge window.
- Making the existing RT645 driver user selectable so it can be used
with more machines.
- Quite a few new AMD laptop quirks.
- A MAINTAINERS update for SpacemiT.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp0dMAACgkQJNaLcl1U
h9BEeQf/bQaIhsd0toM97B3EJa2prc/KX4rYXIk3cCzvqH9xvkxj1q+SRx8YJXeT
xmVGBW6fnqzcZERjwuaKR4VrvsMOoNQh/ZCJZB3qc9az+D4ICHR/8gpxbWFLsdJf
BTmiqZtq+LrjN1Y8cpPSJuExP6H4k+ZQlhseAZA744NktxcXnB0Mr4B1AlAhSoGY
3KYPTEBvQ6Zk8kF8iUiipx0UV5KA8xGS3kd3dR3ywrX+FcslWzLKyiT891azeobr
STs4X2gHtlEsJEz65uKt8fO33RPROlLRainCbG5kOzEkiNNXfYhljl1uZanLW2pX
PlJvm5DyWqeBYDEsAKYTzMQ8YJ+s/g==
=9/a9
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.2-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.2
A moderately large set of fixes, but mostly unremarkable:
- A series of robustness fixes for the SOF code that came from testing.
- Fixes for user visible issues with some of the Qualcomm controls.
- Fixes to the register default tables in Cirrus drivers which ensure
correcy syncing on resume. This is a wider problem which will be
fixed with a regmap core change but I'd already applied these, the
rest of the fixes will come in the merge window.
- Making the existing RT645 driver user selectable so it can be used
with more machines.
- Quite a few new AMD laptop quirks.
- A MAINTAINERS update for SpacemiT.
metadata_take_snap() bumps the live superblock refcount and then
dm_tm_shadow_block() allocates a new block for the metadata snapshot.
If the subsequent dm_sm_inc_block() of writeset_tree_root or
era_array_root fails, the function only unlocks the clone and
returns. The newly allocated shadow block is never returned to the
metadata space map, so each failed take-snap permanently leaks one
metadata block.
Free the clone with dm_sm_dec_block() on those error paths, matching
the final step of metadata_drop_snap().
Fixes: eec40579d8 ("dm: add era target")
Cc: stable@vger.kernel.org
Signed-off-by: liyouhong <liyouhong@kylinos.cn>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Sparse reports several warnings about incorrect type in assignment
(different base types) when building the i2c-viperboard.c driver:
warning: incorrect type in assignment (different base types)
expected unsigned short [usertype] addr
got restricted __le16 [usertype]
Signed-off-by: Mikhail Lukianchikov <avermoal@gmail.com>
Link: https://patch.msgid.link/20260717121015.11666-2-avermoal@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
pte_present() is used as the basis for both pmd_present() and pud_present().
It is currently implemented as a macro composed of pte_val() and
pte_present_invalid().
When pte_present() or its higher-level variants are used directly with
ptep_get() or pXdp_get(), for example:
pte_present(ptep_get(pte));
pmd_present(pmdp_get(pmd));
pud_present(pudp_get(pud));
the macro expansion causes the compiler to evaluate the argument twice,
resulting in redundant loads. For example, pte_present() expands to:
!pte_val(READ_ONCE(*pte) || pte_present_invalid(READ_ONCE(*pte))
A typical example is pud_free_pmd_page(), where the expansion of
pmd_present() generates:
...
/* pmd_present() (x20 = pmdp) */
1b88: f9400288 ldr x8, [x20] // read pmdp.
1b8c: f9000fa8 str x8, [x29, #0x18]
1b90: 3707fec8 tbnz w8, #0x0, 0x1b68 <pud_free_pmd_page+0xd0>
1b94: f9400288 ldr x8, [x20] // redundant read of pmdp.
1b98: 8a170109 and x9, x8, x23
1b9c: f9000fa8 str x8, [x29, #0x18]
1ba0: f120013f cmp x9, #0x800
1ba4: 54fffe20 b.eq 0x1b68 <pud_free_pmd_page+0xd0>
1ba8: 17fffff4 b 0x1b78 <pud_free_pmd_page+0xe0>
...
Convert pte_present() to static inline function so that prevent the
generation of redundant code and move pte_valid() and
pte_present_invalid() further up so the inline function can use them.
After this change, the generated code becomes:
...
/* pmd_present() (x20 = pmdp) */
1a30: f9400288 ldr x8, [x20]
1a34: 8a170109 and x9, x8, x23
1a38: f9000fa8 str x8, [x29, #0x18]
1a3c: f120013f cmp x9, #0x800
1a40: 54fffe80 b.eq 0x1a10 <pud_free_pmd_page+0xd0>
1a44: 3607fee8 tbz w8, #0x0, 0x1a20 <pud_free_pmd_page+0xe0>
1a48: 17fffff2 b 0x1a10 <pud_free_pmd_page+0xd0>
...
This eliminates the redundant load and also reduces code size at
call sites using this pattern. For example, pud_free_pmd_page() shrinks
from 7,500 bytes to 7,148 bytes, a reduction of approximately 4.7%.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
The 64-bit Programmers' model extension, now named FEAT_CSPMU_EXT64,
makes all the non-counter registers 64-bit as well, of which we most
need to care PMEVFILTR<n>, PMEVTYPER<n>, and PMCR since it changes
location. Our event config fields are ready for this internally, but
we need a few more tweaks to propagate 64-bit values properly from
end to end.
Since 64-bit events leave no room for our existing "cycles" encoding,
and we don't really expect to see implementations of it anyway, we
deliberately omit generic support for the architectural fixed cycle
counter in this case to save some bother. At worst, vendor modules
can still implement their own encoding if they really want to.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add the compatible string for the APPS SMMU present on the Qualcomm
IPQ9650 SoC.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Will Deacon <will@kernel.org>
