Introduce an exported shutdown function to safely shutdown the
DesignWare I2C controller.
This shutdown hook gracefully sets the target disable bit before disabling
the controller. This guarantees that any incoming requests from the
controller are immediately NACKed during shutdown, preventing the bus from
hanging.
Signed-off-by: William A. Kennington III <william@wkennington.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260527-dw-i2c-v5-1-3483057f8d67@wkennington.com
Danilo Krummrich <dakr@kernel.org> says:
Currently, Rust device drivers access device resources such as PCI BAR mappings
and I/O memory regions through Devres<T>.
Devres::access() provides zero-overhead access by taking a &Device<Bound>
reference as proof that the device is still bound. Since a &Device<Bound> is
available in almost all contexts by design, Devres is mostly a type-system level
proof that the resource is valid, but it can also be used from scopes without
this guarantee through its try_access() accessor.
This works well in general, but has a few limitations:
- Every access to a device resource goes through Devres::access(), which
despite zero cost, adds boilerplate to every access site.
- Destructors do not receive a &Device<Bound>, so they must use try_access(),
which can fail. In practice the access succeeds if teardown ordering is
correct, but the type system can't express this, forcing drivers to handle a
failure path that should never be taken.
- Sharing a resource across components (e.g. passing a BAR to a sub-component)
requires Arc<Devres<T>>.
- Device references must be stored as ARef<Device> rather than plain &Device
borrows.
These limitations stem from the driver's bus device private data being 'static
-- the driver struct cannot borrow from the device reference it receives in
probe(), even though it structurally cannot outlive the device binding.
This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device
drivers. An HRT is a type that is generic over a lifetime -- it does not have a
fixed lifetime, but can be instantiated with any lifetime chosen by the caller.
Bus driver traits use a Generic Associated Type (GAT) type Data<'bound> to
introduce the lifetime on the private data, rather than parameterizing the
Driver trait itself. This avoids a driver trait global lifetime and avoids the
need for ForLt for bus device private data, making the bus implementations much
simpler. ForLt is only needed for auxiliary registration data, where the
lifetime is not introduced by a trait callback but must be threaded through
Registration.
With HRT, driver structs carry a lifetime parameter tied to the device binding
scope -- the interval of a bus device being bound to a driver. Device resources
like pci::Bar<'bound> and IoMem<'bound> are handed out with this lifetime, so
the compiler enforces at build time that they do not escape the binding scope.
Before:
struct MyDriver {
pdev: ARef<pci::Device>,
bar: Devres<pci::Bar<BAR_SIZE>>,
}
let io = self.bar.access(dev)?;
io.read32(OFFSET);
After:
struct MyDriver<'bound> {
pdev: &'bound pci::Device,
bar: pci::Bar<'bound, BAR_SIZE>,
}
self.bar.read32(OFFSET);
Lifetime-parameterized device resources can be put into a Devres at any point
via Bar::into_devres() / IoMem::into_devres(), providing the exact same
semantics as before. This is useful for resources shared across subsystem
boundaries where revocation is needed.
This also synergizes with the upcoming self-referential initialization support
in pin-init, which allows one field of the driver struct to borrow another
during initialization without unsafe code.
The same pattern is applied to auxiliary device registration data as a first
example beyond bus device private data. Registration<F: ForLt> can hold
lifetime-parameterized data tied to the parent driver's binding scope. Since the
auxiliary bus guarantees that the parent remains bound while the auxiliary
device is registered, the registration data can safely borrow the parent's
device resources.
More generally, binding resource lifetimes to a registration scope applies to
every registration that is scoped to a driver binding -- auxiliary devices,
class devices, IRQ handlers, workqueues.
A follow-up series extends this to class device registrations, starting with
DRM, so that class device callbacks (IOCTLs, etc.) can safely access device
resources through the separate registration data bound to the registration's
lifetime without Devres indirection.
Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for
the early discussions around lifetime-parameterized private data that helped
shape the direction of this work.
Link: https://patch.msgid.link/20260525202921.124698-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Code in misc-ep93xx.h relies on machine_is_*() macros for several
boards that no longer have legacy board files. They were removed in
commit e5ef574dda ("ARM: ep93xx: delete all boardfiles"). This
prevents the removal of machine IDs no longer used by the kernel from
mach-types. To resolve this issue, create local copies of these macros.
(The checks themselves are still valid because the IDs are still passed
in by the bootloader on these machines.) Also take the opportunity to
remove three repeated checks for the same ID.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Alexander Sverdlin <asv@kernel.org>
Add FEAT_RENDER bool constant to the Driver trait to control
render node support. When enabled, the driver exposes /dev/dri/renderDXX
render nodes to userspace. The flag defaults to false, drivers can opt
in by setting it to true in their Driver implementation.
This is then enabled in the Tyr driver, while it's left disabled for
Nova for the time being.
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Laura Nao <laura.nao@collabora.com>
Link: https://patch.msgid.link/20260507080914.95478-2-laura.nao@collabora.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Using named initializers is more explicit and thus easier to parse for a
human.
While touching this array, drop explicit zeros from the list terminator.
This change doesn't introduce changes to the compiled zorro_device_id
array.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Max Staudt <max@enpas.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/3d7690c7a8948f977d6c50bd0c8010efb715fbdc.1779803053.git.u.kleine-koenig@baylibre.com
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
/ {
firmware {
ranges;
coreboot {
compatible = "coreboot";
reg = <...>;
...;
};
};
};
Notably, the /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add power domains found in Tegra114 and configure operating-points-v2 for
supported devices accordingly.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add DC interconnections to Tegra114 device tree to reflect connections
between MC, EMC and DC.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add EMC OPP tables and interconnect paths that will be used for dynamic
memory bandwidth scaling based on memory utilization statistics.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
/ {
firmware {
ranges;
coreboot {
compatible = "coreboot";
reg = <...>;
...;
};
};
};
Notably, the /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
