Devicetree bindings used by memory controller drivers and DTS for Tegra
SoCs.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmn59ZsQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD165bD/wJ7SHCxU64UIDKiVHL8jtthVj5TZrGeWk+
khf/2V7fMnG5cFbenrjT3PI/cyUuFa/+iIFxOdxyPUeoEQADjpjlQkBuIot09bye
2pjal57987oEdVOP/XCKZlZclR+EY8M7UD6mTd0T62DqLZGWfBQE1GLPEfWtdr2n
gb5eTm+AhrXcfLphnKNzUpHgeHYIFCLUimt1LpQjG9PYX+a04EeI4AsOwyrWQLQK
fjf+m+xIddL/hEMiCLYjdHzA1QLAAPIXLbCVQXH+I3Nvp4GLzpfMratUIH/ikup5
I00PrRk/ZqXc5JIDHSO3YX4Y2AZXEbka/ZKKZqFwMGHjTzKEt2xsQkYnvAj5akoY
axCEooYO2og059igfcVXPdSLmwmXjx8ihTJZBUWnAeDWXZBQ3OzRjLqS7tNnPdd0
AQdUWiVeEScYn10k+TcIRs/vwG0ORyqiJX2emB6qED1tCJOjcqg/ecyxEVDCEV3w
j21AtRkE35xMaLAhEUWiEQtmQYGGt8Nax8aXwP5pNCdvYGL01IUCAPvR5kYlKyK+
xjDX4N2T5QXk17FCjZbnYsTNhUoD5PwSXg8o/fj6YnB6DboUfLpbXCb2HPZFycSy
9CkVh1vVgU/x+l/02GldW/tFisONXvnWy6TETp0gJvAGYx5+96B9ephiW9lSygpK
juLjgtLg9w==
=YmVM
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-tegra-dt-bindings-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into for-7.2/arm/dt
DT bindings for memory controller drivers Tegra SoC
Devicetree bindings used by memory controller drivers and DTS for Tegra
SoCs.
kconfiglint reports:
K002: config TEGRA_BPMP selects visible symbol TEGRA_IVC which has
dependencies
TEGRA_IVC was originally introduced in
commit ca791d7f42 ("firmware: tegra:
Add IVC library") as a user-visible
bool with a prompt ("Tegra IVC protocol"). At that time, TEGRA_BPMP
depended on TEGRA_IVC, requiring users to manually enable it.
Recently,
commit 78eb18020a ("firmware: tegra: Fix IVC dependency problems")
recognized that TEGRA_IVC is library code that should be activated via
`select` rather than user selection. That commit changed TEGRA_BPMP from
`depends on TEGRA_IVC` to `select TEGRA_IVC`, and restricted TEGRA_IVC's
prompt to only appear under COMPILE_TEST
(`bool "Tegra IVC protocol" if COMPILE_TEST`). The commit message
explicitly states: "The IVC code is library code that other drivers need to
select if they need that library."
However, the `if COMPILE_TEST` qualifier still leaves TEGRA_IVC as a
technically visible symbol, triggering K002 when TEGRA_BPMP selects it.
Since TEGRA_IVC depends on ARCH_TEGRA, it cannot be independently enabled
under COMPILE_TEST without ARCH_TEGRA anyway, limiting the value of the
standalone COMPILE_TEST path. TEGRA_BPMP itself provides adequate
COMPILE_TEST coverage for the IVC library through its own dependency chain.
Complete the transition to a pure library symbol by removing the prompt
entirely, making TEGRA_IVC a hidden bool activated only via select from
TEGRA_BPMP. This is consistent with the intent expressed in 78eb18020a.
Assisted-by: Claude:claude-opus-4-6 kconfiglint
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fix CAAM driver probe failures caused by missing SoC information by
retrieving the match data directly through of_machine_get_match_data(),
which provides the correct SoC-specific data.
-----BEGIN PGP SIGNATURE-----
iQHFBAABCgAvFiEEJS45w2QNr0ezLVaoNF3oRQ23YkwFAmoYj2MRHGZyYW5rLmxp
QG54cC5jb20ACgkQNF3oRQ23YkxPwQwAq95b24f+LRSLuQjyfQVi6SbuGwufVtMp
zsrwiZKfyWAkvxHa7CLHKaIC7x60J3YTUc5BdB7vQ/uDaZZwEnn/1rnUD4vvjTkd
vODYZ2DYdZERE3UrljAdxEcuXBH496s+eDybVf4oVk5V5/rQ6TCbnK+rxXB+fXS+
dkzUOL1j4fX1XsaGNICsCLJuSNLsxr9ja9CNJLFpr6fnncnmx8kKHSP1PHKseF+N
qwOw5Iv2Cwp4EQZGfm54j/k7pAMlJljzWy+X5qNInUsvEBMUKa97apiMVBCfYfTB
qDIYGA6KNd/7kMMkam2DusrOLitFpQtUFtjlMwee3BoYls3d2OkdpH1EilyoZoEg
MCF7wd7PzD7jenVC4Z1S1BW0AdG+n3Pyxnh9iW3grljYsXE/sFRx/U13JN32EqoU
vWshLNvNX4XH4iZKDNt+mvoCTzcnlkIZYcM4mR+JjXUpmFhcsOIpAFD2RhE/0jta
qJOLvCddLfqkf3VPXK/sRRE48Pkw8kJs
=freo
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmoYurAACgkQmmx57+YA
GNkMKQ//f/kQ6VT0fovp6yM60tEAPsVtt5U8zpSsQpuv1joJqS9FgSx13Z6XlLsq
IIyGPxlzsTnCke3UHo0poiGUlNrOvY87fQ8ZeU7ItpxoKLSHmLUwXZAzmlVy+yj/
WSly0Ns3VURXhlbdQ14mQE+kxZTOBb9L02K3iIGjgIda5fbG+12IvB0cPxPUv3Oi
+Uw2H4D5S17FxYlQoVtxPL6D/GcqBVSSCaqVHJdvpS4wmoCKvycK9yYymJnbRxIf
/QBwpfR6QON4wxpFk7lF0s7+DWfk88qeZOvf+sDyMRGbDLsNU9C6zmjVD6y2lT3N
kHjrnZUqdg3DgwHhc/+sXJgW4cNsDisz/L27lHwMDzzFuvz6+SB7xXn1k0cDuyGt
5HVmdTuRRAYyolzTXCPgxvP1j11xGcOueNR7fQDbQKPDUm9OpgT0X0fPaG/w6H35
qq1VBxJDMV+0DPOgBzHniC2CNBdADZ6Og14wQPEdVTsQUaWH66aXS8iQrcKbjwEw
rDFS3eiOu8s+iP4wccSgKvJs0vn0fRmc2AVA74awwmoyUowwA2lT5hWKhKVuWlJN
Zs4Bw/bk+DQAeCzUvswYdEnb1tTO4l95jHh9b4p3qkU9N8vZOmsQSwoy2XjzseLo
Z14PuXI4R5+4LXgR26doMqonYvVkvblqETt4IkBGrUzUyaRifMM=
=Kz7A
-----END PGP SIGNATURE-----
Merge tag 'imx-soc-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
i.MX SoC fixes for v7.1
Fix CAAM driver probe failures caused by missing SoC information by
retrieving the match data directly through of_machine_get_match_data(),
which provides the correct SoC-specific data.
* tag 'imx-soc-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
soc: imx8m: Fix match data lookup for soc device
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
These FIS partition offsets were never right: the comment clearly
states the FIS index is at 0xfe0000 and 0x7f * 0x200000 is
0xfe0000.
Tested on the iTian SQ201.
Fixes: d88b11ef91 ("ARM: dts: Fix up SQ201 flash access")
Fixes: b5a923f8c7 ("ARM: dts: gemini: Switch to redboot partition parsing")
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ihor Solodrai says:
====================
bpf: Implement stack_map_get_build_id_offset_sleepable()
The series introduces stack_map_get_build_id_offset_sleepable(),
fixing a gap with parsing build_id in sleepable context in stackmap.c
In particular, this fixes a deadlock in
stack_map_get_build_id_offset() doing a blocking __kernel_read(),
which happens since commit 777a8560fd ("lib/buildid: use
__kernel_read() for sleepable context").
See previous revisions for more details.
---
v6->v7:
* Addressed feedback from Andrii (mostly patch #2):
* implement proper CONFIG_PER_VMA_LOCK=n support, following a
VMA locking pattern similar to one used in PROCMAP_QUERY
* change the contract of stack_map_lock_vma(): if a non-NULL VMA
is returned, then a read lock is held
* remove now unnecessary vma_locked flag
* and various other nits
* Add vma_is_anonymous() checks where appropriate (AIs)
v6: https://lore.kernel.org/bpf/20260521225022.2695755-1-ihor.solodrai@linux.dev/
v5->v6:
* Misc refactoring (Andrii):
* add stack_map_build_id_set_valid() helper
* simplify control flow in stack_map_get_build_id_offset_sleepable()
v5: https://lore.kernel.org/bpf/20260515005244.1333013-1-ihor.solodrai@linux.dev/
v4->v5:
* Add comments explaining mmap_read_trylock() (Shakeel)
* Rebase on bpf-next (Alexei)
v4: https://lore.kernel.org/bpf/20260514184727.1067141-1-ihor.solodrai@linux.dev/
v3->v4:
* Change Fixes tag in patch #2 (AI)
* Nit in caching implementation (Mykyta)
v3: https://lore.kernel.org/bpf/20260512032906.2670326-1-ihor.solodrai@linux.dev/
v2->v3:
* Split patch #2 in two: stack_map_get_build_id_offset_sleepable()
implementation, and then introduce caching
* Drop taking mmap_lock if CONFIG_PER_VMA_LOCK=n, fall back to raw
IPs instead
* Cache vm_{start,end} in addition to prev_file (Mykyta)
v2: https://lore.kernel.org/bpf/20260409010604.1439087-1-ihor.solodrai@linux.dev/
v1->v2:
* Addressed feedback from Puranjay:
* split out a small refactoring patch
* use mmap_read_trylock()
* take into account CONFIG_PER_VMA_LOCK
* replace find_vma() with vma_lookup()
* cache prev_build_id to avoid re-parsing the same file
* Snapshot vm_pgoff and vm_start before unlocking (AI)
* To avoid repetitive unlocking statements, introduce struct
stack_map_vma_lock to hold relevant lock state info and add an
unlock helper
v1: https://lore.kernel.org/bpf/20260407223003.720428-1-ihor.solodrai@linux.dev/
---
====================
Link: https://patch.msgid.link/20260525223948.1920986-1-ihor.solodrai@linux.dev
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Stack traces often contain adjacent IPs from the same VMA or from
different VMAs backed by the same ELF file. Cache the last successfully
parsed build id together with the resolved VMA range and backing file
so the sleepable build id path can avoid repeated VMA locking and file
parsing in common cases.
Suggested-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Mykyta Yatsenko <yatsenko@meta.com>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260525223948.1920986-4-ihor.solodrai@linux.dev
A number of targets now depends on the M.2 PCIe power sequencing driver,
enable this to keep these devices functional with a defconfig build.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmoVtMkOHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcUL2w/8CkfdKhdB8BOe/X9t72nNwjVwq/+BTTlpZxR0
pNn5TvBhJWedzLq7Q2R7RU9CF74wGosT9JAX8jb45NHoemH4ia7aj5uHks2rMIU9
i+XI78VT9MwF13ls9yCjLGcqquowEpQzVMNfGwLZO5dp46wZ59GPIUcwoOmr6VqF
G1Ps3T1mkkALB1RDQitad6Ey3xaMZqA38mFhfByz/ELGSuhWaG7sjGSy6HVEVtzd
RIdFEdx+6Ez08V6tvKP82ljWljKDCeAlOggD9BbpTUVq1zGCdqQIaeG/O1nNJzaf
buQH5iqI7HGFtEmXTHCRFzUUKdD/hi5HyYvIF7PWBswqAfoC70Gb9NozFYnNvXac
eCJK6NNc6jCt42W4iZGAD74lr0UDGK2L+ymztJfRU+0v/PTxY40NmIX0GwRN2JKc
zwg6IKhyhwg9IOoBAQpVJLgVx7dUBk8sVj3yJAk/B+C8vOVoCQbde6FIJf6pJRS7
Ms8ZeJ4eGOcVTgdrzaJTxWN5xJzD7Y92KelzlhGN/l35QbYkf9DwEtIm+g816qBX
be6suWXMhZ+aYmrrAJB4yaXfqghDHC2pAaykH3b1J17FyvZIwWTDEJmcxTMHqaha
i+2l8Elrz/VlqC4ugrm0tzbQ6xIv7BeImUcC3fPKi/Whoxv/oZDbaR+RYDMs0R3n
SL15hhw=
=+XU9
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmoYukwACgkQmmx57+YA
GNnagRAAj360SPhrfkWQ94jIqQNoVThrfD3t25JhgSyrrghYQiRf6zTSCRrIDqBl
21JzjbYhT/pd+wvs5AVlyTaY00fVIJtv81s3s5CYUKkonKK0wEG7y7bmHTb2HQIr
1t76jS0Zbj4+HE0eYcvfVQD++sZ+dL1b93HmGDjTm47lsUvdd2OsfaCChS/OkT4H
u9q/PT8iekXgEFY1Q4A6z+D8XE+k0UFsalZaCcEn/eo11ZluBNhX00TsGoIIYDyR
OkfRsyjqc3X3zAqLvsiNUlTtSrAKXXFIUUEGpvEUWRapCgiwqk0XHPSVfExn7C4r
ZSORwoxI7tIbTjNvn9iKZS2KGDUDr8fpe5TKrJvB1IM+4JnzNSU1sSTxrG21jCqA
hvIATBYzHfdE3525A9ANauMbG42zKWvQFwG0/Sege0t6W9Q895jjOH+bH2ku2mFb
/bQ3WF7IsoSFv48u47ISPZJMSZOjC12gJ+NIlouzt0JNmPQJI6Hu5adY9T2OrWtu
ovq6CnZO52V+uTcM6W/VxrdhstUVXJQY3zhbVPSWPu94sfes3a4wmDkZELFy9GdN
SFVZoL1gK4qojrjgLSniBnL0MNpv71coh1cx0j6xonDZqvWrXi9wtx6dpFFTVYyB
UWBZiOFnqeYttwJ1+FZilUsYET9BZt9xpFQBSo2eyVlMGF80n2U=
=M655
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm Arm64 defconfig fixes for v7.1
A number of targets now depends on the M.2 PCIe power sequencing driver,
enable this to keep these devices functional with a defconfig build.
* tag 'qcom-arm64-defconfig-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable PCI M.2 power sequencing driver
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add missing power-domain and iface clocks for the ICE node of Eliza and
Milos to avoid the validation errors that resulted from late binding
changes. Also drop the reference clock for the USB QMP PHYs, for the
same reason.
Avoid touching the 20'th I2C bus on the Hamoa-based (X Elite) Dell
laptops, as this conflicts with the battery management firmware.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmoVs6MOHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcUHfA/+MoI7gAkKpGLLY3z7ZZUfcAgjD9shIaH2lvZU
JV8gvlP3QZSngm65qeADClnzD8aca/ufrp3tyW6aqQUccWmVfXDOV/K2L2DrjYRQ
8m5KyeZD0te1RensSfmHD0J74IhAfwX3vuHFONjRWSQ9+BGRubgnqYoFUG8qVVkZ
jhMFdDerjUBmwiQsg7jkhQrnc3SjUyuXLstB78KBejJ9oHMch0c6Nrt/LeX/T04w
hpldA+C3Gx5R7RAWTNQtQiVzR7uAnbgJci3hmJ0S7prCCPuNEF2lc7pCXaLwqbIu
/wsjorqDE39TizuLkDPdTgD/p9Ec8p4kkBlnNsgVrHuHYYQKP5TF8t/JmllMOy5X
U+96eYNENqjXkezKO69/6yqeTsqJAL1rNRIcauF/p0eNNOU4wUBnEsXnxoxK7TPM
HuvD48wLIxT4eK4nnna7397ZwuSzkvpPxAzL0Opq6nNKMreGVoBLZ2hQgiZXv1tC
zgSmT4Jr4LKk3Cl6RM6KmwpZ1H7DcQB8Me6tgfkApcNbbNLci/D70pG19ikmh8TX
rk18Cfnp5jJvjgE0Hv00PzuzkzmPj2nRTIExb4Cw17n+LAkyC2eifu1O7J7FPW4a
mxkxe9EQ2OdfAKy3jrysvvqMpIK1mH0d1COoKz9OGSrXubYearjhtuC8KaSrZNo5
4LiykTY=
=/uFW
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmoYucwACgkQmmx57+YA
GNmK7Q/9EbFgk/uOiiyEhjPVudQHSR/JxEs7TQMbnxEOMmXvQ01FHnRlfqDSgZqx
X+7UgrFCTIHSIaD/O29WIapW2TN4OGBI2gwHNsnWFCWbC8ZZGo+HoU3V7Fjzk8D+
9A36G3myRerPuKWmPHQSkjfQHUKkmWUmLBCXGBwRxd3YZvjSZxeaYfDm+n9CVsIi
NelVe42QvwP2U+FPBYXARfawn9MEBY267s8PBVaqz+k159gqSfCS5UHHQjzg1d/F
KD7FX0y3B7EkmwpyEElapjPiXs3Mi/5PYa+C9f0zCIdRfU6H70cHcNO2OlXucq5A
PQ79gdTI7Om9uH4gdXEyGg7Qcu2+rz0WKjFjyYBxYpgsEpCYxUVjkRpCZ1Nn34iz
nDqVKY3jmiAws1omP51YPtFNLVw3K0ZmKMka1M7AR7wdK2115l+XUSDze6pTXazL
RBO6DCVZEs9AikhOX+p5VF3Brmupf9lhM7Ixml4E/EOu2jAsfTnKe+3v1IUxAQ4K
rllnn19NntTg7qIcuX+jDAkxY0mwD1JVSR4UYAahPHFfOZYqq++gLE9BcT0IGj47
mo6wL01Niu7OU5hkQlq6fJib1tyiv12zdHYOJt7u85eiT6hXwxjx4iMEnTROCTuI
uaV9Qzfd3EujRnwho4QnOrV8bNwcS9GpBXNz/MaYrjOrxEmn9G0=
=qWqc
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm Arm64 DeviceTree fixes for v7.1
Add missing power-domain and iface clocks for the ICE node of Eliza and
Milos to avoid the validation errors that resulted from late binding
changes. Also drop the reference clock for the USB QMP PHYs, for the
same reason.
Avoid touching the 20'th I2C bus on the Hamoa-based (X Elite) Dell
laptops, as this conflicts with the battery management firmware.
* tag 'qcom-arm64-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
arm64: dts: qcom: x1-dell-thena: remove i2c20 (battery SMBus) and reserve its pins
arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Per some offline discussion with Kiryl, he could use some help on the TDX
host side. I have worked on the TDX host side for the past few years
including wrangling the initial KVM support, and can help with this.
I am already listed as TDX reviewer. Move it to maintainer.
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Link: https://patch.msgid.link/20260527221342.415814-1-rick.p.edgecombe@intel.com
Since commit 4ee58e1e56 ("net: promote SIOCSHWTSTAMP and SIOCGHWTSTAMP
ioctls to dedicated handlers"), SIOCSHWTSTAMP and SIOCGHWTSTAMP are no
longer dispatched through dev_eth_ioctl() / ndo_eth_ioctl(). They are
now handled by their own dedicated functions dev_set_hwtstamp() and
dev_get_hwtstamp() in the ioctl path.
However, the comment describing ndo_eth_ioctl in netdevice.h still
lists these two ioctls, which is misleading for driver developers who
may incorrectly assume they need to handle hardware timestamping
commands in their ndo_eth_ioctl implementation.
Remove the stale references from the comment to accurately reflect that
ndo_eth_ioctl only handles SIOCGMIIPHY, SIOCGMIIREG and SIOCSMIIREG.
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260527120936.24169-1-xuanzhuo@linux.alibaba.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Qualcomm ICE driver suffers from race conditions between probe() and
get() and will in certain cases return the wrong error code, which
results in storage drivers failing to probe. Fix these issues.
Also correct the DeviceTree binding, to ensure that relevant clocks are
described and voted for, to prevent the driver from accessing unclocked
hardware during boot.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmoVsj8OHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcVLlhAAjW6WvbknpvjbJEwVjsFCdi9wtplLibtTBU+q
7HcPCdtN+kWSu1H1F6b/B5ugpfdroy+UK0P6tV2glOQW5h5JIVwCktT4ucPgSrld
UyAcx9EuupyYFy/qCLz6gZ82JMAjzKyFDa2F4IEp3VbAUFneVOgg87XXDPvD8tmU
9VsbLsXJYUaFGixFqpuG2fzSZGH6GSSd493HziyKZL43kskfH4cJOQ6LiQL5RhhE
GuEs9Oqerv+uisS3dq4nqf7pbZEP+SetlQOuj/LcGP0gibZf4W0gvx0RuN9gj0oJ
THeOdn1cf3mEY3wnCwrCTm4t5qn+k85EP5nVN2gmQTSgU/QIkDYNeNUydFn0rvPJ
LlaSMaU5zDI68s+xXfm+8uGZecdRV97VLifUc0OBBh2pdy3gXgNlmctyEKES/lYR
kUVakLcFszElfdsChRNw230MzM5wm9wjsag3KtBua5pqiGiMsfVgU59ejBR9tI6C
tQZrPZotk4mMcljO1f9GO5swJKt5mznQ1XVabTz8NzNHJycBkCJSIA1IDxzjATt0
9IQqtK8fULVtD5gPpwF1tEigIEy0mL1QDv4qDZWS2KkElYOrRWQVwRoP1Ba3ZqSI
gnBTVlULNftodxbLW32ujgBDBQoEAeNBkA9Nfy9HTiYapbCqrlr7fne29+YTj2lz
dR7+CXw=
=QdJR
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmoYt/4ACgkQmmx57+YA
GNkgIA//S0tL8vyZ4kVKetG1ZUSSTZkX1IzmNLyiroaIk1mIFIepnaLI37MU6Yiq
RZUZsXPsHX2mPOVXSqIA0imwKn5fAVR8HgoQE8Tng0U2t9KTEW9NCgvPjLWlwpPe
kKZlxnk3wxoD+tlEBYisjc44MLLo2pS+lrrFGd9Ki03r+Gt+jnfb/icxMnHYRSIu
fBrsPaAzPsGuIzGUrNJcm0FzDMcLq2SJ9cIka8QUQSJR0+rugvC0thZxExAo1zt8
UnlMrpTDcuCTzxgVdiQMj9ThhplvAqobOrgadq6h91OQtPKwGaFQ8cXnTBvX1ILk
tFhNKTNp3hOxbPYy4km5+TCfmjI1X4b6i9hQGeP/3FTsB8L/twYQd135SDeV6Mmy
/zgDWFd2ZyEI/DtMauOTFs8bt3Cq9Lpq0wzwOxXdknZapXDbhdidIJloX+bAmS0D
BI6uRXEnEJQPWeHd452gJSJ9tJLqYRbSiw0KH0T430YnhwN4wx5owMyFPmGawVUj
D6AuGaWwpTtX1velVQD6cGGMxjw2RYfMw4tNWsxB9c6BoB8dR+K5jXGi0vfE5Hk0
6Lh09zvsc2hfIlT5gELMEkiKbEyrkAD48wUh9ZAZ1LMwIChZ6sq2JnTtaZzufetX
HdnsUDOVCgcrjb4UEMDUq6VNwXM2M/7PKmS2q/rRdDrU7OP7hhM=
=o97B
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm driver fixes for v7.1
The Qualcomm ICE driver suffers from race conditions between probe() and
get() and will in certain cases return the wrong error code, which
results in storage drivers failing to probe. Fix these issues.
Also correct the DeviceTree binding, to ensure that relevant clocks are
described and voted for, to prevent the driver from accessing unclocked
hardware during boot.
* tag 'qcom-drivers-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: ice: Fix the error code when 'qcom,ice' property is not found
scsi: ufs: ufs-qcom: Remove NULL check from devm_of_qcom_ice_get()
mmc: sdhci-msm: Remove NULL check from devm_of_qcom_ice_get()
soc: qcom: ice: Return proper error codes from devm_of_qcom_ice_get() instead of NULL
soc: qcom: ice: Return -ENODEV if the ICE platform device is not found
soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()
soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ETHTOOL_MSG_STRSET_GET is the only op which sets allow_nodev_do.
When no device is provided it dumps static tables, there's no
need to hold rtnl_lock for this.
Not taking rtnl_lock is a minor win in itself so I think this
patch stands on its own merits. Later on it will be useful
to do locking only in paths which have access to a netdev,
so that we can decide which locks to take per-netdev.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260527162522.3344231-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This reverts commit 4157501b9a ("vsock/virtio: fix skb overhead
overflow on 32-bit builds"). The fix was semantically correct (although
it would have been better to use mul_u32_u32(), as David pointed out),
but in practice we are estimating the memory used to allocate the SKBs,
and this will never cause a 32-bit variable to overflow on a 32-bit
system, since the memory would have run out long before that. On 64-bit,
SKB_TRUESIZE() already evaluates to size_t, so the multiplication is
already in 64-bit arithmetic without the cast.
Let's revert this to avoid unnecessary 64-bit multiplies on the
per-packet receive path on 32-bit systems.
Reported-by: David Laight <david.laight.linux@gmail.com>
Closes: https://lore.kernel.org/netdev/20260523173557.5cc4f4f6@pumpkin
Suggested-by: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Laight <david.laight.linux@gmail.com>
Link: https://patch.msgid.link/20260527171046.130211-1-sgarzare@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Register nvmem lookups in tegra_fuse_probe(), after the nvmem device has
been registered, since they can only be used after the nvmem device is
registered.
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
LoongArch uses the generic syscall table, where __NR_bpf is defined
as 280 in include/uapi/asm-generic/unistd.h.
To align with other architectures, add the __NR_bpf definition for
LoongArch to avoid a potential compilation failure: "error __NR_bpf
not defined. libbpf does not support your arch."
This is a follow up patch of:
commit b0c47807d3 ("bpf: Add sparc support to tools and samples.")
commit bad1926dd2 ("bpf, s390: fix build for libbpf and selftest suite")
commit ca31ca8247 ("tools/bpf: fix perf build error with uClibc (seen on ARC)")
commit e32cb12ff5 ("bpf, mips: Fix build errors about __NR_bpf undeclared")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260526063936.16769-1-yangtiezhu@loongson.cn
Jakub Kicinski says:
====================
docs: net: updates for old and cobwebbed docs
I'm hoping to start feeding our docs into the AI review tools, instead
of maintaining a separate repo with review prompts. To experiment with
that we have to refresh the docs a little bit.
A read thru our current docs makes one slightly question the value
of including them in reviews. But directionally, I feel, it's probably
still right. I'm hoping the Rx Checksum section about not dropping packets
for example to be impactful. I don't think the current AI agents or
review docs include this guidance.
====================
Link: https://patch.msgid.link/20260526160151.2793354-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the segmentation offload documentation to match current GSO types:
- clarify csum_start for encapsulated TSO
- document TCP AccECN GSO and NETIF_F_GSO_ACCECN
- distinguish legacy UFO from UDP L4 GSO
- add ESP and fraglist GSO entries
Link: https://patch.msgid.link/20260526160151.2793354-11-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
checksum-offloads.rst seems like a better place to render
the checksum comment than skbuff.rst.
Remove the stale references to sections in that comment
(it no longer has A, B, C, D, E sections).
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260526160151.2793354-10-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Rx checksum processing gives people pause. The two main questions
in my experience are:
- what to do with bad IPv4 checksum; and
- what to do with packets with bad checksum.
Folks often feel the urge to drop the latter, to "avoid overloading
the host".
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260526160151.2793354-9-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the checksum offload documentation to match current code:
- SCTP CRC32c offload requires NETIF_F_SCTP_CRC, not ordinary IP
checksum offload
- NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM are restricted legacy
features; new devices should use NETIF_F_HW_CSUM
- GRE LCO is handled by the shared gre_build_header() helper used by
both IPv4 and IPv6 GRE
- VXLAN_F_REMCSUM_TX is a VXLAN configuration flag, not a field of
struct vxlan_rdst
Link: https://patch.msgid.link/20260526160151.2793354-8-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update netdev feature documentation for current locking rules and
feature semantics. Clarify hw_features updates and netdev_update_features()
locking, keep the NETIF_F_NEVER_CHANGE rule with the VLAN challenged
exception, fix the HSR duplication wording, and document netdev->netmem_tx
as a device flag rather than a feature bit.
Split the list of basic feature sets from the "extra" ones like
vlan_features. A bunch of the newer fields weren't documented and
having them all together would be confusing.
Link: https://patch.msgid.link/20260526160151.2793354-7-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the NAPI documentation to match current API behavior:
- repeated napi_disable() calls hang waiting for ownership, rather
than deadlock
- NAPI IDs are exposed through SO_INCOMING_NAPI_ID and netdev Netlink
- epoll uses the maxevents parameter spelling
- add that drivers holding the netdev instance lock may need _locked()
variants
Link: https://patch.msgid.link/20260526160151.2793354-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the code examples
- update the YNL sample with the latest(?) APIs
- struct dmabuf_tx_cmsg does not exist, use __u32 directly
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260526160151.2793354-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the kernel-internal ethtool stats list to match current code:
- spell the entries as "struct ethtool_*_stats", not as functions
- list the full set of structures, not only pause and fec
- mention that fields are pre-initialized to ETHTOOL_STAT_NOT_SET by
ethtool_stats_init() and drivers should leave unsupported fields at
that value rather than zeroing them
Link: https://patch.msgid.link/20260526160151.2793354-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Update the driver documentation TX queue example to match current APIs:
- use the ring-local tx_ring_mask field in drv_tx_avail()
- stop the selected netdev_queue with netif_tx_stop_queue() instead of
stopping queue 0 with netif_stop_queue()
Link: https://patch.msgid.link/20260526160151.2793354-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A handful of unrelated nits:
- free_netdevice() does not exist; replace two stray references
with free_netdev().
- The simple-driver probe example fell through into err_undo after
register_netdev() success; add return 0 for clarity.
- Clarify the netdev_priv() paragraph: "(netdev_priv())" was easy
to misread as the thing that needs explicit freeing; spell out
that it refers to extra pointers stored in the device private
struct.
- ndo_setup_tc synchronization note: TC_SETUP_BLOCK / TC_SETUP_FT
actually run under block->cb_lock, not "NFT locks", and rtnl_lock
may or may not be held depending on path.
- ->lltx guidance reads as very outdated, it's not really deprecated.
I suspect people may have been trying to use it for HW drivers
in the past but I can't think of such a case in the last decade.
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260526160151.2793354-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
While testing perf with an updated Debian experimental cross compiler
(gcc version 14.2.0 (Debian 14.2.0-13)) this started failing:
In file included from tests/hwmon_pmu.c:12:
tests/hwmon_pmu.c: In function 'do_test':
tests/hwmon_pmu.c:199:34: error: format '%lld' expects argument of type 'long long int', but argument 7 has type '__u64' {aka 'long unsigned int'} [-Werror=format=]
199 | pr_debug("FAILED %s:%d Unexpected config for '%s', %lld != %ld\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/git/perf-7.1.0-rc5/tools/perf/util/debug.h:20:21: note: in definition of macro 'pr_fmt'
20 | #define pr_fmt(fmt) fmt
| ^~~
tests/hwmon_pmu.c:199:25: note: in expansion of macro 'pr_debug'
199 | pr_debug("FAILED %s:%d Unexpected config for '%s', %lld != %ld\n",
| ^~~~~~~~
tests/hwmon_pmu.c:199:79: note: format string is defined here
199 | pr_debug("FAILED %s:%d Unexpected config for '%s', %lld != %ld\n",
| ~~~^
| |
| long long int
| %ld
LD /tmp/build/perf/util/intel-pt-decoder/perf-util-in.o
The usual make that %lld a PRIu64 (since arg7 is
evsel->core.attr.config, which is a __u64) but then on Fedora 44 (gcc
version 16.1.1 20260515 (Red Hat 16.1.1-2)) it ends up with:
In file included from tests/hwmon_pmu.c:13:
tests/hwmon_pmu.c: In function ‘do_test’:
tests/hwmon_pmu.c:200:34: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘__u64’ {aka ‘long long unsigned int’} [-Werror=format=]
200 | pr_debug("FAILED %s:%d Unexpected config for '%s', %" PRIu64 " != %ld\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/acme/git/perf-tools-next2/tools/perf/util/debug.h:20:21: note: in definition of macro ‘pr_fmt’
20 | #define pr_fmt(fmt) fmt
| ^~~
tests/hwmon_pmu.c:200:25: note: in expansion of macro ‘pr_debug’
200 | pr_debug("FAILED %s:%d Unexpected config for '%s', %" PRIu64 " != %ld\n",
| ^~~~~~~~
cc1: all warnings being treated as errors
So the way to satisfy both compilers is to also add a (u64) cast to
arg7.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When rustc prints an error containing a long type that doesn't fit in a
line, it will write the whole thing in a .txt file and print messages
like:
note: the full type name has been written to
'path/to/subsystem/module_name.long-type-11621316855315349594.txt'
[ Depending on the compiler version and the kind of error, there are
two possible spellings -- copying them here for reference:
= note: the full name for the type has been written to '...long-type-...txt'
= note: the full type name has been written to '...long-type-...txt'
In addition, we could clean the files as well in one of our
cleaning Make targets [1][2].
Another option would be `--verbose` (but it implies more things
that we probably don't want) or `-Zwrite-long-types-to-disk=no`
(unstable so far, but a possible alternative if we prefer to
avoid the files and simply see the long types in the output
-- I asked upstream Rust about it [3]).
Link: https://lore.kernel.org/rust-for-linux/CANiq72=cKXdmxEacuGET8fuz_v5eFGB50vnOnKZZJd6iEeAAFA@mail.gmail.com/ [1]
Link: https://github.com/Rust-for-Linux/linux/issues/1236 [2]
Link: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.60-Zwrite-long-types-to-disk.3Dno.60/near/598310194 [3]
- Miguel ]
Long types like core::result::Result<core::pin::Pin<Box<_, Kmalloc,
kernel::error::Error>: pin_init::PinInit<Box<_, Kmalloc>, _> are common
during development, so add a gitignore entry.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260521-rust-gitignore-long-types-txt-v1-1-5be5e6fa427c@pitsidianak.is
[ Moved the lines closer to the existing rust-analyzer one. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
strset_add_str_mem() might reallocate the strset data buffer in order to
accommodate the provided string 's'. However, if 's' points to a string
already present in the buffer, it becomes dangling after the realloc.
This leads to a use-after-free when attempting to memcpy() the string
into the new buffer.
One scenario that triggers this problematic path is when resolve_btfids
attempts to patch kfunc prototypes using existing BTF parameter names:
| resolve_btfids: function bpf_list_push_back_impl already exists in BTF
| Segmentation fault (core dumped)
Compiling resolve_btfids with fsanitize=address generates a detailed
report of the UAF:
| =================================================================
| ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4
| ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818
| READ of size 5 at 0x7f4c4a500bd4 thread T0
| #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7)
| #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2
| #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8
| #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14
| #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9
| #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9
| #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6
| #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
| #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3
| #9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860)
|
| 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8)
| freed by thread T0 here:
| #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700)
| #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9
| #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13
|
| previously allocated by thread T0 here:
| #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3)
| #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20
While resolve_btfids could be refactored to avoid this call path, let's
instead fix this issue at the source in strset__add_str() and avoid
similar scenarios.
Let's check if set->strs_data was reallocated and whether 's' points to
an internal string within the old strset buffer. In such case, 's' is
reconstructed to point to the new buffer.
While already here, also fix strset__find_str() which suffers from the
same problem by factoring out the common operations into a new helper
function strset_str_append().
Fixes: 90d76d3ece ("libbpf: Extract internal set-of-strings datastructure APIs")
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Suggested-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260523162722.2718940-1-cmllamas@google.com
When generating light skeletons for BPF programs containing struct_ops
maps, bpftool incorrectly outputs a stray literal 't' instead of a tab
character for the map file descriptor member in the links structure.
This causes a compilation error when the generated light skeleton is
used.
Correct the format string by replacing 't' with '\t'.
Fixes: 08ac454e25 ("libbpf: Auto-attach struct_ops BPF maps in BPF skeleton")
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/bpf/20260520-struct_ops_gen_typo_fix-v1-1-4dee3771da46@google.com
parse_vma_segs() in tools/lib/bpf/usdt.c parses /proc/<pid>/maps
with two widthless scansets, "%s" into mode[16] and "%[^\n]"
into line[4096]. A VMA name in maps is not limited to that local
buffer; a deeply nested backing path can produce a maps record long
enough to overflow the stack buffer.
Bound both scansets to the declared buffer sizes ("%15s" for mode[16]
and "%4095[^\n]" for line[4096]) and drain any residue past line[4094]
with "%*[^\n]" before the trailing "\n". Without the drain, the residue
of an over-long record would stay in the stream and break the next
"%zx-%zx" parse, so the loop would exit early and silently skip later
maps records.
Also stop using sscanf(..., "%s") to peel the /proc/<pid>/root prefix
from lib_path. Parse the pid and prefix length with "%n", check for the
following slash, and copy the remainder with libbpf_strlcpy(). That
removes a second unbounded stack write and preserves paths containing
spaces.
Fixes: 74cc6311ce ("libbpf: Add USDT notes parsing and resolution logic")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260522201353.1454653-1-michael.bommarito@gmail.com
The PMC found on Tegra238 is similar to the version in earlier chips but
some of the register offsets and bitfields differ, so add a specific
compatible string for this new variant.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Register the MAX77620 PMIC as the system power controller on Pixel C so
the driver can install its sys-off handler.
This allows the PMIC poweroff sequence to override the non-working PSCI
SYSTEM_OFF implementation on this platform.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
