Andrei Lalaev [Mon, 21 Jul 2025 15:57:37 +0000 (17:57 +0200)]
gpiolib: of: add forward declaration for struct device_node
Commit 08a149c40bdb ("gpiolib: Clean up headers") added a forward
declaration for struct device.
Later, commit 07445ae1c263 ("gpiolib: of: change of_find_gpio() to
accept device node") changed the function signature to accept a struct
device_node instead of a struct device.
Replace forward declaration of struct device with struct device_node to
match the updated function signature.
of_node_to_fwnode() is an irqdomain's reimplementation of the
"officially" defined of_fwnode_handle(). The former is in the process of
being removed, so use the latter instead.
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
Randy Dunlap [Tue, 22 Jul 2025 23:54:31 +0000 (16:54 -0700)]
pc104: move PC104 option to drivers/Kconfig
Put the PC104 kconfig option in drivers/Kconfig along with
other buses (AMBA, EISA, PCI, CXL, PCCard, & RapidIO).
This localizes PC104 with option bus kconfig options to make
it easier to find.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: William Breathitt Gray <wbg@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250722235431.3671754-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Weißschuh [Fri, 18 Jul 2025 13:43:49 +0000 (15:43 +0200)]
drivers: virt: acrn: Don't use %pK through printk
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
Jonas Karlman [Wed, 23 Jul 2025 08:56:46 +0000 (08:56 +0000)]
dt-bindings: serial: snps-dw-apb-uart: Allow use of a power-domain
The UART controllers in most Rockchip SoCs are part of power domains
that are always powered on. These always powered on power domains have
typically not been described in the device tree.
Because these power domains have been left out of the device tree there
has not been any real need to properly describe the UART controllers
power domain of Rockchip SoCs.
On Rockchip RK3528 the UART controllers are spread out among the
described PD_RKVENC, PD_VO and PD_VPU power domains. However, one UART
controller belong to an undescribed always powered on power domain.
Add support to describe an optional power-domains for the UART
controllers.
Yunhui Cui [Wed, 23 Jul 2025 02:33:22 +0000 (10:33 +0800)]
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p->fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==
(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock
to fix this issue.
usb: atm: cxacru: Merge cxacru_upload_firmware() into cxacru_heavy_init()
After a recent change in clang to expose uninitialized warnings from
const variables [1], there is a warning in cxacru_heavy_init():
drivers/usb/atm/cxacru.c:1104:6: error: variable 'bp' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1104 | if (instance->modem_type->boot_rom_patch) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/atm/cxacru.c:1113:39: note: uninitialized use occurs here
1113 | cxacru_upload_firmware(instance, fw, bp);
| ^~
drivers/usb/atm/cxacru.c:1104:2: note: remove the 'if' if its condition is always true
1104 | if (instance->modem_type->boot_rom_patch) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/atm/cxacru.c:1095:32: note: initialize the variable 'bp' to silence this warning
1095 | const struct firmware *fw, *bp;
| ^
| = NULL
While the warning is technically correct that bp is conditionally passed
uninitialized to cxacru_upload_firmware(), it is ultimately a false
positive warning on the uninitialized use of bp because the same
condition that initializes bp, instance->modem_type->boot_rom_patch, is
the same one that gates the use of bp within cxacru_upload_firmware().
As this warning occurs in clang's frontend before inlining occurs, it
cannot know that these conditions are indentical to avoid the warning.
Manually inline cxacru_upload_firmware() into cxacru_heavy_init(), as
that is its only callsite, so that clang can see that bp is initialized
and used under the same condition, clearing up the warning without any
functional changes to the code (LLVM was already doing this inlining
later).
Ali Nasrolahi [Wed, 23 Jul 2025 04:19:21 +0000 (07:49 +0330)]
staging: rtl8723bs: remove redundant semicolon in basic_types.h
The macro SET_BITS_TO_LE_2BYTE ends with a semicolon inside its definition,
which can lead to an extra semicolon when used, resulting in inconsistent
formatting or potential warnings.
This patch removes the redundant semicolon to comply with kernel macro
style guidelines and improve readability.
staging: rtl8723bs: clean up redundant & parentheses
Cleaned up redundant parentheses around the '&' (address-of)
operator in various expressions to improve code readability
and comply with kernel coding style guidelines.
staging: axis-fifo: add debugfs interface for dumping fifo registers
For debugging purposes, add a simple, read-only debugfs interface to dump
the following fifo registers:
ISR - Interrupt Status Register
IER - Interrupt Enable Register
TDFV - Transmit Data FIFO Vacancy
RDFO - Receive Data FIFO Occupancy
Unhandled fault: imprecise external abort (0x1406) at 0xaec8d000
[aec8d000] *pgd=03f74831, *pte=0525c75f, *ppte=0525cc7f
Internal error: Oops - BUG: 1406 [#1] SMP ARM
Hardware name: Xilinx Zynq Platform
PC is at sysfs_read+0xc4/0xd8
LR is at dev_attr_show+0x6c/0xc0
pc : [<c0ff9298>] lr : [<c0adad38>] psr: 60070013
sp : e09abd18 ip : c3193000 fp : c0adaccc
r10: 00000000 r9 : c3192000 r8 : 183abab5
r7 : c1d5d5a8 r6 : c2d71440 r5 : 00000024 r4 : c3192000
r3 : e0a60024 r2 : 00000000 r1 : c3192000 r0 : c2d71444
...
Call trace:
sysfs_read from dev_attr_show+0x6c/0xc0
dev_attr_show from sysfs_kf_seq_show+0x270/0x360
sysfs_kf_seq_show from seq_read_iter+0x7f4/0x10bc
seq_read_iter from vfs_read+0x350/0x3d0
vfs_read from ksys_read+0x104/0x194
ksys_read from ret_fast_syscall+0x0/0x54
The same abort is triggered if a read is attempted on RDFD register when
the fifo is empty.
Therefore, remove the sysfs interface and only let read()/write() modify
the fifo registers. For debugging purposes, a simple read-only debugfs
interface is added in the next patch.
staging: nvec: Fix incorrect null termination of battery manufacturer
The battery manufacturer string was incorrectly null terminated using
bat_model instead of bat_manu. This could result in an unintended
write to the wrong field and potentially incorrect behavior.
fixe the issue by correctly null terminating the bat_manu string.
Fixes: 32890b983086 ("Staging: initial version of the nvec driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20250719080755.3954373-1-alok.a.tiwari@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: hns3: default enable tx bounce buffer when smmu enabled
The SMMU engine on HIP09 chip has a hardware issue.
SMMU pagetable prefetch features may prefetch and use a invalid PTE
even the PTE is valid at that time. This will cause the device trigger
fake pagefaults. The solution is to avoid prefetching by adding a
SYNC command when smmu mapping a iova. But the performance of nic has a
sharp drop. Then we do this workaround, always enable tx bounce buffer,
avoid mapping/unmapping on TX path.
This issue only affects HNS3, so we always enable
tx bounce buffer when smmu enabled to improve performance.
Fixes: 295ba232a8c3 ("net: hns3: add device version to replace pci revision") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250722125423.1270673-5-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, the queried maximum of vf channels is the maximum of channels
supported by each TC. However, the actual maximum of channels is
the maximum of channels supported by the device.
Fixes: 849e46077689 ("net: hns3: add ethtool_ops.get_channels support for VF") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250722125423.1270673-4-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The vport->req_vlan_fltr_en may be changed concurrently by function
hclge_sync_vlan_fltr_state() called in periodic work task and
function hclge_enable_vport_vlan_filter() called by user configuration.
It may cause the user configuration inoperative. Fixes it by protect
the vport->req_vlan_fltr by vport_lock.
Fixes: 2ba306627f59 ("net: hns3: add support for modify VLAN filter state") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250722125423.1270673-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Thomas Huth [Mon, 21 Jul 2025 10:15:37 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the GFDL-1.2
The FSF does not reside in the Franklin street anymore. Let's update
the address with the link to their website, as suggested in the latest
revisions of their GFDL-1.2 license:
https://www.gnu.org/licenses/old-licenses/fdl-1.2.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Mon, 21 Jul 2025 10:15:36 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the GFDL-1.1
The FSF does not reside in the Franklin street anymore. Let's update
the address with the link to their website, as suggested in the latest
revisions of their GFDL-1.1 license:
https://www.gnu.org/licenses/old-licenses/fdl-1.1.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Mon, 21 Jul 2025 10:15:35 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the LGPL-2.1
The FSF does not reside in the Franklin street anymore. Let's update
the address with the link to their website, as suggested in the latest
revisions of their LGPL-2.1 license:
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Mon, 21 Jul 2025 10:15:34 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the LGPL-2.0
The FSF does not reside in the Franklin street anymore. Let's update
the address with the link to their website, as suggested in the latest
revisions of their LGPL-2.0 license:
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Mon, 21 Jul 2025 10:15:33 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the GPL-2.0
The FSF does not reside in the Franklin street anymore. Let's update
the address with the link to their website, as suggested in the latest
revisions of their GPL-2.0 license:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Mon, 21 Jul 2025 10:15:32 +0000 (12:15 +0200)]
LICENSES: Replace the obsolete address of the FSF in the GPL-1.0
The FSF does not reside in the Mass Ave anymore. Let's update the
address with the link to their website, as suggested in the latest
revisions of their GPL-1.0 license:
https://www.gnu.org/licenses/old-licenses/gpl-1.0.txt
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Halil Pasic [Tue, 22 Jul 2025 16:18:17 +0000 (18:18 +0200)]
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one
request-response sequence is allowable per ISM function at any point in
time. Unfortunately as of today the s390/ism driver in Linux does not
honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states
that for certain workloads the ISM functions end up entering error state
(with PEC 2 as seen from the logs) after a while and as a consequence
connections handled by the respective function break, and for future
connection requests the ISM device is not considered -- given it is in a
dysfunctional state. During further debugging PEC 3A was observed as
well.
A kernel message like
[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a
is a reliable indicator of the stated function entering error state
with PEC 2. Let me also point out that a kernel message like
[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery
is a reliable indicator that the ISM function won't be auto-recovered
because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to
the FW) may be partially or fully overwritten (corrupted) by another CPU
trying to issue commands on the same function. There is hard evidence that
this can lead to DMB token values being used as DMB IOVAs, leading to
PEC 2 PCI events indicating invalid DMA. But this is only one of the
failure modes imaginable. In theory even completely losing one command
and executing another one twice and then trying to interpret the outputs
as if the command we intended to execute was actually executed and not
the other one is also possible. Frankly, I don't feel confident about
providing an exhaustive list of possible consequences.
Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory") Reported-by: Aliaksei Makarau <Aliaksei.Makarau@ibm.com> Tested-by: Mahanta Jambigi <mjambigi@linux.ibm.com> Tested-by: Aliaksei Makarau <Aliaksei.Makarau@ibm.com> Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250722161817.1298473-1-wintera@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Hector Martin [Tue, 10 Jun 2025 15:29:48 +0000 (15:29 +0000)]
power: reset: macsmc-reboot: Add driver for rebooting via Apple SMC
This driver implements the reboot/shutdown support exposed by the SMC
on Apple Silicon machines, such as Apple M1 Macs.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-7-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
Hector Martin [Tue, 10 Jun 2025 15:29:47 +0000 (15:29 +0000)]
gpio: Add new gpio-macsmc driver for Apple Macs
This driver implements the GPIO service on top of the SMC framework
on Apple Mac machines. In particular, these are the GPIOs present in the
PMU IC which are used to control power to certain on-board devices.
Although the underlying hardware supports various pin config settings
(input/output, open drain, etc.), this driver does not implement that
functionality and leaves it up to the firmware to configure things
properly. We also don't yet support interrupts/events. This is
sufficient for device power control, which is the only thing we need to
support at this point. More features will be implemented when needed.
To our knowledge, only Apple Silicon Macs implement this SMC feature.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-6-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
Sven Peter [Tue, 10 Jun 2025 15:29:46 +0000 (15:29 +0000)]
mfd: Add Apple Silicon System Management Controller
The System Management Controller (SMC) on Apple Silicon machines is a
piece of hardware that exposes various functionalities such as
temperature sensors, voltage/power meters, shutdown/reboot handling,
GPIOs and more.
Communication happens via a shared mailbox using the RTKit protocol
which is also used for other co-processors. The SMC protocol then allows
reading and writing many different keys which implement the various
features. The MFD core device handles this protocol and exposes it
to the sub-devices.
Some of the sub-devices are potentially also useful on pre-M1 Apple
machines and support for SMCs on these machines can be added at a later
time.
Co-developed-by: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-5-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
hwmon: add support for MC33XS2410 hardware monitoring
The device is able to monitor temperature, voltage and current of each of
the four outputs. Add basic support for monitoring the temperature of the
four outputs and the die temperature.
ssb: use new GPIO line value setter callbacks for the second GPIO chip
Because the other chip is guarded in an unlikely ifdef, I missed it when
converting this driver. Fix it now.
Fixes: 757259db79fc ("ssb: use new GPIO line value setter callbacks") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://patch.msgid.link/20250723141257.51412-1-brgl@bgdev.pl Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Marc Zyngier [Tue, 1 Jul 2025 15:16:48 +0000 (16:16 +0100)]
KVM: arm64: Follow specification when implementing WXN
The R_QXXPC and R_NPBXC rules have some interesting (and pretty
sharp) corners when defining the behaviour of of WXN at S1:
- when S1 overlay is enabled, WXN applies to the overlay and
will remove W
- when S1 overlay is disabled, WXN applies to the base permissions
and will remove X.
Today, we lumb the two together in a way that doesn't really match
the rules, making things awkward to follow what is happening, in
particular when overlays are enabled.
Split these two rules over two distinct paths, which makes things
a lot easier to read and validate against the architecture rules.
Marc Zyngier [Tue, 1 Jul 2025 15:16:47 +0000 (16:16 +0100)]
KVM: arm64: Remove the wi->{e0,}poe vs wr->{p,u}ov confusion
Some of the POE computation is a bit confused. Specifically, there
is an element of confusion between what wi->{e0,}poe an wr->{p,u}ov
actually represent.
- wi->{e0,}poe is an *input* to the walk, and indicates whether
POE is enabled at EL0 or EL{1,2}
- wr->{p,u}ov is a *result* of the walk, and indicates whether
overlays are enabled. Crutially, it is possible to have POE
enabled, and yet overlays disabled, while the converse isn't
true
What this all means is that once the base permissions have been
established, checking for wi->{e0,}poe makes little sense, because
the truth about overlays resides in wr->{p,u}ov. So constructs
checking for (wi->poe && wr->pov) only add perplexity.
Refactor compute_s1_overlay_permissions() and the way it is
called according to the above principles. Take the opportunity
to avoid reading registers that are not strictly required.
David Woodhouse [Mon, 23 Jun 2025 13:22:52 +0000 (15:22 +0200)]
KVM: arm64: vgic-its: Return -ENXIO to invalid KVM_DEV_ARM_VGIC_GRP_CTRL attrs
A preliminary version of a hack to invoke unmap_all_vpes() from an ioctl
didn't work very well. We eventually determined this was because we were
invoking it on the wrong file descriptor, but not getting an error.
Merge tag 'icc-6.17-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next
Georgi writes:
interconnect changes for 6.17
This pull request contains the interconnect changes for the 6.17-rc1
merge window. It contains only driver changes.
Driver changes:
- SC8180X and SC8280XP driver fixes
- Add new driver for the Qualcomm Milos SoC
- Add Support for EPSS L3 hardware in QCS8300 SoC
- DT bindings fixes and other cleanups
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* tag 'icc-6.17-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: qcom: Add Milos interconnect provider driver
dt-bindings: interconnect: document the RPMh Network-On-Chip Interconnect in Qualcomm Milos SoC
dt-bindings: interconnect: qcom,msm8998-bwmon: Allow 'nonposted-mmio'
dt-bindings: interconnect: Add EPSS L3 compatible for QCS8300 SoC
dt-bindings: interconnect: qcom: Remove double colon from description
interconnect: qcom: qcs615: Drop IP0 interconnects
interconnect: qcom: sc8180x: specify num_nodes
interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg
Paul Chaignon [Tue, 22 Jul 2025 14:33:37 +0000 (16:33 +0200)]
selftests/bpf: Test invalid narrower ctx load
This patch adds selftests to cover invalid narrower loads on the
context. These used to cause kernel warnings before the previous patch.
To trigger the warning, the load had to be aligned, to read an affected
context field (ex., skb->sk), and not starting at the beginning of the
field.
The nine new cases all fail without the previous patch.
Paul Chaignon [Tue, 22 Jul 2025 14:32:32 +0000 (16:32 +0200)]
bpf: Reject narrower access to pointer ctx fields
The following BPF program, simplified from a syzkaller repro, causes a
kernel warning:
r0 = *(u8 *)(r1 + 169);
exit;
With pointer field sk being at offset 168 in __sk_buff. This access is
detected as a narrower read in bpf_skb_is_valid_access because it
doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed
and later proceeds to bpf_convert_ctx_access. Note that for the
"is_narrower_load" case in the convert_ctx_accesses(), the insn->off
is aligned, so the cnt may not be 0 because it matches the
offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,
the target_size stays 0 and the verifier errors with a kernel warning:
verifier bug: error during ctx access conversion(1)
This patch fixes that to return a proper "invalid bpf_context access
off=X size=Y" error on the load instruction.
The same issue affects multiple other fields in context structures that
allow narrow access. Some other non-affected fields (for sk_msg,
sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for
consistency.
Note this syzkaller crash was reported in the "Closes" link below, which
used to be about a different bug, fixed in
commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions
in insn_def_regno()"). Because syzbot somehow confused the two bugs,
the new crash and repro didn't get reported to the mailing list.
Fixes: f96da09473b52 ("bpf: simplify narrower ctx access") Fixes: 0df1a55afa832 ("bpf: Warn on internal verifier errors") Reported-by: syzbot+0ef84a7bdf5301d4cbec@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ef84a7bdf5301d4cbec Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://patch.msgid.link/3b8dcee67ff4296903351a974ddd9c4dca768b64.1753194596.git.paul.chaignon@gmail.com
Merge tag 'drm-fixes-2025-07-24' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"This might just be part one, but I'm sending it a bit early as it has
two sets of reverts for regressions, one is all the gem/dma-buf
handling and another was a nouveau ioctl change.
Otherwise there is an amdgpu fix, nouveau fix and a scheduler fix.
If any other changes come in I'll follow up with another more usual
Fri/Sat MR.
gem:
- revert all the dma-buf/gem changes as there as lifetime issues
with them
nouveau:
- revert an ioctl change as it causes issues
- fix NULL ptr on fermi
bridge:
- remove extra semicolon
sched:
- remove hang causing optimisation
amdgpu:
- fix garbage in cleared vram after resume"
* tag 'drm-fixes-2025-07-24' of https://gitlab.freedesktop.org/drm/kernel:
drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe()
Revert "drm/nouveau: check ioctl command codes better"
drm/nouveau/nvif: fix null ptr deref on pre-fermi boards
Revert "drm/gem-dma: Use dma_buf from GEM object instance"
Revert "drm/gem-shmem: Use dma_buf from GEM object instance"
Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance"
Revert "drm/prime: Use dma_buf from GEM object instance"
Revert "drm/etnaviv: Use dma_buf from GEM object instance"
Revert "drm/vmwgfx: Use dma_buf from GEM object instance"
Revert "drm/virtio: Use dma_buf from GEM object instance"
drm/sched: Remove optimization that causes hang when killing dependent jobs
drm/amdgpu: Reset the clear flag in buddy during resume
selftests: drv-net: wait for iperf client to stop sending
A few packets may still be sent out during the termination of iperf
processes. These late packets cause failures in rss_ctx.py when they
arrive on queues expected to be empty.
Jakub Kicinski [Thu, 24 Jul 2025 00:52:10 +0000 (17:52 -0700)]
Merge branch 'dualpi2-patch'
Chia-Yu Chang says:
====================
DUALPI2 patch
This patch serise adds DualPI Improved with a Square (DualPI2) with
following features:
* Supports congestion controls that comply with the Prague requirements
in RFC9331 (e.g. TCP-Prague)
* Coupled dual-queue that separates the L4S traffic in a low latency
queue (L-queue), without harming remaining traffic that is scheduled
in classic queue (C-queue) due to congestion-coupling using PI2
as defined in RFC9332
* Configurable overload strategies
* Use of sojourn time to reliably estimate queue delay
* Supports ECN L4S-identifier (IP.ECN==0b*1) to classify traffic into
respective queues
For more details of DualPI2, please refer IETF RFC9332
(https://datatracker.ietf.org/doc/html/rfc9332).
====================
Introduce the specification of tc qdisc DualPI2 stats and attributes,
which is the reference implementation of IETF RFC9332 DualQ Coupled AQM
(https://datatracker.ietf.org/doc/html/rfc9332) providing two different
queues: low latency queue (L-queue) and classic queue (C-queue).
selftests/tc-testing: Add selftests for qdisc DualPI2
Update configuration of tc-tests and preload DualPI2 module for self-tests,
and add following self-test cases for DualPI2:
Test a4c7: Create DualPI2 with default setting
Test 1ea4: Create DualPI2 with memlimit
Test 2130: Create DualPI2 with typical_rtt and max_rtt
Test 90c1: Create DualPI2 with max_rtt
Test 7b3c: Create DualPI2 with any_ect option
Test 49a3: Create DualPI2 with overflow option
Test d0a1: Create DualPI2 with drop_enqueue option
Test f051: Create DualPI2 with no_split_gso option
Test 456b: Create DualPI2 with packet step_thresh
Test 610c: Create DualPI2 with packet min_qlen_step
Test b4fa: Create DualPI2 with packet coupling_factor
Test 37f1: Create DualPI2 with packet classic_protection
DualPI2 provides L4S-type low latency & loss to traffic that uses a
scalable congestion controller (e.g. TCP-Prague, DCTCP) without
degrading the performance of 'classic' traffic (e.g. Reno,
Cubic etc.). It is to be the reference implementation of IETF RFC9332
DualQ Coupled AQM (https://datatracker.ietf.org/doc/html/rfc9332).
Note that creating two independent queues cannot meet the goal of
DualPI2 mentioned in RFC9332: "...to preserve fairness between
ECN-capable and non-ECN-capable traffic." Further, it could even
lead to starvation of Classic traffic, which is also inconsistent
with the requirements in RFC9332: "...although priority MUST be
bounded in order not to starve Classic traffic." DualPI2 is
designed to maintain approximate per-flow fairness on L-queue and
C-queue by forming a single qdisc using the coupling factor and
scheduler between two queues.
The qdisc provides two queues called low latency and classic. It
classifies packets based on the ECN field in the IP headers. By
default it directs non-ECN and ECT(0) into the classic queue and
ECT(1) and CE into the low latency queue, as per the IETF spec.
Each queue runs its own AQM:
* The classic AQM is called PI2, which is similar to the PIE AQM but
more responsive and simpler. Classic traffic requires a decent
target queue (default 15ms for Internet deployment) to fully
utilize the link and to avoid high drop rates.
* The low latency AQM is, by default, a very shallow ECN marking
threshold (1ms) similar to that used for DCTCP.
The DualQ isolates the low queuing delay of the Low Latency queue
from the larger delay of the 'Classic' queue. However, from a
bandwidth perspective, flows in either queue will share out the link
capacity as if there was just a single queue. This bandwidth pooling
effect is achieved by coupling together the drop and ECN-marking
probabilities of the two AQMs.
The PI2 AQM has two main parameters in addition to its target delay.
The integral gain factor alpha is used to slowly correct any persistent
standing queue error from the target delay, while the proportional gain
factor beta is used to quickly compensate for queue changes (growth or
shrinkage). Either alpha and beta are given as a parameter, or they can
be calculated by tc from alternative typical and maximum RTT parameters.
Internally, the output of a linear Proportional Integral (PI)
controller is used for both queues. This output is squared to
calculate the drop or ECN-marking probability of the classic queue.
This counterbalances the square-root rate equation of Reno/Cubic,
which is the trick that balances flow rates across the queues. For
the ECN-marking probability of the low latency queue, the output of
the base AQM is multiplied by a coupling factor. This determines the
balance between the flow rates in each queue. The default setting
makes the flow rates roughly equal, which should be generally
applicable.
If DUALPI2 AQM has detected overload (due to excessive non-responsive
traffic in either queue), it will switch to signaling congestion
solely using drop, irrespective of the ECN field. Alternatively, it
can be configured to limit the drop probability and let the queue
grow and eventually overflow (like tail-drop).
GSO splitting in DUALPI2 is configurable from userspace while the
default behavior is to split gso. When running DUALPI2 at unshaped
10gigE with 4 download streams test, splitting gso apart results in
halving the latency with no loss in throughput:
sched: Dump configuration and statistics of dualpi2 qdisc
The configuration and statistics dump of the DualPI2 Qdisc provides
information related to both queues, such as packet numbers and queuing
delays in the L-queue and C-queue, as well as general information such as
probability value, WRR credits, memory usage, packet marking counters, max
queue size, etc.
The following patch includes enqueue/dequeue for DualPI2.
sched: Struct definition and parsing of dualpi2 qdisc
DualPI2 is the reference implementation of IETF RFC9332 DualQ Coupled
AQM (https://datatracker.ietf.org/doc/html/rfc9332) providing two
queues called low latency (L-queue) and classic (C-queue). By default,
it enqueues non-ECN and ECT(0) packets into the C-queue and ECT(1) and
CE packets into the low latency queue (L-queue), as per IETF RFC9332 spec.
This patch defines the dualpi2 Qdisc structure and parsing, and the
following two patches include dumping and enqueue/dequeue for the DualPI2.
The first step towards that is splitting struct page by its individual
users, as has already been done with folio and slab. This patchset does
that for page pool.
Matthew Wilcox tried and stopped the same work, you can see in:
I focused on removing the page pool members in struct page this time,
not moving the allocation code of page pool from net to mm. It can be
done later if needed.
====================
Byungchul Park [Mon, 21 Jul 2025 02:18:26 +0000 (11:18 +0900)]
netmem, mlx4: access ->pp_ref_count through netmem_desc instead of page
To eliminate the use of struct page in page pool, the page pool users
should use netmem descriptor and APIs instead.
Make mlx4 access ->pp_ref_count through netmem_desc instead of page.
While at it, add a helper, pp_page_to_nmdesc() and __pp_page_to_nmdesc(),
that can be used to get netmem_desc from page only if it's a pp page.
For now that netmem_desc overlays on page, it can be achieved by just
casting, and use macro and _Generic to cover const casting as well.
Plus, change page_pool_page_is_pp() to check for 'const struct page *'
instead of 'struct page *' since it doesn't modify data and additionally
covers const type.
Byungchul Park [Mon, 21 Jul 2025 02:18:25 +0000 (11:18 +0900)]
netmem: use netmem_desc instead of page to access ->pp in __netmem_get_pp()
To eliminate the use of the page pool fields in struct page, the page
pool code should use netmem descriptor and APIs instead.
However, __netmem_get_pp() still accesses ->pp via struct page. So
change it to use struct netmem_desc instead, since ->pp no longer will
be available in struct page.
While at it, add a helper, __netmem_to_nmdesc(), that can be used to
unsafely get pointer to netmem_desc backing the netmem_ref, only when
the netmem_ref is always backed by system memory.
To simplify struct page, the page pool members of struct page should be
moved to other, allowing these members to be removed from struct page.
Introduce a network memory descriptor to store the members, struct
netmem_desc, and make it union'ed with the existing fields in struct
net_iov, allowing to organize the fields of struct net_iov.
Signed-off-by: Byungchul Park <byungchul@sk.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Pavel Begunkov <asml.silence@gmail.com> Reviewed-by: Mina Almasry <almasrymina@google.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Harry Yoo <harry.yoo@oracle.com> Link: https://patch.msgid.link/20250721021835.63939-2-byungchul@sk.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Netdevsim emulates firmware update and it takes 5 seconds to complete.
For some use cases, this is too long and unnecessary. Allow user to
configure the time by exposing debugfs a knob to set chunk time.
devlink: Fix excessive stack usage in rate TC bandwidth parsing
The devlink_nl_rate_tc_bw_parse function uses a large stack array for
devlink attributes, which triggers a warning about excessive stack
usage:
net/devlink/rate.c: In function 'devlink_nl_rate_tc_bw_parse':
net/devlink/rate.c:382:1: error: the frame size of 1648 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
Introduce a separate attribute set specifically for rate TC bandwidth
parsing that only contains the two attributes actually used: index
and bandwidth. This reduces the stack array from DEVLINK_ATTR_MAX
entries to just 2 entries, solving the stack usage issue.
Update devlink selftest to use the new 'index' and 'bw' attribute names
consistent with the YAML spec.
Yang Xiwen [Sun, 15 Jun 2025 16:01:10 +0000 (00:01 +0800)]
i2c: qup: jump out of the loop in case of timeout
Original logic only sets the return value but doesn't jump out of the
loop if the bus is kept active by a client. This is not expected. A
malicious or buggy i2c client can hang the kernel in this case and
should be avoided. This is observed during a long time test with a
PCA953x GPIO extender.
Fix it by changing the logic to not only sets the return value, but also
jumps out of the loop and return to the caller with -ETIMEDOUT.
Fixes: fbfab1ab0658 ("i2c: qup: reorganization of driver code to remove polling for qup v1") Signed-off-by: Yang Xiwen <forbidden405@outlook.com> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250616-qca-i2c-v1-1-2a8d37ee0a30@outlook.com
Akhil R [Thu, 10 Jul 2025 13:12:04 +0000 (18:42 +0530)]
i2c: tegra: Fix reset error handling with ACPI
The acpi_evaluate_object() returns an ACPI error code and not
Linux one. For the some platforms the err will have positive code
which may be interpreted incorrectly. Use device_reset() for
reset control which handles it correctly.
Fixes: bd2fdedbf2ba ("i2c: tegra: Add the ACPI support") Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Cc: <stable@vger.kernel.org> # v5.17+ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250710131206.2316-2-akhilrajeev@nvidia.com
Troy Mitchell [Sat, 31 May 2025 06:57:26 +0000 (14:57 +0800)]
i2c: imx: use guard to take spinlock
Use guard to automatically release the lock after going out of scope
instead of calling it manually.
i2c_imx_slave_handle() can safely be entered with the lock held.
Refactored the i2c_imx_isr function so that i2c_imx_master_isr
does not participate in the guard scope
So Using scoped_guard simplifies the control flow
by ensuring consistent and automatic unlock,
which improves readability without affecting correctness.
Allow clocks property to fix below CHECK_DTB warnings:
arch/arm/boot/dts/nxp/lpc/lpc3250-ea3250.dtb: i2c@300 (nxp,pnx-i2c): Unevaluated properties are not allowed ('clocks' was unexpected)
Lad Prabhakar [Wed, 25 Jun 2025 10:45:26 +0000 (11:45 +0100)]
i2c: riic: Add support for RZ/T2H SoC
Add support for the Renesas RZ/T2H (R9A09G077) SoC, which features a
different interrupt layout for the RIIC controller. Unlike other SoCs
with individual error interrupts, RZ/T2H uses a combined error interrupt
(EEI).
Introduce a new IRQ descriptor table for RZ/T2H, along with a custom
ISR (`riic_eei_isr`) to handle STOP and NACK detection from the shared
interrupt.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # on RZ/A1 Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250625104526.101004-6-prabhakar.mahadev-lad.rj@bp.renesas.com
Lad Prabhakar [Wed, 25 Jun 2025 10:45:25 +0000 (11:45 +0100)]
i2c: riic: Move generic compatible string to end of array
Reorder the entry in `riic_i2c_dt_ids` to place the generic compatible
string `renesas,riic-rz` at the end of the array, following the
convention used in other Renesas drivers.
Also, drop the unnecessary comma after the sentinel entry, as it is
not needed.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # on RZ/A1 Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250625104526.101004-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Lad Prabhakar [Wed, 25 Jun 2025 10:45:24 +0000 (11:45 +0100)]
i2c: riic: Pass IRQ desc array as part of OF data
In preparation for adding support for Renesas RZ/T2H and RZ/N2H SoCs,
which feature a combined error interrupt instead of individual error
interrupts per condition, update the driver to support configurable IRQ
layouts via OF data.
Introduce a new `irqs` field and `num_irqs` count in `riic_of_data` to
allow future SoCs to provide a custom IRQ layout. This patch is a
non-functional change for existing SoCs and maintains compatibility with
the current `riic_irqs` array.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # on RZ/A1 Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250625104526.101004-4-prabhakar.mahadev-lad.rj@bp.renesas.com
projects / thirdparty / kernel / linux.git / log
