Rename stmmac_release() to __stmmac_release(), providing a new
stmmac_release() method. Update stmmac_change_mtu() to use
__stmmac_release(). Move the runtime PM handling into stmmac_open()
and stmmac_release().
This avoids stmmac_change_mtu() needlessly fiddling with the runtime
PM state, and will allow future changes to remove code from
__stmmac_open() and __stmmac_release() that should only happen when
the net device is administratively brought up or down.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nothing outside of stmmac_main.c makes use of
stmmac_init_tstamp_counter(), so there's no point exporting it for
modules, or even having it non-static. Remove the export and make
it static.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Neither stmmac_xdp_release() nor the normal paths of stmmac_xdp_open()
touch clk_ptp_ref, so stmmac_xdp_open() should not be doing anything
with this clock. However, in its error path, it calls
stmmac_hw_teardown() which disables and unprepares this clock, which
can lead to the clock state becoming unbalanced when the netdev is
taken administratively down.
Remove this call to stmmac_hw_teardown(), and as this is the last user
of this function, remove the function as well.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The cleanup function for stmmac_setup_ptp() is stmmac_release_ptp()
which entirely undoes the effects of stmmac_setup_ptp() by
unregistering the PTP device and then stopping the PTP clock,
whereas stmmac_hw_teardown() will only stop the PTP clock while
leaving the PTP device registered.
This can lead to a kernel oops - if __stmmac_open() fails after
registering the PTP clock, the PTP device will remain registered,
and if the module is removed, subsequent PTP device accesses will
lead to a kernel oops.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Follow the principle of unpublish from userspace and then teardown
resources.
Disable the PTP clock only after unregistering with the PTP subsystem,
which ensures that we only stop the clock that ticks the timesource
after we have removed the PTP device.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The aux_ts_lock mutex is only required while the PTP clock has been
successfully registered.
stmmac_ptp_register() does not return any errors (as we don't wish to
prevent the netdev being opened if PTP fails), stmmac_ptp_unregister()
was coded to allow it to be called irrespective of whether PTP was
successfully registered or not.
Arrange for the aux_ts_lock mutex to be destroyed if the PTP clock
is not functional during stmmac_ptp_register(), and only destroy it
in stmmac_ptp_unregister() if we had a PTP clock registered.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King says:
====================
net: dsa: mv88e6xxx: remove redundant ptp/timestamping code
mv88e6xxx as accumulated some unused data structures and code over the
years. This series removes it and simplifies the code. See the patches
for each change.
====================
Link: https://patch.msgid.link/aMKoYyN18FHFCa1q@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mv88e6352_config_eventcap() is documented as handling both EXTTS and
PPS capture modes, but nothing ever calls it for PPS capture. Remove
the unused PPS capture mode support, and the now unused
MV88E6XXX_TAI_EVENT_STATUS_CAP_TRIG definition.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1uwep9-00000004ikJ-2FeF@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
evcap_config is only read and written in mv88e6352_config_eventcap(),
so it makes little sense to store it in the global chip struct. Make
it a local variable instead.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1uwep4-00000004ikD-1ZEh@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
chip->trig_config is never written, and thus takes the value zero.
Remove this struct member and its single reader.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1uweoz-00000004ik7-13Fl@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mv88e6250_ptp_ops and mv88e6352_ptp_ops are identical since commit
7e3c18097a ("net: dsa: mv88e6xxx: read cycle counter period from
hardware"). Remove the unnecessary duplication.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1uweou-00000004ik1-0aiX@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The smc argument is not used in both smc_connect_ism_vlan_setup() &
smc_connect_ism_vlan_cleanup(). Hence removing it.
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Link: https://patch.msgid.link/20250910063125.2112577-1-mjambigi@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During recent testing with the netem qdisc to inject delays into TCP
traffic, we observed that our CLS BPF program failed to function correctly
due to incorrect classid retrieval from task_get_classid(). The issue
manifests in the following call stack:
bpf_get_cgroup_classid+5
cls_bpf_classify+507
__tcf_classify+90
tcf_classify+217
__dev_queue_xmit+798
bond_dev_queue_xmit+43
__bond_start_xmit+211
bond_start_xmit+70
dev_hard_start_xmit+142
sch_direct_xmit+161
__qdisc_run+102 <<<<< Issue location
__dev_xmit_skb+1015
__dev_queue_xmit+637
neigh_hh_output+159
ip_finish_output2+461
__ip_finish_output+183
ip_finish_output+41
ip_output+120
ip_local_out+94
__ip_queue_xmit+394
ip_queue_xmit+21
__tcp_transmit_skb+2169
tcp_write_xmit+959
__tcp_push_pending_frames+55
tcp_push+264
tcp_sendmsg_locked+661
tcp_sendmsg+45
inet_sendmsg+67
sock_sendmsg+98
sock_write_iter+147
vfs_write+786
ksys_write+181
__x64_sys_write+25
do_syscall_64+56
entry_SYSCALL_64_after_hwframe+100
The problem occurs when multiple tasks share a single qdisc. In such cases,
__qdisc_run() may transmit skbs created by different tasks. Consequently,
task_get_classid() retrieves an incorrect classid since it references the
current task's context rather than the skb's originating task.
Given that dev_queue_xmit() always executes with bh disabled, we can use
softirq_count() instead to obtain the correct classid.
The simple steps to reproduce this issue:
1. Add network delay to the network interface:
such as: tc qdisc add dev bond0 root netem delay 1.5ms
2. Build two distinct net_cls cgroups, each with a network-intensive task
3. Initiate parallel TCP streams from both tasks to external servers.
Under this specific condition, the issue reliably occurs. The kernel
eventually dequeues an SKB that originated from Task-A while executing in
the context of Task-B.
It is worth noting that it will change the established behavior for a
slightly different scenario:
<sock S is created by task A>
<class ID for task A is changed>
<skb is created by sock S xmit and classified>
prior to this patch the skb will be classified with the 'new' task A
classid, now with the old/original one. The bpf_get_cgroup_classid_curr()
function is a more appropriate choice for this case.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20250902062933.30087-1-laoar.shao@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If HW Channel (HWC) is not responding, reduce the waiting time, so further
steps will fail quickly.
This will prevent getting stuck for a long time (30 minutes or more), for
example, during unloading while HWC is not responding.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/1757537841-5063-1-git-send-email-haiyangz@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hosts under DOS attack can suffer from false sharing
in enqueue_to_backlog() : atomic_inc(&sd->dropped).
This is because sd->dropped can be touched from many cpus,
possibly residing on different NUMA nodes.
Generalize the sk_drop_counters infrastucture
added in commit c51613fa27 ("net: add sk->sk_drop_counters")
and use it to replace softnet_data.dropped
with NUMA friendly softnet_data.drop_counters.
This adds 64 bytes per cpu, maybe more in the future
if we increase the number of counters (currently 2)
per 'struct numa_drop_counters'.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20250909121942.1202585-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lad Prabhakar says:
====================
Add GMAC support for Renesas RZ/{T2H, N2H} SoCs
This series adds support for the Ethernet MAC (GMAC) IP present on
the Renesas RZ/T2H and RZ/N2H SoCs.
While these SoCs use the same Synopsys DesignWare MAC IP (version 5.20) as
the existing RZ/V2H(P), the hardware is synthesized with different options
that require driver and binding updates:
- 8 RX/TX queue pairs instead of 4 (requiring 19 interrupts vs 11)
- Different clock requirements (3 clocks vs 7)
- Different reset handling (2 named resets vs 1 unnamed)
- Split header feature enabled
- GMAC connected through a MIIC PCS on RZ/T2H
The series first updates the generic dwmac binding to accommodate the
higher interrupt count, then extends the Renesas-specific binding with
a to document both SoCs.
The driver changes prepare for multi-SoC support by introducing OF match
data for per-SoC configuration, then add RZ/T2H support including PCS
integration through the existing RZN1 MIIC driver.
Note this patch series is dependent on the PCS driver [0]
(not a build dependency).
[0] https://lore.kernel.org/all/20250904114204.4148520-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
====================
Link: https://patch.msgid.link/20250908105901.3198975-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Extend the Renesas GBETH stmmac glue driver to support the RZ/T2H SoC,
where the GMAC is connected through a MIIC PCS. Introduce a new
`has_pcs` flag in `struct renesas_gbeth_of_data` to indicate when PCS
handling is required.
When enabled, the driver parses the `pcs-handle` phandle, creates a PCS
instance with `miic_create()`, and wires it into phylink. Proper cleanup
is done with `miic_destroy()`. New init/exit/select hooks are added to
`plat_stmmacenet_data` for PCS integration.
Update Kconfig to select `PCS_RZN1_MIIC` when building the Renesas GBETH
driver so the PCS support is always available.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20250908105901.3198975-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Prepare for adding RZ/T2H SoC support by making the driver configuration
selectable via OF match data. While the RZ/V2H(P) and RZ/T2H use the same
version of the Synopsys DesignWare MAC (version 5.20), the hardware is
synthesized with different options. To accommodate these differences,
introduce a struct holding per-SoC configuration such as clock list,
number of clocks, TX clock rate control, and STMMAC flags, and retrieve
it from the device tree match entry during probe.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20250908105901.3198975-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add device tree binding support for the Gigabit Ethernet MAC (GMAC) IP
on Renesas RZ/T2H and RZ/N2H SoCs. While these SoCs use the same
Synopsys DesignWare MAC version 5.20 as RZ/V2H, they are synthesized
with different hardware configurations.
Add new compatible strings "renesas,r9a09g077-gbeth" for RZ/T2H and
"renesas,r9a09g087-gbeth" for RZ/N2H, with the latter using RZ/T2H as
fallback since they share identical GMAC IP.
Update the schema to handle hardware differences between SoC variants.
RZ/T2H requires only 3 clocks compared to 7 on RZ/V2H, supports 8 RX/TX
queue pairs instead of 4, and needs 2 reset controls with reset-names
property versus a single unnamed reset. RZ/T2H also has the split header
feature enabled which is disabled on RZ/V2H.
Add support for an optional pcs-handle property to connect the GMAC to
the MIIC PCS converter on RZ/T2H. Use conditional schema validation to
enforce the correct clock, reset, and interrupt configurations per SoC
variant.
Extend the base snps,dwmac.yaml schema to accommodate the increased
interrupt count, supporting up to 19 interrupts and extending the
rx-queue and tx-queue interrupt name patterns to cover queues 0-7.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250908105901.3198975-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Here are some small tty and serial driver fixes for 6.17-rc6 that
resolve some reported problems. Included in here are:
- 8250 driver dt bindings fixes
- broadcom serial driver binding fixes
- hvc_console bugfix
- xilinx serial driver bugfix
- sc16is7xx serial driver bugfix
All of these have been in linux-next for the past week with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaMar1w8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yk8AQCgx9deB0WhbxP/+3sVJ+0swX/bWdoAn3hCCy8f
P+QkteZ02Mmz25DS+gMB
=3mTh
-----END PGP SIGNATURE-----
Merge tag 'tty-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some small tty and serial driver fixes for 6.17-rc6 that
resolve some reported problems. Included in here are:
- 8250 driver dt bindings fixes
- broadcom serial driver binding fixes
- hvc_console bugfix
- xilinx serial driver bugfix
- sc16is7xx serial driver bugfix
All of these have been in linux-next for the past week with no
reported issues"
* tag 'tty-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: xilinx_uartps: read reg size from DTS
tty: hvc_console: Call hvc_kick in hvc_write unconditionally
dt-bindings: serial: 8250: allow "main" and "uart" as clock names
dt-bindings: serial: 8250: move a constraint
dt-bindings: serial: brcm,bcm7271-uart: Constrain clocks
serial: sc16is7xx: fix bug in flow control levels init
Here are some small USB driver fixes and new device ids for 6.17-rc6.
Included in here are:
- new usb-serial driver device ids
- dummy-hcd locking bugfix for rt-enabled systems (which is crazy, but
people have odd testing requirements at times...)
- xhci driver bugfixes for reported issues
- typec driver bugfix
- midi2 gadget driver bugfixes
- usb core sysfs file regression fix from -rc1
All of these, except for the last usb sysfs file fix, have been in
linux-next with no reported issues. The sysfs fix was added to the tree
on Friday, and is "obviously correct" and should not have any problems
either, it just didn't have any time for linux-next to pick up (0-day
had no problems with it.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCaMas6Q8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynTnQCcCnZGqZrq8wiioAa4AzwRkM0PqAAAn3N0yrx4
BXF8pTnpOkYZmjX1cIzK
=GoFM
-----END PGP SIGNATURE-----
Merge tag 'usb-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB driver fixes and new device ids for 6.17-rc6.
Included in here are:
- new usb-serial driver device ids
- dummy-hcd locking bugfix for rt-enabled systems (which is crazy,
but people have odd testing requirements at times...)
- xhci driver bugfixes for reported issues
- typec driver bugfix
- midi2 gadget driver bugfixes
- usb core sysfs file regression fix from -rc1
All of these, except for the last usb sysfs file fix, have been in
linux-next with no reported issues. The sysfs fix was added to the
tree on Friday, and is "obviously correct" and should not have any
problems either, it just didn't have any time for linux-next to pick
up (0-day had no problems with it)"
* tag 'usb-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: core: remove the move buf action
usb: gadget: midi2: Fix MIDI2 IN EP max packet size
usb: gadget: midi2: Fix missing UMP group attributes initialization
usb: typec: tcpm: properly deliver cable vdms to altmode drivers
USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels
xhci: fix memory leak regression when freeing xhci vdev devices depth first
xhci: dbc: Fix full DbC transfer ring after several reconnects
xhci: dbc: decouple endpoint allocation from initialization
USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions
USB: serial: option: add Telit Cinterion FN990A w/audio compositions
When the AXP717A PMIC is missing nodes for the sub-functions, the kernel
complains about not found nodes.
Add all the remaining nodes corresponding to the defined functions for
the dev boards, which have publicly available schematics to base this
change on. The battery charger on all of them are disabled. Also add
an "iio-hwmon" node to express some of the ADC channels as hwmon
sensors.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250913173511.4064176-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
When the board was added, its external 32.768 KHz crystal was described
but not hooked up correctly. This meant the device had to fall back to
the SoC's internal oscillator or divide a 32 KHz clock from the main
oscillator, neither of which are accurate for the RTC. As a result the
RTC clock will drift badly.
Hook the crystal up to the RTC block and request the correct clock rate.
Fixes: de713ccb99 ("arm64: dts: allwinner: t527: Add OrangePi 4A board")
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250913102450.3935943-3-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
When the board was added, its external 32.768 KHz crystal was described
but not hooked up correctly. This meant the device had to fall back to
the SoC's internal oscillator or divide a 32 KHz clock from the main
oscillator, neither of which are accurate for the RTC. As a result the
RTC clock will drift badly.
Hook the crystal up to the RTC block and request the correct clock rate.
Fixes: dbe54efa32 ("arm64: dts: allwinner: a523: add Avaota-A1 router support")
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250913102450.3935943-2-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Radxa Cubie A5E has empty pads for a 32.768 KHz crystal, but it is
left unpopulated, as per the schematics and seen on board images. A dead
give away is the RTC's LOSC auto switch register showing the external
OSC to be abnormal.
Drop the external crystal from the device tree. It was not referenced
anyway.
Fixes: c2520cd032 ("arm64: dts: allwinner: a523: add Radxa A5E support")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250913102450.3935943-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
At least in the initial version of U-boot support landed upstream, the
PRCM bus clocks were not configured, and left at their reset default 24
MHz clock rate. This is quite slow for the peripherals on them.
The recommended rates from the manual are:
- AHBS: 200 MHz
- APBS0: 100 MHz
- APBS1: 24 MHz
Since 24 MHz is the hardware default, just assign rates for the first two.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250913101600.3932762-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
a lockdep warning on the resctrl filesystem.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmjGjXMRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1jPsg/+O0Oyk4MkKtTip3Xf3XFFZUigCk5Lg9Ib
AMCICzDUPSTbaGhH8hCErE0YgD8Rk7gyO+w0qKNH5q2DAhkuLFc609cHwldsZgMz
n8WncqL/NxrtqmROyhGFs9i9TcX8W1qR5zHopov6EgCXQ1448PftA0jQLhQlww9j
SqYPSVii78hHFKBUiaWw0nc40wDHsIMzdUxTUrqd9Qi/7RsTikApTqwUINb65uFS
XLYPUVauZLh1dU2qJKMt2GHuslxn6sBKV1sRXkjsxI+KzuKd61CHDUNcbFCrsjBE
3nJwd0Oc4+2Pdx8Qu3I/8K+IHnwYLxd/0NT2ROCnn8Grqp1AzMmoGpnajF30yPYg
ncLRazjlfNb5EKIQyRJN/Um9dY0yraHlIgfvJ8lZ9Aqon80WxSmPRCg2SdipKdZh
/XJw0kP4dUCH7X9xnhAsz02VwQTXITeZMzK8jev02nzxkPodcv5Gq4mD0CclM3VJ
LeGwasWkba7hcZy8+pICtKkZ+1O/+Cd1w0cE9YkPN+c+bqDXIQRmaFIZHTM/lVRx
HFmfn0gd0EVidKu1CAuRHH7BDOI2K95LLTChdR0toKfkI3ra7oUFZN2BXLxfYV2J
3t1PWrJvHMCjifOq2F8m7WGbg7VzoTjOGaZIFvBxGKKB1azBm7Hxlq1OMjp8LUcx
3T5TPE1agtw=
=pmQD
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2025-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
"Fix a CPU topology parsing bug on AMD guests, and address
a lockdep warning in the resctrl filesystem"
* tag 'x86-urgent-2025-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Eliminate false positive lockdep warning when reading SNC counters
x86/cpu/topology: Always try cpu_parse_topology_ext() on AMD/Hygon
can trigger with certain hardware configs and regular HZ.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmjGirsRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1i91g//QWtFBkjSJgDaCwABsSIr7Z5vgzlidtx5
ZI6bP7Fjt2nMnRXqp+KojMhoVx5WNi8XnQHL+tXIx685ILg8pusxJZ8RplwgccxZ
jApW6PWEvrznWQn4i/uPsH2sDud1T7lI/K74JGPri3xaxpWxfk5LBzHDv296ygi6
PShGP2RDjc1WpOtTs/K/1BHpwodDGB9k7V9CNjydaYKtbuRtNfbvpqTt+Syto8O8
UuFG22j2ZRyPbwuw3PouwaZgBOrks0H9cXW9s6E3wHJA4p+90LVDdhSXcYo2YtJG
VHJM1wUSN/Tth4DIUwxcXwk5ya5AKvQvokPv9n/FL3ceO2CdfyR/hJ2euB+l/dCl
kNooAjaIQzTLowyMigMO+tT7jKTLuwUrq/l6rHSEIoLWoWLH9Ii55fXDlKr9zihu
y5H/jjbNKULIPzZ03gfuIqz4/+t7hFthMcyH+x4xHgPNayT9BJ2X/T59i3wATeZu
s7hscdCb1rNE11Or2mggSX/pMDJxDMzEaD1JmD/4qJeFSipLmKbxcZZgq96RF//2
tU5zrZhm5GIqaK8o/xp1ps15xAwSnDyYjH59U7To0drfoV9uBg7lczPhaAoVAW/F
lQoepSFrw9hV34YRAebimza7/+5IRk+SBCWwYg++xviGaxFt5TStJITOTk3UbHSx
miCA3D/MDeM=
=m+Ze
-----END PGP SIGNATURE-----
Merge tag 'timers-urgent-2025-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Ingo Molnar:
"Fix a lost-timeout CPU hotplug bug in the hrtimer code, which can
trigger with certain hardware configs and regular HZ"
* tag 'timers-urgent-2025-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimers: Unconditionally update target CPU base after offline timer migration
Changes to defconfig should be always updated via 'make
savedefconfig', run this command to make it aligned again.
This will ease the effort of reviewing changes of defconfig
in the future.
Signed-off-by: Yixun Lan <dlan@gentoo.org>
- a quirk to i8042 for yet another TUXEDO laptop
- a fix to mtk-pmic-keys driver to properly handle MT6359
- a fix to iqs7222 driver to only enable proximity interrupt if it is
mapper to a key or a switch event
- an update to xpad controller driver to recognize Flydigi Apex 5
controller
- an update to maintainers file to drop bounding entry for Melfas touch
controller.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQST2eWILY88ieB2DOtAj56VGEWXnAUCaMYYKAAKCRBAj56VGEWX
nOvAAP9IkaFQyTC8hWVUU8w6Q5gC7+pF3lccnOckdDxvoY6kVAEAsQMz8J4Df7ZK
OEaOPUCzWn5mcrAR74+LGXqGgRYGAwk=
=ctHa
-----END PGP SIGNATURE-----
Merge tag 'input-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- a quirk to i8042 for yet another TUXEDO laptop
- a fix to mtk-pmic-keys driver to properly handle MT6359
- a fix to iqs7222 driver to only enable proximity interrupt
if it is mapped to a key or a switch event
- an update to xpad controller driver to recognize Flydigi Apex 5
controller
- an update to maintainers file to drop bounding entry for Melfas
touch controller
* tag 'input-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
MAINTAINERS: Input: Drop melfas-mip4 section
Input: mtk-pmic-keys - MT6359 has a specific release irq
Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk table
Input: iqs7222 - avoid enabling unused interrupts
Input: xpad - add support for Flydigi Apex 5
Make the function definition of phy_StoreTxPowerByRateBase() follow the
kernel coding style by placing the return type and function name on a
single line.
No functional change.
Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
Link: https://lore.kernel.org/r/20250912162613.776769-1-weibu@redadmin.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Apple Silicon machines there is no control over which alt mode is
chosen. The CD321x' firmware negotiates the target mode on its own and
only lets the main CPU know after the mode has already been chosen.
Especially after plugging a new cable in this can result to quick mode
changes from e.g. power only -> USB3 only -> USB3+DisplayPort in a short
time. It is not possile to influence this in any way and we also do not
get direct access to the PDOs or VDOs exchanged via USB PD.
Additionally, mode changes must be tightly synchronized between DWC3 and
the Type C PHY and most mode changes require a full reset of DWC3 to
make the port work correctly.
This is all done synchronously from the role switch handler inside the
DWC3 glue driver on these machines to avoid tripping any failsafes or
watchdogs inside the Type-C PHY that may, in the worst case, reset the
entire SoC.
To be able to control all this we trigger the entire process in the
correct order directly from the TIPD driver and de-bounce any mode
changes to avoid tearing down and re-setting DWC3 back up multiple times
any time a new connection is made.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Co-developed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Sven Peter <sven@kernel.org>
Reviewed-by: Janne Grunau <j@jannau.net>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-11-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just like for power status we also need to keep track of data status to
be able to detect mode changes once we introduce de-bouncing for CD321x.
Read it during probe and keep a cached copy of its value.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-10-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need the initial power status to be able to reliably detect connector
changes once we introduce de-bouncing for CD321x next. read_power_status
takes care of this and also forwards the status to the trace subsystem
so let's use that instead of open-coding it inside probe.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-9-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Whenever the power status is changed make sure to also update the
partner identity to be able to detect changes once de-bouncing and mode
changes are added for CD321x.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-8-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ports equipped with a CD321x are only found on Apple Silicon machines
and always support DisplayPort, Thunderbolt and USB4. Register these
port modes unconditionally.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-7-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CD321x supports various alternate modes and stores information once
these are entered into separate status registers. Read those when they
are active when reading TPS_DATA_STATUS to prepare supporting these.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-6-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We're about to add more fields to struct tps6598x which are only relevant
for Apple's CD321x and to ensure that we don't waste memory everywhere for
those add a separate struct for cd321x and prepare to allocate more space
inside probe.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-5-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some bits inside the CD321x TPS_DATA_STATUS register have a different
function compared to the original tipd chip. Add these and introduce a
separate trace function to show them correctly.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-4-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When support for CD321x was originally added no other hardware variant
was supported and there was no need for struct tipd_data. Now that it
exists move the special case in there so that we can drop the
of_device_is_compatible_check entirely.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-3-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the irq mask was originally added more tipd variants have been
introduced and there's now struct tipd_data. Move the initial mask in
there.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-2-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Right now the interrupt handler first reads all updated status registers
and only then clears the interrupts. It's possible that a duplicate
interrupt for a changed register or plug state comes in after the
interrupts have been processed but before they have been cleared:
* plug is inserted, TPS_REG_INT_PLUG_EVENT is set
* TPS_REG_INT_EVENT1 is read
* tps6598x_handle_plug_event() has run and registered the plug
* plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again)
* TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared
We then have no plug connected and no pending interrupt but the tipd
core still thinks there is a plug. It's possible to trigger this with
e.g. a slightly broken Type-C to USB A converter.
Fix this by first clearing the interrupts and only then reading the
updated registers.
Fixes: 45188f27b3 ("usb: typec: tipd: Add support for Apple CD321X")
Fixes: 0a4c005bd1 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Cc: stable@kernel.org
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-1-4e99c8649024@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core can properly handle constant struct bus_type,
move the pmu_bus variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240204-bus_cleanup-events-v1-1-c779d1639c3a@marliere.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the device tree information for the S32G On Chip One-Time
Programmable Controller (OCOTP) chip.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add descriptions for the SolidRun i.MX8M Plus System on Module based
HummingBoard product-line. They share a common designed based on the
"Pulse" version, defined by various assembly options.
The HummingBoard Pulse features:
- 2x RJ45 Ethernet
- 2x USB-3.0 Type A
- HDMI connector
- mini-HDMI connector
- microSD connector
- mini-PCI-E connector with SIM slot supporting USB-2.0/3.0 interfaces
- M.2 connector with SIM slot supporting USB-2.0/3.0 interfaces
- MIPI-CSI Camera Connector (not described without specific camera)
- 3.5mm Analog Stereo Out / Microphone In Headphone Jack
- RTC with backup battery
The variants Mate and Ripple are reduced versions of Pulse.
The HummingBoard Pro extends Pulse with PCI-E on M.2 connector.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This patch adds a new fixup for the ALC295 codec on some Dell
laptops that use the TAS2781 I2C amplifier.
The fixup correctly initializes the amplifier and pins, allowing
sound to work on all speakers of these devices.
The fixup chain is added to the relevant quirk entries for
Dell Polaris models.
[ adjusted for 6.17 kernel code by tiwai ]
Fixes: 1e9c708dc3 ("ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1249575
Signed-off-by: Donald Menig <djmenig@outlook.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Extend the Tegra124 DFLL driver to include configuration settings
required for Tegra114 compatibility.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
[treding@nvidia.com: Use TEGRA210 instead of T210]
Signed-off-by: Thierry Reding <treding@nvidia.com>
for_each_free_mem_pfn_range_in_zone_from() and its "backend" implementation
__next_mem_pfn_range_in_zone() were only used by deferred initialization of
the memory map.
Remove them as they are not used anymore.
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
