The 15 patch limit is intended by the maintainers to cover
all outstanding patches on the mailing list on a per-tree basis.
Not just those in a single patchset. Document this practice accordingly.
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260115-15-minutes-of-fame-v2-1-70cbf0883aff@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It is only called from __tcp_transmit_skb() and __tcp_retransmit_skb().
Move it in tcp_output.c and make it static.
clang compiler is now able to inline it from __tcp_transmit_skb().
gcc compiler inlines it in the two callers, which is also fine.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Link: https://patch.msgid.link/20260114165109.1747722-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On the receive path, packet can be damaged because of buffer
overflow in Rx FIFO. Avoid misleading per-packet error log when
packet->errors is set, this can flood the log. Instead, rely on the
standard rtnl_link_stats64 stats.
Fixes: c5aa9e3b81 ("amd-xgbe: Initial AMD 10GbE platform driver")
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20260114163037.2062606-1-Raju.Rangoju@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- ALE_VERSION_MAJOR/MINOR are no longer used following the transition to
regmaps in commit bbfc7e2b9e ("net: ethernet: ti: cpsw_ale: use
regfields for ALE registers")
- ALE_VERSION_IR3 is unused since entry mask bits are no longer
hardcoded with commit b5d31f2940 ("net: ethernet: ti: ale: optimize
ale entry mask bits configuartion")
- ALE_VERSION_IR4 has never been used since its introduction in commit
ca47130a74 ("net: netcp: ale: update to support unknown vlan
controls for NU switch")
Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
Link: https://patch.msgid.link/20260114144425.3973272-1-stefan.wiehler@nokia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
0 is a valid DMA address [1] so using it as the error value can lead to
errors. The error value of dma_map_XXX() functions is DMA_MAPPING_ERROR
which is ~0. The callers of otx2_dma_map_page() use dma_mapping_error()
to test the return value of otx2_dma_map_page(). This means that they
would not detect an error in otx2_dma_map_page().
Make otx2_dma_map_page() return the raw value of dma_map_page_attrs().
[1] https://lore.kernel.org/all/f977f68b-cec5-4ab7-b4bd-2cf6aca46267@intel.com
Fixes: caa2da34fd ("octeontx2-pf: Initialize and config queues")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Link: https://patch.msgid.link/20260114123107.42387-2-fourier.thomas@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo pointed out that we can avoid separately allocating struct
cake_sched_config even in the non-mq case, by embedding it into struct
cake_sched_data. This reduces the complexity of the logic that swaps the
pointers and frees the old value, at the cost of adding 56 bytes to the
latter. Since cake_sched_data is already almost 17k bytes, this seems
like a reasonable tradeoff.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Fixes: bc0ce2bad3 ("net/sched: sch_cake: Factor out config variables into separate struct")
Link: https://patch.msgid.link/20260113143157.2581680-1-toke@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Expand the tls-offload.rst documentation to provide a more detailed
explanation of the asynchronous resync process, including the role
of struct tls_offload_resync_async in managing resync requests on
the kernel side.
Also, add documentation for helper functions
tls_offload_rx_resync_async_request_start/ _end/ _cancel.
Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/1768298883-1602599-1-git-send-email-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Thomas Weißschuh says:
====================
uapi: Use UAPI definitions of INT_MAX and INT_MIN
Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
dependency on a libc, which UAPI headers should not do.
Introduce and use equivalent UAPI constants.
====================
Link: https://patch.msgid.link/20260113-uapi-limits-v2-0-93c20f4b2c1a@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
dependency on a libc, which UAPI headers should not do.
Use the equivalent UAPI constants.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260113-uapi-limits-v2-3-93c20f4b2c1a@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Using <limits.h> to gain access to INT_MAX introduces a dependency on a
libc, which UAPI headers should not do.
Use the equivalent UAPI constant.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260113-uapi-limits-v2-2-93c20f4b2c1a@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some UAPI headers use INT_MAX and INT_MIN. Currently they include
<limits.h> for their definitions, which introduces a problematic
dependency on libc.
Add custom, namespaced definitions of INT_MAX and INT_MIN using the
same values as the regular kernel code.
These definitions are not added to uapi/linux/limits.h, as that header
will conflict with libc definitions on some platforms.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260113-uapi-limits-v2-1-93c20f4b2c1a@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This device does not have a MII, even though the driver
contains code to drive one (because it originated as a copy of the
dm9601 driver). It also only supports 10Mbps half-duplex
operation (the DM9601 registers to set the speed/duplex mode
are read-only). Remove all MII-related code and implement
sr9700_get_link_ksettings which returns hardcoded correct
information for the link speed and duplex mode. Also add
announcement of the link status like many other Ethernet
drivers have.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Link: https://patch.msgid.link/20260113040649.54248-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lad Prabhakar says:
====================
net: pcs: rzn1-miic: Support configurable PHY_LINK polarity
This series adds support for configuring the active level of MIIC
PHY_LINK status signals on Renesas RZ/N1 and RZ/T2H/N2H platforms.
The MIIC block provides dedicated hardware PHY_LINK signals that indicate
EtherPHY link-up and link-down status independently of whether the MAC
(GMAC) or Ethernet switch (ETHSW) is used. While GMAC-based systems
typically obtain link state via MDIO and handle it in software, the
ETHSW relies on these PHY_LINK pins for both CPU-assisted operation and
switch-only forwarding paths that do not involve the host processor.
These hardware PHY_LINK signals are particularly important for use cases
requiring fast reaction to link-down events, such as redundancy protocols
including Device Level Ring (DLR). In such scenarios, relying solely on
software-based link detection introduces latency that can negatively
impact recovery time. The ETHSW therefore exposes PHY_LINK signals to
enable immediate hardware-level detection of cable or port failures.
Some systems require the PHY_LINK signal polarity to be configured as
active low rather than the default active high. This series introduces a
new DT property to describe the required polarity and adds corresponding
driver support to program the MIIC PHY_LINK register accordingly. The
configuration is accumulated during DT parsing and applied once hardware
initialization is complete, taking into account SoC-specific differences
between RZ/N1 and RZ/T2H/N2H.
====================
Link: https://patch.msgid.link/20260112173555.1166714-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add support to configure the active level of MIIC PHY_LINK status signals
on a per-converter basis using a DT property.
MIIC provides dedicated PHY_LINK signals that indicate EtherPHY link-up and
link-down status in hardware. These signals are required regardless of
whether GMAC or ETHSW is used. With GMAC, link state is retrieved via
MDC/MDIO and handled in software, while ETHSW relies on PHY_LINK pins for
both CPU-assisted operation and switch-only data paths that do not involve
the host.
Hardware PHY_LINK signals are also critical for fast reaction to link-down
events, for example when running redundancy protocols such as Device Level
Ring (DLR), where rapid detection of cable faults is required to switch to
an alternate path without software latency.
Parse the requested polarity from DT, accumulate the configuration during
probing, and apply it to the MIIC_PHY_LINK register once hardware
initialization is complete, when the registers can be safely modified.
Handle SoC-specific bit layout differences between RZ/N1 and RZ/T2H/N2H
within the driver.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20260112173555.1166714-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the renesas,miic-phy-link-active-low property to allow configuring
the active level of phy_link status signals provided by the MIIC block.
EtherPHY link-up and link-down status is required as a hardware IP
feature independent of whether GMAC or ETHSW is used. With GMAC, link
state is retrieved via MDC/MDIO and handled in software. In contrast,
ETHSW exposes dedicated PHY_LINK pins that provide this information
directly in hardware.
These PHY_LINK signals are required not only for host-controlled traffic
but also for switch-only forwarding paths where frames are exchanged
between external nodes without CPU involvement. This is particularly
important for redundancy protocols such as DLR (Device Level Ring),
which depend on fast detection of link-down events caused by cable or
port failures. Handling such events purely in software introduces
latency, which is why ETHSW provides dedicated hardware PHY_LINK pins.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260112173555.1166714-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads
will return "val" from the i2c bus driver. For i2c-aspeed and
i2c-npcm7xx that is a stack uninitialised u8.
Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c
instance, now it returns all 0xff.
Fixes: f5b8abf9fc ("mctp i2c: MCTP I2C binding driver")
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key
initialization fails:
==================================================================
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2
RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]
RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401
Call Trace:
sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189
sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111
sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217
sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169
sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052
sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88
sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243
sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127
The issue is triggered when sctp_auth_asoc_init_active_key() fails in
sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the
command sequence is currently:
- SCTP_CMD_PEER_INIT
- SCTP_CMD_TIMER_STOP (T1_INIT)
- SCTP_CMD_TIMER_START (T1_COOKIE)
- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)
- SCTP_CMD_ASSOC_SHKEY
- SCTP_CMD_GEN_COOKIE_ECHO
If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while
asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by
SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL
to be queued by sctp_datamsg_from_user().
Since command interpretation stops on failure, no COOKIE_ECHO should been
sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already
been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As
a result, the DATA chunk can be transmitted together with the COOKIE_ECHO
in sctp_outq_flush_data(), leading to the observed issue.
Similar to the other places where it calls sctp_auth_asoc_init_active_key()
right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY
immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting
T1_COOKIE. This ensures that if shared key generation fails, authenticated
DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,
giving the client another chance to process INIT_ACK and retry key setup.
Fixes: 730fc3d05c ("[SCTP]: Implete SCTP-AUTH parameter processing")
Reported-by: Zhen Chen <chenzhen126@huawei.com>
Tested-by: Zhen Chen <chenzhen126@huawei.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/44881224b375aa8853f5e19b4055a1a56d895813.1768324226.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Document the Inter-Processor Communication Controller on the Qualcomm
Kaanapali and Glymur Platforms, which will be used to route interrupts
across various subsystems found on the SoC.
Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20251031-knp-ipcc-v3-1-62ffb4168dff@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Some parallel panels have a pixelclk of 24.19 MHz. Add support for
241.90 MHz so a by 10 divider can be used to derive the exact pixelclk.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20260113-v6-18-topic-clk-fracn-gppll-v3-2-45da70f43c98@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Some parallel panels have a pixelclk of 33.260 MHz. Add support for
332.60 MHz so a by 10 divider can be used to derive the exact pixelclk.
Reviewed-by: Primoz Fiser <primoz.fiser@norik.com>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://patch.msgid.link/20260113-v6-18-topic-clk-fracn-gppll-v3-1-45da70f43c98@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Enable the cmu_dpu clock management unit. It feeds some of the display
IPs. Additionally add the sysreg_dpu node which contains the
BUSCOMPONENT_DRCG_EN and MEMCLK registers required by cmu_dpu to enable
dynamic root clock gating of bus components.
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260113-dpu-clocks-v3-5-cb85424f2c72@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
cmu_dpu is the clock management unit used for the Display Process Unit
block. It generates clocks for image scaler, compressor etc.
Add support for the muxes, dividers and gates in cmu_dpu.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260113-dpu-clocks-v3-4-cb85424f2c72@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Add dedicated compatibles for gs101 dpu sysreg controllers to the
documentation.
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260113-dpu-clocks-v3-3-cb85424f2c72@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Add dt schema documentation and clock IDs for the Display Process Unit
(DPU) clock management unit (CMU). This CMU feeds IPs such as image scaler,
enhancer and compressor.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260113-dpu-clocks-v3-2-cb85424f2c72@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Ensure children of cmu_top have alphanumeric ordering. Top is special as it
feeds all the other children CMUs. This ordering then matches the
clk-gs101.c file.
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260113-dpu-clocks-v3-1-cb85424f2c72@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Currently, sysreg registers of a CMU that has PM and automatic clock
gating enabled are not saved / restored during runtime PM (RPM) or
s2idle. During normal suspend, they are accessed too late, after the
CMU (and potentially power domain) have been shut down, causing an
SError.
The reason is that these registers are registered to be saved/restored
via a syscore suspend handler which doesn't run during RPM or s2idle.
During normal suspend, this handler runs after the CMU has been shut
down. This registration happens as part of
samsung_clk_extended_sleep_init() via samsung_en_dyn_root_clk_gating().
When PM is enabled for a CMU, registers must be saved/restored via
exynos_arm64_cmu_suspend() / exynos_arm64_cmu_resume() respectively
instead. These use their own data structures and are unrelated to
anything that samsung_clk_extended_sleep_init() does. Calling it
unconditionally from samsung_en_dyn_root_clk_gating() therefore isn't
useful.
Update the code to prepare sysreg save / restore in a similar way to
how it handles other clock registers in the PM case already.
exynos_arm64_cmu_suspend() / exynos_arm64_cmu_resume() already handle
sysreg save/restore, just the setup was incorrect.
Fixes: 298fac4f4b ("clk: samsung: Implement automatic clock gating mode for CMUs")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260109-clk-samsung-autoclk-updates-v1-2-2394dcf242a9@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
We currently print a warning message that the IO memory size is not
compatible with automatic clock gating for many Exynos-based boards,
including legacy ones, even if not requested to enable automatic clock
gating in the first place.
Change the test in question to avoid that warning.
Fixes: 298fac4f4b ("clk: samsung: Implement automatic clock gating mode for CMUs")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/8b2c412d-3e1e-4be0-a9d5-ef67f6f0d409@samsung.com/
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260109-clk-samsung-autoclk-updates-v1-1-2394dcf242a9@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
A lot of SoC series end up getting CCed to the hardening list due to
their mention of "pstore" in device tree or similar, and this noise isn't
worth making sure I don't lose pstore patches by having them show up in
the hardening patchwork. ;) I can use better email filters instead!
Link: https://patch.msgid.link/20260116005631.work.387-kees@kernel.org
Signed-off-by: Kees Cook <kees@kernel.org>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with flexible-array members in the
middle of other structs, we use the `struct_group_tagged()` helper
to separate the flexible array from the rest of the members in the
flexible structure. We then use the newly created tagged `struct
nfp_crypto_req_add_front_hdr` to replace the type of the objects
causing trouble in a couple of structures.
We also want to ensure that when new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.
Lastly, use container_of() to retrieve a pointer to the flexible
structure and, through that, access the flexible-array member when
needed.
So, with these changes, fix the following warnings:
drivers/net/ethernet/netronome/nfp/nfd3/../crypto/fw.h:58:41: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/ethernet/netronome/nfp/nfd3/../crypto/fw.h:65:41: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://patch.msgid.link/aSfDqouLFcA4h8JX@kspp
Signed-off-by: Kees Cook <kees@kernel.org>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Move the conflicting declaration (which happens to be in a union, so
we're moving the entire union) to the end of the corresponding
structure. Notice that `struct carl9170_rsp` is a flexible structure,
this is a structure that contains a flexible-array member.
With these changes fix the following warning:
drivers/net/wireless/ath/carl9170/carl9170.h:382:9: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://patch.msgid.link/aR1yxjmzb2DM2-Uq@kspp
Signed-off-by: Kees Cook <kees@kernel.org>
Introduce __counted_by_ptr(), which works like __counted_by(), but for
pointer struct members.
struct foo {
int a, b, c;
char *buffer __counted_by_ptr(bytes);
short nr_bars;
struct bar *bars __counted_by_ptr(nr_bars);
size_t bytes;
};
Because "counted_by" can only be applied to pointer members in very
recent compiler versions, its application ends up needing to be distinct
from flexibe array "counted_by" annotations, hence a separate macro.
This is a reworking of Kees' previous patch [1].
Link: https://lore.kernel.org/all/20251020220118.1226740-1-kees@kernel.org/ [1]
Co-developed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Bill Wendling <morbo@google.com>
Link: https://patch.msgid.link/20260116005838.2419118-1-morbo@google.com
Signed-off-by: Kees Cook <kees@kernel.org>
On the Dell G15 5510, fans spin at maximum speed when AC power is
connected. This behavior has been observed as a regression in recent
kernels (v6.18+).
Add the Dell G15 5510 to the fan control whitelist to enable manual fan
control and resolve the issue. This model requires the same fan control
configuration as the Dell G15 5511.
Fixes: 1c1658058c ("hwmon: (dell-smm) Add support for automatic fan mode")
Signed-off-by: Leo Banno-Cloutier <leobannocloutier@gmail.com>
Link: https://lore.kernel.org/r/20260117015315.214569-2-leobannocloutier@gmail.com
[groeck: Updated patch description to follow guidance]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When the mutex 'link_event_lock' was introduced, it was never
initialized and it triggers kernel warnings when used with locking
debug turned on. Add initialization for the mutex.
Fixes: 3db835dd8f ("ntb: Add mutex to make link_event_callback executed linearly.")
Cc: fuyuanli <fuyuanli0722@gmail.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
(atomicity not required). For kunit testing, the structure is packed to
avoid memcmp() errors but this affects atomic bitops as they have strict
alignment requirements.
Also remove a duplicate include in the mpam driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmlrlm0ACgkQa9axLQDI
XvHAXg/9Fk91bQjJzqSY3oPdDyY+H9VC49iS89OIiJb5Bw+2p+0/vJw10ujhCQ3I
A0GJs4DvjBJbqBqYhZ0lIZtKrKCfNsa3Ej3RqlZfRh6BtQK+EfcE7IxyYXevuDOc
wLUqrVQJpx2T6fzus2XMRFLGn8kRGnq+eCysEFCjRxqCQcxcLaokWrX2tYAbgBtb
E3EjA2mQkpQQgkBUbCODUa4aHZggGPO7oiWGi6KfyuYbJ/GnKRDWdLg2WsqnI1E6
DnVuonfkXIc+8glnTkqh8T3M4NEQxYxBBpraeyuWdzIhzK0oNp5uChCNeG+oPAOd
FAQ0oN/2W+KpAdX16eYoZcc4AhXaOoNuVPtcw1M18VhCIVhQ8l8GlXVjKX8HPtzs
DWk/pG1hgmTtmww8BS2Vjx5hxJXcsQGACQ4KZ61VkPUJpMIARDxlB/+hXGTO34bM
E5SheukLH46kLRzU5hJmC6BChHBLcSUj4fo0MKsM/4iiagrRi/G/Sbll33HYFEO9
ksIayBMX0lLylMeCg00+QovA+7MiNnMEAgdvKhnIoJo2bdXG7z+mt2S1LXjuGY9J
czsfSCuDgb413REAi+VKv7Ow+fOwUSUWjiFgoi70Jy/hIoiGdyPlWiuu6ayb/qsP
ghe6deDdNx7Hx5+iYLTFAIiV8yT8EOTsbEmGdJi6vSVYiOcclJw=
=lmDb
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
"An arm64/mpam fix to use non-atomic bitops on struct mmap_props member
(atomicity not required).
For kunit testing, the structure is packed to avoid memcmp() errors
but this affects atomic bitops as they have strict alignment
requirements.
Also remove a duplicate include in the mpam driver"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm_mpam: Use non-atomic bitops when modifying feature bitmap
arm_mpam: Remove duplicate linux/srcu.h header
The SPCR provided console on x86 is only available as a boot console when
earlycon is provided on the kernel command line, and will not be present in
/proc/consoles.
While it's possible to retain the boot console with the keep_bootcon
parameter, that leaves the console using the less efficient 8250_early driver.
Users wanting to use the firmware suggested console (to avoid maintaining
unique serial console parameters for different server models in large fleets)
with the conventional driver have to parse the kernel log for the console
parameters and reinsert them.
[ 0.005091] ACPI: SPCR 0x000000007FFB5000 000059 (v04 ALASKA A M I 01072009 INTL 20250404)
[ 0.073387] ACPI: SPCR: console: uart,io,0x3f8,115200
In commit
0231d00082 ("ACPI: SPCR: Make SPCR available to x86")¹
the SPCR console was only added as an option for earlycon but not as an
ordinary console so users don't see console output changes.
So users can opt in to an automatic SPCR console, make ACPI init add it if
acpi=spcr is set.
¹https://lore.kernel.org/lkml/20180118150951.28964-1-prarit@redhat.com/
[ bp: Touchups. ]
Signed-off-by: Shenghao Yang <me@shenghaoyang.info>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260117072827.355360-1-me@shenghaoyang.info
of_find_node_by_path() returns a device_node with its refcount
incremented. When kstrtoint() fails or dt_alloc() fails, the function
continues to the next iteration without calling of_node_put(), causing
a reference count leak.
Add of_node_put(np) before continue on both error paths to properly
release the device_node reference.
Fixes: 611cad7201 ("dt: add of_alias_scan and of_alias_get_id")
Cc: stable@vger.kernel.org
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Link: https://patch.msgid.link/20260117091238.481243-1-geoffreyhe2@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
While pci_read() and pci_write() have returned errno values since their
inception with commit cd24834130 ("s390/pci: base support") other
config accessors in particular pci_generic_config_read() as well as
pci_generic_config_write() return specific error values which are then
converted to errno by pcibios_err_to_errno(). Since latter does handle
the case where the error value already looks like an errno the previous
behavior is unlikely to cause actual issues.
Still, for consistency and in case any caller explicitly checks error
values align pci_read() and pci_write() with the generic accessors.
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
On s390 PCI busses and slots with multiple functions may have holes
because PCI functions are passed-through by the hypervisor on a per
function basis and some functions may be in standby or reserved. This
fact is indicated by returning true from the
hypervisor_isolated_pci_functions() helper and triggers common code to
scan all possible devfn values. Via pci_scan_single_device() this in
turn causes config reads for the device and vendor IDs, even for PCI
functions which are in standby and thereofore disabled.
So far these futile config reads, as well as potentially writes, which
can never succeed were handled by the PCI load/store instructions
themselves. This works as the platform just returns an error for
a disabled and thus not usable function handle. It does cause spamming
of error logs and additional overhead though.
Instead check if the used function handle is enabled in zpci_cfg_load()
and zpci_cfg_write() and if not enable directly return -ENODEV. Also
refactor zpci_cfg_load() and zpci_cfg_store() slightly to accommodate
the new logic while meeting modern kernel style guidelines.
Cc: stable@vger.kernel.org
Fixes: a50297cf82 ("s390/pci: separate zbus creation from scanning")
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Heiko Carstens says:
====================
The option to select PREEMPT_NONE will go away for all architectures which
support PREEMPT_LAZY [1]. Until now all distributions provide kernels built
with PREEMPT_NONE enabled for s390. In particular this means that all
preempt_disable() / preempt_enable() pairs are optimized away during
compile time.
With PREEMPT_LAZY this is not the case. Switching to PREEMPT_LAZY leads
to a kernel image size increase of ~218kb (defconfig, gcc15).
s390 provides optimized preempt primitives, however there is still room for
improvement. Since support for relocatable lowcore was added access to
preempt_count in lowcore requires an extra call of get_lowcore(), which
generates an extra instruction. Also all instructions have to use a base
register which is not zero to access preempt_count.
Address this by adding a couple of inline assemblies with alternatives.
This generates better code and reduces the size of a PREEMPT_LAZY built
kernel image by ~58kb.
[1] https://lore.kernel.org/all/20251219101502.GB1132199@noisy.programming.kicks-ass.net/
====================
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Provide an inline assembly using alternatives to avoid the need of a
base register due to relocatable lowcore when adding or subtracting
small constants from preempt_count.
Main user is preempt_enable(), which subtracts one from preempt_count
and tests if the result is zero.
With this the generated code changes from
1000b8: a7 19 00 00 lghi %r1,0
1000bc: eb ff 13 a8 00 6e alsi 936(%r1),-1
1000c2: a7 54 00 05 jnhe 1000cc <__rcu_read_unlock+0x14>
to something like this:
1000b8: eb ff 03 a8 00 6e alsi 936,-1
1000be: a7 54 00 05 jnhe 1000c8 <__rcu_read_unlock+0x10>
Kernel image size is reduced by 45kb (bloat-o-meter -t, defconfig, gcc15).
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
With the empty define __is_enabled(__HAVE_ASM_FLAG_OUTPUTS__)
evaluates to false. Therefore let __HAVE_ASM_FLAG_OUTPUTS__ define 1
if it is defined.
This allows to make use of __is_defined(__HAVE_ASM_FLAG_OUTPUTS__)
like expected.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Provide an inline assembly using alternatives to avoid the need of a
base register due to relocatable lowcore when adding or subtracting
small constants from preempt_count.
Main user is preempt_disable(), which subtracts one from
preempt_count. With this the generated code changes from
10012c: a7 b9 00 00 lghi %r11,0
100130: eb 01 b3 a8 00 6a asi 936(%r11),1
to something like this:
10012c: eb 01 03 a8 00 6a asi 936,1
Kernel image size is reduced by 13kb (bloat-o-meter -t, defconfig, gcc15).
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Provide an inline assembly using alternatives to avoid the need of
a base register when reading preempt_count() from lowcore. Use the
LLGT instruction, which reads only the least significant 31 bits of
preempt_count. This masks out the encoded PREEMPT_NEED_RESCHED bit.
Generated code is changed from
000000000046e5d0 <vfree>:
46e5d0: c0 04 00 00 00 00 jgnop 46e5d0 <vfree>
46e5d6: a7 39 00 00 lghi %r3,0
46e5da: 58 10 33 a8 l %r1,936(%r3)
46e5de: c0 1b 00 ff ff 00 nilf %r1,16776960
46e5e4: a7 74 00 11 jne 46e606 <vfree+0x36>
to something like this:
000000000046e5d0 <vfree>:
46e5d0: c0 04 00 00 00 00 jgnop 46e5d0 <vfree>
46e5d6: e3 10 03 a8 00 17 llgt %r1,936
46e5dc: ec 41 28 b7 00 55 risbgz %r4,%r1,40,55
46e5e2: a7 74 00 0f jne 46e600 <vfree+0x30>
Overall savings are only 82 bytes according to bloat-o-meter. This
is because of different inlining decisions, and there aren't many
preempt_count() users in the kernel.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The s390 vDSO source directory was recently moved,
but this reference was not updated.
Fixes: c0087d807a ("s390/vdso: Rename vdso64 to vdso")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
For some reason gcc 8, 9, 10, and 11 generate a dynamic relocation in
vdso.so.dbg if CONFIG_KSTACK_ERASE is enabled:
>> arch/s390/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported
make[3]: *** [arch/s390/kernel/vdso/Makefile:54: arch/s390/kernel/vdso/vdso.so.dbg] Error 1
$ readelf -rW arch/s390/kernel/vdso/vdso.so.dbg
Relocation section '.rela.dyn' at offset 0x15c0 contains 1 entry:
Offset Info Type Symbol's Value Symbol's Name + Addend
00000000000015f0 000000010000000b R_390_JMP_SLOT 0000000000000000 __sanitizer_cov_stack_depth + 0
Add $(DISABLE_KSTACK_ERASE) to vdso compile flags to fix this.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202601070505.xQcLr5KV-lkp@intel.com/
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The PM reference count is not expected to be incremented on return in
functions starfive_wdt_probe.
However, pm_runtime_get_sync will increment pm usage counter
even failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: db728ea9c7 ("drivers: watchdog: Add StarFive Watchdog driver")
Signed-off-by: Kery Qi <qikeyu2017@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
