mptcp_active_enable() is called from subflow_finish_connect(),
which is icsk->icsk_af_ops->sk_rx_dst_set() and it's not always
under RCU.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Fixes: 27069e7cb3 ("mptcp: disable active MPTCP in case of blackhole")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250916214758.650211-8-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mptcp_active_enable() calls sk_dst_get(), which returns dst with its
refcount bumped, but forgot dst_release().
Let's add missing dst_release().
Cc: stable@vger.kernel.org
Fixes: 27069e7cb3 ("mptcp: disable active MPTCP in case of blackhole")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250916214758.650211-7-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
get_netdev_for_sock() is called during setsockopt(),
so not under RCU.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Note that the only ->ndo_sk_get_lower_dev() user is
bond_sk_get_lower_dev(), which uses RCU.
Fixes: e8f6979981 ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://patch.msgid.link/20250916214758.650211-6-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_vlan_by_tcpsk() fetches sk_dst_get(sk)->dev before RTNL and
passes it to netdev_walk_all_lower_dev(), which is illegal.
Also, smc_vlan_by_tcpsk_walk() does not require RTNL at all.
Let's use __sk_dst_get(), dst_dev_rcu(), and
netdev_walk_all_lower_dev_rcu().
Note that the returned value of smc_vlan_by_tcpsk() is not used
in the caller.
Fixes: 0cfdd8f92c ("smc: connection and link group creation")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250916214758.650211-5-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_clc_prfx_match() is called from smc_listen_work() and
not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Note that the returned value of smc_clc_prfx_match() is not
used in the caller.
Fixes: a046d57da1 ("smc: CLC handshake (incl. preparation steps)")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250916214758.650211-4-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_clc_prfx_set() is called during connect() and not under RCU
nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()
after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used
in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()
not to touch dst there.
Fixes: a046d57da1 ("smc: CLC handshake (incl. preparation steps)")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250916214758.650211-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Originally, to directly align with the chanctx design, getter of managed
chanctx returned a default channel when a link doesn't own a chanctx yet.
Then, callers could simply use the return without trivial NULL checking.
But in MLD HW settings of next chip, there will be a special case that a
caller needs to check if a link has owned chanctx or not to determine
CCK hardware circuit working on HW-x. So, add a func *_or_null for this
first.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250915065213.38659-2-pkshih@realtek.com
All recent platforms (including all the ones officially supported by the
Xe driver) do not allow concurrent execution of RCS and CCS workloads
from different address spaces, with the HW blocking the context switch
when it detects such a scenario.
The DUAL_QUEUE flag helps with this, by causing the GuC to not submit a
context it knows will not be able to execute. This, however, causes a new
problem: if RCS and CCS queues have pending workloads from different
address spaces, the GuC needs to choose from which of the 2 queues to
pick the next workload to execute. By default, the GuC prioritizes RCS
submissions over CCS ones, which can lead to CCS workloads being
significantly (or completely) starved of execution time.
The driver can tune this by setting a dedicated scheduling policy KLV;
this KLV allows the driver to specify a quantum (in ms) and a ratio
(percentage value between 0 and 100), and the GuC will prioritize the CCS
for that percentage of each quantum.
Given that we want to guarantee enough RCS throughput to avoid missing
frames, we set the yield policy to 20% of each 80ms interval.
v2: updated quantum and ratio, improved comment, use xe_guc_submit_disable
in gt_sanitize
Fixes: d9a1ae0d17 ("drm/xe/guc: Enable WA_DUAL_QUEUE for newer platforms")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Tested-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://lore.kernel.org/r/20250905235632.3333247-2-daniele.ceraolospurio@intel.com
(cherry picked from commit 8843444843)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo added #include "xe_guc_submit.h" while backporting]
... and fold __nfsd_mkdir() into it.
Reviewed-by: NeilBrown <neil@brown.name>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
mkdir should incrment the parent's refcount; symlink should not.
Reviewed-by: NeilBrown <neil@brown.name>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2025-09-16 (ice, i40e, ixgbe, igc)
For ice:
Jake resolves leaking pages with multi-buffer frames when a 0-sized
descriptor is encountered.
For i40e:
Maciej removes a redundant, and incorrect, memory barrier.
For ixgbe:
Jedrzej adjusts lifespan of ACI lock to ensure uses are while it is
valid.
For igc:
Kohei Enju does not fail probe on LED setup failure which resolves a
kernel panic in the cleanup path, if we were to fail.
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
igc: don't fail igc_probe() on LED setup error
ixgbe: destroy aci.lock later within ixgbe_remove path
ixgbe: initialize aci.lock before it's used
i40e: remove redundant memory barrier when cleaning Tx descs
ice: fix Rx page leak on multi-buffer frames
====================
Link: https://patch.msgid.link/20250916212801.2818440-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- fix crash in rfkill due to uninitialized type_name
- fix aggregation in iwlwifi 7000/8000 devices
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmjKkRQACgkQ10qiO8sP
aAArIg//eXIRRrpXqxps5kYtVymvqHhcfO1xi3CmQ/vdZP88AO5E2Mj5sjT13nOX
QIxrZWL3nh1iFy+qyUyVAoPQMKm4aqCBpBjlt0+qachZUzdmefyk2H3O2v8TOQ1b
wfu7SK5nzWfGkwjIF7e6JUFeT/9bmYhTN2Xg/A7LaWhMO3XXG261fwCQ/Tbu6Guy
R75ISU7hVuohGjldZIjcoU3blbbG8UdfnyIBPt6L+XjU87SaxvwG5mCQavJNFv3j
TUwdD2Zqg/Rs3WV/hNBc3dCc/myEXYHt0VMb0mwh2frslGXTjMZX20Fds0FPlh2K
iN3AHeJ7aB0cvnyBfOJNLOOGTJ9rCGWO0VhJnlK/woWlLkUfKjWqX1N45qrRUMC9
bZD5GoYrhWL5nPBNGNo7QmPDXvEgnsx6PxFszQtli1SPh0h2+Q4MiUZGe1srVdGI
G2mKU+eO4/94djF3PMM7N+MW0mYmnUDdShJb8gurbxrdp6VH/jO/NtzmEjKpQHXz
KqUBUzxIE5zx8+IK0GdcIccZz1y+kjN2msGA69QYdOypx13+88Tas/ukxZPfAh1V
fBTokjk3BlUsqfpyrkk1q3zKGda551gkqnBf5BtYmYuuu74964GgSA+irC1xycQ5
BRbXQzO4VOoygZaJ3jo8Sz6L6U85AD8VBiP254hEfXuWiq/zbkU=
=nDwo
-----END PGP SIGNATURE-----
Merge tag 'wireless-2025-09-17' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Just two fixes:
- fix crash in rfkill due to uninitialized type_name
- fix aggregation in iwlwifi 7000/8000 devices
* tag 'wireless-2025-09-17' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
wifi: iwlwifi: pcie: fix byte count table for some devices
====================
Link: https://patch.msgid.link/20250917105159.161583-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kuniyuki Iwashima says:
====================
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
syzbot reported a warning in tcp_retransmit_timer() for TCP Fast
Open socket.
Patch 1 fixes the issue and Patch 2 adds a test for the scenario.
====================
Link: https://patch.msgid.link/20250915175800.118793-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test reproduces the scenario explained in the previous patch.
Without the patch, the test triggers the warning and cannot see the last
retransmitted packet.
# ./ksft_runner.sh tcp_fastopen_server_reset-after-disconnect.pkt
TAP version 13
1..2
[ 29.229250] ------------[ cut here ]------------
[ 29.231414] WARNING: CPU: 26 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer+0x32/0x9f0
...
tcp_fastopen_server_reset-after-disconnect.pkt:26: error handling packet: Timed out waiting for packet
not ok 1 ipv4
tcp_fastopen_server_reset-after-disconnect.pkt:26: error handling packet: Timed out waiting for packet
not ok 2 ipv6
# Totals: pass:0 fail:2 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20250915175800.118793-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add charge control support for SM8550 and X1E80100. It's supported
with below two power supply properties:
charge_control_end_threshold: The battery SoC (State of Charge)
threshold at which the charging should be terminated.
charge_control_start_threshold: The battery SoC threshold at
which the charging should be resumed.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add nvmem properties to retrieve charge control configurations
from the PMIC SDAM registers.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The SM8550 and X1E80100 platforms now include charge control
functionality in battery management firmware, allowing charging
to stop when the battery reaches a set level and resume when it
drops below another level. To support this in the qcom_battmgr
driver, CHARGE_CONTROL_START/END_THRESHOLD power supply properties
can be added to manage these levels. This results in the battery
power supply properties for SM8550 and X1E80100 differing from
those for SM8350 and SC8280XP. Therefore, separate compatible
entries for SM8550 and X1E80100 are introduced, each with
their own variant definitions as match data.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add state_of_health property to read battery health percentage from
battery management firmware.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add power supply property to get battery internal resistance from
the battery management firmware.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add state_of_health power supply property to represent battery
health percentage.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some battery drivers provide the ability to export internal resistance
as a parameter. Add internal_resistance power supply property for that
purpose.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Remove redundant condition checks and replace else if with else.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Document active low Charge Enable pin. Battery charging is enabled when
REG01[5:4] = 01 and CE pin = Low. CE pin must be pulled high or low.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Change the return value of match_noXlvl() to return the SATP mode that
will be used, rather than the mode being disabled. This enables unified
logic for return value judgement with the function that obtains mmu-type
from the fdt, avoiding extra conversion. This only changes the naming,
with no functional impact.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Link: https://lore.kernel.org/r/20250722-satp-from-fdt-v1-1-5ba22218fa5f@pigmoral.tech
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Currently, VF MAC address info is not updated when the MAC address is
configured from VF, and it is not cleared when the VF is removed. This
leads to stale or missing MAC information in the PF, which may cause
incorrect state tracking or inconsistencies when VFs are hot-plugged
or reassigned.
Fix this by:
- storing the VF MAC address in the PF when it is set from VF
- clearing the stored VF MAC address when the VF is removed
This ensures that the PF always has correct VF MAC state.
Fixes: cde29af9e6 ("octeon_ep: add PF-VF mailbox communication")
Signed-off-by: Sathesh B Edara <sedara@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250916133207.21737-1-sedara@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Heiner Kallweit says:
====================
net: phy: remove mdio_board_info support from phylib
Since its introduction in 2017 mdio_board_info has had only two users:
- dsa_loop (still existing)
- arm orion, added in 2017 and removed with fd68572b57 ("ARM: orion5x:
remove dsa_chip_data references")
So let's remove usage of mdio_board_info from dsa_loop, then support
for mdio_board_info can be dropped from phylib.
====================
Link: https://patch.msgid.link/4ccf7476-0744-4f6b-aafc-7ba84d15a432@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After having removed mdio_board_info usage from dsa_loop, there's no
user left. So let's drop support for it from phylib.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/01542a2e-05f5-4f13-acef-72632b33b5be@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dsa_loop is the last remaining user of mdio_board_info. Let's remove
using mdio_board_info, so that support for it can be dropped from
phylib.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Tested-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://patch.msgid.link/da9563a4-8e14-41cf-bfea-cf5f1b58a4b7@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The periodic pulse event interrupts are used to register the PPS events
into the system, so it is only applicable to PTP_CLK_REQ_PPS request.
However, these interrupts are mistakenly enabled in PTP_CLK_REQ_PEROUT
request, so fix this error.
Fixes: 671e266835 ("ptp: netc: add periodic pulse output support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20250915082528.1616361-1-wei.fang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a vlan over bond testing to make sure arp/ns target works.
Also change all the configs to mudules.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Link: https://patch.msgid.link/20250916080127.430626-2-liuhangbin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Unlike IPv4, IPv6 routing strictly requires the source address to be valid
on the outgoing interface. If the NS target is set to a remote VLAN interface,
and the source address is also configured on a VLAN over a bond interface,
setting the oif to the bond device will fail to retrieve the correct
destination route.
Fix this by not setting the oif to the bond device when retrieving the NS
target destination. This allows the correct destination device (the VLAN
interface) to be determined, so that bond_verify_device_path can return the
proper VLAN tags for sending NS messages.
Reported-by: David Wilder <wilder@us.ibm.com>
Closes: https://lore.kernel.org/netdev/aGOKggdfjv0cApTO@fedora/
Suggested-by: Jay Vosburgh <jv@jvosburgh.net>
Tested-by: David Wilder <wilder@us.ibm.com>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Fixes: 4e24be018e ("bonding: add new parameter ns_targets")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Link: https://patch.msgid.link/20250916080127.430626-1-liuhangbin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RP1 chip has the Cadence GEM block, but wants the tx_clock
to always run at 125MHz, in the same way as sama7g5.
Add the relevant configuration.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Link: https://patch.msgid.link/20250916081059.3992108-1-svarbanov@suse.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King says:
====================
ptp: safely cleanup when unregistering a PTP clock
The standard rule in the kernel for unregistering user visible devices
is to unpublish the userspace API before doing any shutdown of the
resources necessary for the operation of the device.
PTP has several issues in this area:
1. ptp_clock_unregister() cancells and destroys work while the PTP
chardev is still published, which gives the opportunity for a
precisely timed user API call to cause a driver to attempt to
queue the aux work.
2. PTP pins are not cleaned up - if userspace has enabled PTP pins,
e.g. for extts, drivers are forced to do cleanup before calling
ptp_clock_unregister() to stop events being forwarded into the
PTP layer. E.g mv88e6xxx cancells its internal tai_event_work
to avoid calling into the PTP clock code with a stale ptp_clock
pointer, but a badly timed userspace EXTTS enable will re-schedule
the tai_event_work.
Simplify the process by ensuring that:
1. we take a referene on the PTP struct device to stop the
ptp_clock structure going away underneath us when we call
posix_clock_unregister().
2. call posix_clock_unregister() to remove the /dev/ptp* device.
3. add additional functionality to disable any PTP EXTTS pins and
PPS event generation that have been configured on this device.
This should shutdown all events coming from PTP clock drivers.
4. cancel the delayed aux_work and destroy the kthread.
5. remove the PPS source.
6. drop the reference on the PTP struct device to allow the
ptp_clock structure to be released.
This is difficult for me to test beyond build testing - on the
Clearfog platform with Marvell PHY PTP, the ethernet PHY is the
primary connectivity, so removing the PHY driver for an in-use
network interface isn't possible.
On the ZII rev B platform, where the DSA switches have the TAI
hardware and where root NFS is used, removal of the DSA switch
module somehow forces the FEC interface _not_ connected to the DSA
switch to lose link, causing the machine to become unresponsive
as its root filesystem vanishes.
====================
Link: https://patch.msgid.link/aMnYIu7RbgfXrmGx@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ordering of ptp_clock_unregister() is not ideal, as the chardev
remains published while state is being torn down, which means userspace
can race with the kernel teardown. There is also no cleanup of enabled
pin settings nor of the internal PPS event, which means enabled events
can still forward into the core, dereferencing a free'd pointer.
Rework the ordering of cleanup in ptp_clock_unregister() so that we
unpublish the posix clock (and user chardev), disable any pins that
have EXTTS events enabled, disable the PPS event, and then clean up
the aux work and PPS source.
This avoids potential use-after-free and races in PTP clock driver
teardown.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # ocelot, sja1105, netdevsim, vclocks
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Link: https://patch.msgid.link/E1uydLH-000000061DM-2gcV@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Accurately describe what each call to ptp_disable_pinfunc() is doing,
rather than the misleading comment above the first disable. This helps
to make the code more readable.
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Link: https://patch.msgid.link/E1uydLC-000000061DG-2BRt@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Support for platform data from dropped from twl in 4a346a03a6 ("mfd:
twl: Remove platform data support") and board files were dropped even
earlier. There are no in-kernel users of twl4030_keypad_data in the
kernel, and the driver supports configuration via generic device
properties.
Drop support of static platform data from the keypad driver.
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/tica7ol7xwv5tqb7hlkzu6wkiv4quxwrpqv6croe4wfnwvj6wv@4ob6ktqqi3cr
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fix the Kconfig dependencies for PCS_RZN1_MIIC to avoid the unmet direct
dependency warning when enabling DWMAC_RENESAS_GBETH. The PCS driver is
used on multiple Renesas SoCs including RZ/N1, RZ/N2H and RZ/T2H, but the
existing condition only allowed ARCH_RZN1, ARCH_R9A09G077, or
ARCH_R9A09G087. This conflicted with the GBETH/GMAC driver which selects
PCS_RZN1_MIIC under ARCH_RENESAS.
Update the dependency to ARCH_RENESAS || COMPILE_TEST so that the PCS
driver is available on all Renesas platforms.
Fixes: 08f89e4212 ("net: pcs: rzn1-miic: Add RZ/T2H MIIC support")
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Closes: https://lore.kernel.org/all/aMlgg_QpJOEDGcEA@monster/
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20250916162335.3339558-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ethtool FEC histogram series run into a build issue with
type: uint + multi-attr: True. Auto scalars use 64b types,
we need to convert them explicitly when rendering the types.
No current spec needs this, and the ethtool FEC histogram
doesn't need this either any more, so not posting as a fix.
Link: https://lore.kernel.org/8f52c5b8-bd8a-44b8-812c-4f30d50f63ff@redhat.com
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a simple driver for the Himax HX852x(ES) touch panel controller,
with support for multi-touch and capacitive touch keys.
The driver is somewhat based on sample code from Himax. However, that
code was rather confusing, so that we spent a significant amount of
time just trying to understand the packet format and register commands.
In this driver they are described with clean structs and defines rather
than magic numbers and offset calculations.
Co-developed-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20250915-hx852x-v5-2-b938182f1056@linaro.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Himax HX852x(ES) is a touch panel controller with optional support
for capacitive touch keys.
Unfortunately, the model naming is quite unclear and confusing. There
seems to be a distinction between models (e.g. HX8526) and the "series"
suffix (e.g. -A, -B, -C, -D, -E, -ES). But this doesn't seem to be
applied very consistently because e.g. HX8527-E(44) actually seems to
belong to the -ES series.
The compatible consists of the actual part number followed by the
"series" as fallback compatible. Typically only the latter will be
interesting for drivers as there is no relevant difference on the
driver side.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20250915-hx852x-v5-1-b938182f1056@linaro.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmjKiPoACgkQUa+KL4f8
d2FARw//ah5Lic56BNTe3PExXqZcTfPyJT2hgQRer7pMZAigXzAt2nF/oVGNkMTN
VAlrA7wb6979J0JMO4m+LfuBJE5vdsbmjSVL8IfVZuTBnTrlNwM1UEHXLlv4GPnI
4l3xVKEmS5AF0g6aLek2y2d1T2vgh7ErL94Lb4AbqPsskSPwrdhEeYEc/VEUQoHJ
rt8OfN4JrMVVYofFqlOuAUdrdyOQ4NKOZf8DPkmat3ZF4QEu/x8UDecBuzsmQv+t
UDhYdOgBKWW42y9q525lBglGO/r35gHFhbxvV0Z8LlLxBLlTlys9krm6obFDhIW3
VBciLBUGNmuL7OnqjvFjV/Z9sb253iz67xtLInwhMBI2/WcSOufTtCYJ8IrERnsE
mlwy6uWEuWoMH3qLT5z02NPjHC2p02LXfGXG37JRrOrPAr30gKbXt4iOEWz66wbU
J1phVsoy2KzbrhZL/pWUGazQyRkbmNATj10/nYGFNsOVLYhcxArIwyhjqITviH+H
L10OnCP3LYkKK120Mr4fTHqrXb72NVBHWr6RH3QT69gvUwEJulMnQ+mvMCyouh7t
7NidHorEBSwA8daHvgj6hw9WD6WeoBwlPV5t8ns766P0L/X7E5px3WDS22evFRha
n2+jNp0Grb8QDvl6r0oZe2kI+csrax5ZsndRNjyJpeo5stWAsjo=
=fwWe
-----END PGP SIGNATURE-----
Merge tag 'ib-mfd-gpio-input-pinctrl-pwm-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into next
Sync up with MFD tree to bring in support for MAX7360.
