| Age | Commit message (Collapse) | Author |
|---|
|
Make it possible to decouple the registration of the DisplayPort
PHY driver from the DisplayPort IP driver by adding a devicetree
match to probe the PHY, registering an OF PHY provider and this
device's own MMIO regmap - if, and only if, this PHY driver was
registered with an OF match.
In order to retain compatibility with older devicetrees that are
not declaring the DisplayPort PHY as a separate node, the legacy
code was moved in a `mtk_dp_phy_legacy_probe()` function, which
gets called if the driver was registered by the DisplayPort one.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260910092038.48291-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
In preparation to perform further cleanups and to extend the
driver to support more SoCs, rename the `regs` member to `regmap`
to improve readability, as this is a common name across many
kernel drivers for a struct regmap.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260910092038.48291-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Selective fetch is dropped while pipe CRC is active, and the planes keep
their SEL_FETCH_PLANE_CTL / SEL_FETCH_CUR_CTL enable bit set in hardware
over that. A plane disabled while selective fetch is off never gets the
bit cleared, as the disable path is guarded by enable_psr2_sel_fetch.
Once selective fetch comes back the hardware resumes fetching for a
plane that is no longer enabled and keeps its DDB range reserved.
Clear the bits as selective fetch is turned off instead. Atomic check
has both the old and the new crtc state, so record the transition there
and let the plane and cursor arm paths write the registers to 0 for that
commit.
v2: Drop the old_crtc_state->hw.active check. [Jouni]
Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: Copilot:Claude-Opus-5
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-3-nemesa.garg@intel.com
|
|
This reverts commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a.
This commit replaced the crtc_state->enable_psr2_sel_fetch guard in
icl_plane_disable_sel_fetch_arm() and i9xx_cursor_disable_sel_fetch_arm()
with HAS_PSR2_SEL_FETCH(). This is a display version check and
says nothing about the pipe, so every plane and cursor disable on a
display 12+ platform started writing SEL_FETCH_PLANE_CTL() /
SEL_FETCH_CUR_CTL(), including on pipes that do not implement them.
It shows up as an unclaimed register access on pipes driving HDMI where
selective fetch was never enabled.
The stale selective fetch enable bit that commit addressed is handled
in the next patch.
Fixes: 7f1172a2ac0d ("drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16876
Cc: stable@vger.kernel.org
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-2-nemesa.garg@intel.com
|
|
The atomic disable in drm/sysfb currently clears the buffer using
memset_io(). Since the mapping is provided in a |struct iosys_map|,
it is better to use the related API instead of extracting the vaddr.
This is mentioned as a TODO item.
Switch to iosys_map_memset(), which takes the mapping as well as an
offset into the mapping.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260903084823.4156065-1-wenst@chromium.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
|
|
bcmgenet_hfb_init() runs INIT_LIST_HEAD() on priv->rxnfc_list, which drops
every rule off the list, and bcmgenet_open() calls it on each ifup. Every
rule the user configured is silently lost:
# ethtool -N eth0 flow-type ether dst $MAC action 0
Added rule with ID 0
# ethtool -n eth0 | grep -c Filter:
1
# ip link set eth0 down && ip link set eth0 up
# ethtool -n eth0 | grep -c Filter:
0
Initialise the lists once at probe and restore the rules on open, as
bcmgenet_resume() already does.
Fixes: 3e370952287c ("net: bcmgenet: add support for ethtool rxnfc flows")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260913190052.939955-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
commit f695390ea639 ("octeontx2-af: Fix limiting SRIOV VF count logic")
added a local PCI_DEVID_OCTEONTX2_RVU_AFVF define in rvu.c, although
the same value was already defined twice elsewhere: as RVU_LBK_VF_DEVID
in af/rvu.h and as PCI_DEVID_OCTEONTX2_RVU_AFVF in nic/otx2_common.h.
Move the definition into the "PCI device IDs" block in af/rvu.h, rename
RVU_LBK_VF_DEVID to match the PCI_DEVID_* naming convention of its
peers, and drop the redundant copies in rvu.c and nic/otx2_common.h,
the latter already including <rvu.h> through the af include path.
No functional change.
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Acked-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260910104102.590989-1-yijiangshan@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
mxl862xx_setup() arms the stats poll before mxl862xx_setup_mdio(), and
nothing stops it until dsa_register_switch() has returned an error to
mxl862xx_probe(). DSA frees the dsa_port list before it returns, so a
poll that fires once .setup or a later step of dsa_tree_setup() has
failed walks freed ports. On shutdown the user ports stay registered,
and the WORK_STOPPED flag test in mxl862xx_get_stats64() is not atomic
with the cancel in mxl862xx_shutdown(), so a re-arm that read the flag
before it was set queues the poll after cancel_delayed_work_sync() has
returned.
Arm the poll once .setup has succeeded and stop it from a .teardown op,
which DSA calls on unregister and after a failed registration, in both
cases before it frees the ports. Use disable_delayed_work_sync() there
and in shutdown(): it drains a running poll as the cancel did and turns
every later attempt to queue the work into a no-op, so the re-arm
cannot bring the poll back. remove() and the probe error path only set
WORK_STOPPED, which crc_err_work tests before it walks the ports.
Fixes: a21d33a5265f ("net: dsa: mxl862xx: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/1eb6f7fc1789b67e4b11e3f4d5ff080d0b6f7cbb.1789045590.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
mtk_phy_led_hw_ctrl_get() reports TRIGGER_NETDEV_LINK whenever any of the
speed bits in on_set is on, and in addition reports every individual
TRIGGER_NETDEV_LINK_* bit that is set. The netdev trigger refuses that
combination: netdev_led_attr_store() rejects TRIGGER_NETDEV_LINK together
with any per-speed rule, and it validates the whole resulting mode rather
than just the bit being written. Once the hardware has any link bit
programmed, every write to the trigger attributes of that LED therefore
fails with -EINVAL and the LED can no longer be configured.
The rules are also fed back into the hardware: the trigger stores what is
read back, and a later write of device_name programs it again, expanding
TRIGGER_NETDEV_LINK to every speed in on_set. An LED configured for a
single speed is thereby silently widened to "on at any link speed".
Both are easy to see on the EcoNet EN7528, whose four PHYs share one LED
block. The first LED programs the block correctly, the second reads those
rules back and rewrites them widened, and the remaining two then read the
widened value, so an LED configured for "link_10 link_100" ends up lit on a
1000 Mbps link.
on_set holds every speed the LED can indicate and is exactly what
mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so report the
speed independent rule only when all of them are on, and the individual
speeds otherwise. The mapping is then the inverse of the one used when
programming the LED and round trips without changing the register.
Fixes: c66937b0f8db ("net: phy: mediatek-ge-soc: support PHY LEDs")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260912134306.3544329-1-naseefkm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
otx2_get_link_ksettings() already reports speed, duplex, autoneg, link
modes and FEC from CGX firmware shared data, but never fills
cmd->base.port. As a result, ethtool does not show the physical
connector type even though firmware provides it in fwdata.port.
Read the connector type from shared firmware data and expose it via
ethtool. Extract only the low 8 bits of the firmware field and
validate the value against the standard ethtool PORT_* definitions
before publishing it to userspace.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260909040621.397255-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The AC200 and AC300 contain compatible Fast Ethernet link PHYs, but the
link endpoint is inaccessible until package-specific control registers
have powered and configured it.
Add one PHY driver which binds the link child and joins its parent
Ethernet PHY package. Fixed package compatibles select the corresponding
backend. The generic ACx00 compatible reads one packed configuration field
and selects the backend before touching backend-specific resources. The
AC300 path therefore does not resolve or access the candidate AC200 I2C
device.
Require two returned NVMEM bytes for AC300 and selectable ACx00
packages before selecting the backend. Keep the existing little-endian
decoding and one-byte calibration support for fixed AC200 packages.
AC200 locates the I2C device referenced by the package and establishes a
managed device link. It verifies that the provider is fully bound under
the supplier device lock before retrieving the regmap attached to the I2C
device. The companion MFD provider enables and exclusively pins the input
clock rate while it is bound. The link keeps the supplier bound until the
PHY consumer has unbound. Firmware must make the selected AC200 provider
path available before the PHY probes.
AC300 uses the PHY package helpers to access the control range at base
address plus 16. Keeping both backends in the same module lets the common
link implementation own the complete PHY without registering artificial
control devices.
Obtain and manage the selected package supply and calibration, manage the
AC300 input clock, validate or program the link address, and apply the
required reset, clock, I/O and shutdown sequences. Start in the
hardware-default MII mode so the forced PHY device can probe before a MAC
attaches, then apply the MAC-provided MII or RMII mode before the normal
PHY soft reset. AC200 specifies no additional delay between its EPHY
controls; the provider's input-clock startup delay is already complete
before its regmap becomes available.
Apply the common vendor analog initialization, optional AC300
low-calibration tuning and board-selected receive-clock inversion. Keep
MDI/MDI-X in automatic mode. Preserve standard MAC-managed EEE support
while disabling the vendor PHY-autonomous Intelligent EEE mode. Restart
autonegotiation when restoring the standard EEE advertisement changes it.
Serialize package state and the multi-register power sequences across the
different phylib callback lock contexts. Power down the package control
block and its supply during PHY suspend, then restore them and the vendor
configuration during resume. If shutdown fails after resetting the PHY,
restore the vendor settings and standard advertisement or forced
speed/duplex under the phylib lock before returning the original error.
A failed suspend is not followed by a normal resume to restore these
settings. Power down again if recovery fails, and unwind package power if
reset, resume or configuration fails after power-on.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260909-submit-acx00-of-dynamic-v1-v11-2-eb45e89ef918@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Introduce LRO offload support to the airoha_eth driver, leveraging
the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues mapped to RX
queues 24-31. LRO offloading does not support Scatter-Gather (SG) so
it is required to increase the page_pool allocation order to 2 for RX
queues 24-31 (LRO queues).
Since LRO is configured per-QDMA and shared across all devices using
it, LRO is mutually exclusive with multiple devices bound to the
same QDMA block. NETIF_F_LRO availability is re-evaluated whenever the
QDMA user count changes (device registration and runtime QDMA
migration): airoha_update_netdev_features() drops the feature when the
QDMA has more than one user, while airoha_dev_set_qdma() re-enables LRO
on the destination QDMA after a migration so that a running device
keeps it active on the new QDMA block.
Set the GSO metadata (gso_type/gso_size/gso_segs) on aggregated packets,
together with CHECKSUM_PARTIAL and the pseudo-header checksum, so that
L3-forwarded traffic is correctly re-segmented by the GSO/TSO path on
the egress device.
The HW does not report the per-segment MSS (msg3[31:16] only reports
the max aggregated size), so the gso_size of an aggregated packet is
approximated as DIV_ROUND_UP(data_len, agg_count), i.e. the mean
segment size. Since this can never exceed the largest merged segment,
re-segmentation only produces smaller packets, which is safe.
Aggregated skbs are marked SKB_GSO_DODGY so that the stack recomputes
gso_segs from gso_size and does not merge the aggregate into the GRO
engine.
Performance comparison between sw GRO and LRO has been carried out using
a 10Gbps NIC:
GRO: ~2.7 Gbps
LRO: ~8.2 Gbps
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260909-airoha-eth-lro-v7-1-e6317be79067@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
ice: expose TSPLL state on E825 through dpll subsystem
Grzegorz Nitka says:
On E825 devices that own the source timer, the TSPLL can lose lock when
the TCXO or TIME_REF signal is disrupted. This series adds monitoring
and recovery for that condition, then surfaces the lock status and clock
source selection through the dpll subsystem. It also fixes the clock_id
generation for E825 generic DPLL devices so userspace can unambiguously
map each DPLL device to its owning interface.
Patch 1 adds TSPLL lock monitoring to ice_ptp_periodic_work(). Placing it
there ensures recovery runs regardless of whether DPLL init succeeded or
CONFIG_DPLL is enabled. Lock state is cached in pf->ptp.tspll_locked via
WRITE_ONCE()/READ_ONCE() for consumption by the DPLL worker.
Patch 2 registers the TSPLL as a DPLL_TYPE_GENERIC device for E825 owner
PFs, with a fwnode-backed "time_ref" input pin. The pin state_on_dpll_set
callback switches the clock source between TIME_REF and TCXO. Lock status
is read from pf->ptp.tspll_locked; UNLOCKED is reported unconditionally
when the clock source is TCXO to reflect the free-running oscillator state.
Patch 3 changes the clock_id generation for E825 TX-CLK and TSPLL DPLLs.
Previously they used the board-level PCIe DSN, which is identical for
all interfaces sharing the same NAC/quad, so userspace could not tell
them apart. The new scheme derives the clock_id from the permanent port
MAC (with a dedicated tag bit distinguishing TSPLL from TX-CLK), while
other DPLL objects (EEC/PPS and non-E825 paths) keep the board-level
DSN-derived clock_id.
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
ice: use per-interface clock_id for E825 generic DPLLs
ice: add TSPLL DPLL device and TIME_REF pin for E825
ice: monitor TSPLL lock from PTP periodic worker
====================
Link: https://patch.msgid.link/20260908222428.872254-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
* ras/edac-drivers:
EDAC/dummy: Add a dummy EDAC driver
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
|
|
A dummy EDAC driver is useful for testing purposes in a VM when one
doesn't have all the hardware needed to test aspects of the EDAC
subsystem code.
Fix edac/Makefile alignment while at it.
Assisted-by: LLM
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260707215307.396571-1-bp@kernel.org
|
|
ie31200_init_one() enables the PCI device before calling ie31200_probe1().
If probing fails, it returns without balancing the successful enable,
leaving the PCI enable count elevated.
Call pci_disable_device() on that failure path. This also covers the
direct ie31200_init_one() call from the module initialization fallback,
while preserving the existing return values and successful probe path.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260913212500.60272-1-mhun512@gmail.com
|
|
If skb->tstamp is in the future, program this future delivery txtime
in the transmit descriptor.
TCP pacing offload is only offloaded if SK_PACING_FQ is negotiated and
the FQ offload_horizon is configured. But device support for pacing
offload must be more robust: it can also be reached through SO_TXTIME.
Bounds check txtime. Only packets with timestamp between now and the
horizon (max_pacing_offload_horizon) are offloaded when pacing offload
is enabled on the device via pacing_offload.
Negotiate the feature with the device using virtchnl. Support is
conditional on
- splitq mode, where tx and tx completion queues are separate, so
completions can be returned out of order.
- flow scheduling mode, where completions can arrive out of order.
- PTP to ensure the NIC clock is synced to CLOCK_TAI.
These features are negotiated per adapter, but expect all vports to
uniformly request splitq (req_[rt]x_splitq) and flow scheduling
(flow_sch_en) when available.
Packets beyond the horizon are sent immediately with the overflow bit
set.
On device reset, EDT capabilities are re-negotiated with firmware.
If re-negotiation succeeds, dev->max_pacing_offload_horizon is refreshed.
If pacing offload is no longer supported, dev->max_pacing_offload_horizon is set to 0.
Must not be called from netpoll due to ktime_get. But netpoll does not
generate packets with EDT, so no explicit test is needed.
Do not fail device initialization on EDT init error. Log an error, but
continue without EDT, similar to PTP.
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Joshua A Hay <joshua.a.hay@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260910171131.2532487-5-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The LED configuration lives in LEDCR1 (the per-LED function nibble) and
LEDCR2 (per-LED driver enable/value and polarity). The driver programs it
through the LED class callbacks -- dp83867_led_brightness_set(),
dp83867_led_hw_control_set() and dp83867_led_polarity_set() -- either once
from device tree at probe, or at runtime from sysfs and the netdev trigger.
dp83867_phy_reset(), the .soft_reset callback, issues a global software
reset (CTRL SW_RESET), which the datasheet defines as resetting all
registers, including the extended registers, to their defaults.
phy_init_hw() runs .soft_reset before .config_init on every attach and
resume -- phy_attach_direct(), mdio_bus_phy_resume() and MAC drivers -- so
the LED configuration is wiped from the first attach onward and never
restored. A device-tree polarity is lost, a manually driven LED goes dark,
and an LED offloaded to the netdev trigger whose link stays down after a
resume keeps the reset-default function until the next link event.
Shadow what the LED callbacks program, as a value and a written-bits mask
per register, and replay it from config_init(), which runs right after the
soft reset. Only bits the driver actually set are restored.
The callbacks run under phydev->lock, but config_init() must not take it:
the cable-test abort path in phy_state_machine() already holds phydev->lock
when it reaches phy_init_hw(), so config_init() taking it would deadlock.
Serialize the shadow and its replay with a dedicated lock instead.
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Link: https://patch.msgid.link/20260908235740.120112-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The K3 CPU PLL rate tables currently describe only one rate per PLL,
although the hardware supports a wider range.
PLL3 and PLL4 support rates from 1.05 to 2.4 GHz, while PLL5 and PLL8
support rates from 1.05 to 2 GHz. Populate the tables with every
supported rate in 50 MHz steps.
Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
Cc: stable@vger.kernel.org # 7.0+
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260907-k3-pll5-pll8-1800mhz-v5-1-5cc96d716b0a@linux.spacemit.com
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
msm_hdmi_phy_probe() enables runtime PM before enabling the PHY
resources and initializing the PLL, but failures from either operation
return without calling the matching pm_runtime_disable().
The remove path disables runtime PM, but it is not called when probe
fails. As a result, runtime PM remains enabled after an unsuccessful
probe.
Route failures after pm_runtime_enable() through a common error path
and disable runtime PM before returning.
This issue was found by manual code inspection.
Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753043/
Link: https://lore.kernel.org/r/20260913085814.1509352-1-lgs201920130244@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
DSI 6G v2.9 hosts (SM8650, SM8750, Kaanapali, etc.) reparent the byte and
pixel RCGs to the DSI PHY PLL at runtime from
dsi_link_clk_set_rate_6g_v2_9(), after the PHY has been enabled. However
dsi_calc_clk_rate_6g() runs earlier, in order to compute the bit clock
request for the PHY. At that point the byte RCG still has its reset
parent (XO), so clk_round_rate() returns a bogus rate, which then ends up
in the PHY bit clock request and the PLL gets programmed to a wrong
frequency, breaking the panel.
Move the rounding to dsi_link_clk_set_rate_6g(), which is called after
the RCGs have been reparented to the PLL. Storing the rounded rate at
this point still makes later link_clk_set_rate() calls no-ops in the
CCF. Derive the byte interface clock rate from the rounded byte clock
rate, otherwise it would keep requesting the idealized rate and
retrigger the PLL on every transfer.
Reported-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Fixes: 6cd33b6f4155 ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value")
Assisted-by: LLM
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SM6115P J606F
Tested-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/750496/
Link: https://lore.kernel.org/r/20260903-fix-eliza-dsi-v1-1-3474a6c9f2e0@oss.qualcomm.com
|
|
For an asynchronous transaction to one of the two CSR address ranges on
the local node, the current implementation generates the packet data for
the response subaction internally while handling the request subaction.
Unlike transactions to other addresses, there is no need to submit the new
packet for the response subaction.
The current implementation handles both subactions in a single helper
function with conditional statements. This makes it difficult to see why
the two subactions should be handled differently.
Split the helper function into two helper functions, one for the request
subaction and the other for the response subaction.
Link: https://lore.kernel.org/r/20260913101356.156420-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
For an asynchronous transaction to one of the two CSR address ranges on
the local node, the current implementation generates the packet data for
the response subaction internally while handling the request subaction.
The handling code is duplicated between the two ranges.
Reduce the duplication by moving response handling to the callers.
Link: https://lore.kernel.org/r/20260913101356.156420-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The handle_local_rom() function calls fw_fill_response() in each
conditional branch. Using local variables for the function parameters
allows the function to be called from a single place.
Link: https://lore.kernel.org/r/20260913101356.156420-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The current implementation handles asynchronous packets sent to the local
node specially. To decide whether a packet is destined for the local node,
the local node ID and bus generation need to be checked while holding the
spinlock, since both can change.
Add a helper function annotated to require the spinlock to be held.
Link: https://lore.kernel.org/r/20260913101356.156420-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The current implementation handles asynchronous packets sent to the two
CSR address ranges on the local node specially. To decide whether a packet
is destined for either range, the destination offset needs to be checked
according to the IEEE 1394 and 1394 OHCI specifications.
The current implementation uses both conditional and switch statements to
check the offset, which makes the range checks difficult to reuse.
Add two helper functions for the range checks using the in_range() macro.
Link: https://lore.kernel.org/r/20260913101356.156420-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
According to the existing quirk the Pericom E5 errata for ACS P2P applies
to PI7C9X2G404, PI7C9X2G304 and PI7C9X2G303 models.
The Arduino Ventuno Q board has a PI7C9X2G304 switch (verified from chip
markings) with a product-id of 0xb304. Add 12d8:b304 to the existing list
of quirks for this erratum.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260820082041.13470-1-johannes.goede@oss.qualcomm.com
|
|
Some Qualcomm PCIe devices (WCN6855/WCN7850 WLAN cards, SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.
The problem manifests in VFIO passthrough scenarios:
- WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WLAN devices: Normal VM
operation works fine, including clean shutdown/reboot. However, when
the VM terminates uncleanly (crash, force-off), VFIO attempts to reset
the device before it can be assigned to another VM. Without a working
reset method, the device remains in an undefined state, preventing
reuse.
- SDX62/SDX65 (17cb:0308) 5G modems: Never successfully initialize even
on first VM assignment without proper reset capability.
Add device-specific reset methods using BAR-space hardware reset registers
that exist in these devices:
- WCN6855/WCN7850 WLAN devices use SoC global reset via BAR0 (sequence
from ath11k/ath12k driver: ath11k_pci_soc_global_reset(),
ath11k_pci_sw_reset(), ath11k_mhi_set_mhictrl_reset()):
- Write/clear reset bit at offset 0x3008
- Wait for PCIe link recovery (up to 5 seconds)
- Clear MHI controller SYSERR status at offset 0x38
- SDX62/SDX65 modem devices use MHI SoC reset via BAR0 (sequence from MHI
driver: mhi_soc_reset(), mhi_pci_reset_prepare()):
- Write reset request to offset 0xb0
- Wait 2 seconds for reset completion
These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.
Testing was performed on desktop platforms with M.2 WLAN and modem cards
using M.2-to-PCIe adapters, including extensive force-reset cycling to
verify stability.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260721081301.205374-1-jtornosm@redhat.com
|
|
ASPM states
It is not recommended to enable/disable the ASPM states on the back of the
PCI core directly using the LNKCTL register. It will break the PCI core's
knowledge about the device ASPM states. So use the APIs exposed by the PCI
core to enable/disable ASPM states.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-8-6bd72451746e@kernel.org
|
|
ASPM states
It is not recommended to enable/disable the ASPM states on the back of the
PCI core directly using the LNKCTL register. It will break the PCI core's
knowledge about the device ASPM states. So use the APIs exposed by the PCI
core to enable/disable ASPM states.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-7-6bd72451746e@kernel.org
|
|
ASPM states
It is not recommended to enable/disable the ASPM states on the back of the
PCI core directly using the LNKCTL register. It will break the PCI core's
knowledge about the device ASPM states. So use the APIs exposed by the PCI
core to enable/disable ASPM states.
Tested-on: WCN7850 hw2.0 PCI
WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Reported-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-6-6bd72451746e@kernel.org
|
|
pcie_aspm_enabled() returns 'pcie_link_state::aspm_enabled' parameter which
contains the enabled states. But the API currently returns the 'bool' type
which is used by the callers to decide if ASPM is enabled or not.
To allow the future callers to also make use of the enabled ASPM states,
return the actual type of 'pcie_link_state::aspm_enabled' parameter, 'u32'.
Existing callers can still treat the return value as a 'bool' as the C11
standard guarantees the behavior (this API relied on the same behavior
before as well).
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-5-6bd72451746e@kernel.org
|
|
Add kernel-doc for pci_disable_link_state_locked() API and fix the
kernel-doc for pci_disable_link_state() API.
Also convert the kernel-doc of pci_enable_link_state() and
pci_enable_link_state_locked() APIs to the standard format and mention that
pci_force_enable_link_state() should be used to re-enable the states
disabled by pci_disable_link_state().
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-4-6bd72451746e@kernel.org
|
|
states
Per PCIe spec r6.0, sec 5.5.4:
If setting either or both of the enable bits for PCI-PM L1 PM Substates,
both ports must be configured as described in this section while in D0.
Currently, the callers of pci_enable_link_state_locked() (vmd, pcie-qcom)
transition the device to D0 themselves before enabling the link state. But
this is easy to get wrong and has to be duplicated by every caller.
Move the D0 transition into the shared __pci_enable_link_state() helper so
that all three APIs pci_enable_link_state(), pci_enable_link_state_locked()
and pci_force_enable_link_state() perform it, and only when the PCI-PM L1
PM Substates are getting enabled.
Now that the helper handles the transition, drop the redundant D0
transition from the vmd and pcie-qcom callers.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-3-6bd72451746e@kernel.org
|
|
pci_enable_link_state() and pci_enable_link_state_locked() APIs only enable
the ASPM states that were not previously disabled via
pci_disable_link_state*() API or blacklisted during init (e.g. the pre-1.1
device blacklist, which is only meant to be overridden with
'pcie_aspm=force'). This is an intentional behavior as these APIs must not
silently re-enable states that were deliberately disabled, since doing so
could enable ASPM on a link where it is known to be unsafe.
However, some drivers (e.g. the atheros WLAN drivers) save the currently
enabled ASPM states, disable all ASPM states before firmware download, and
then try to restore exactly the states that were enabled before. Restoring
those states requires re-enabling states that were just disabled via
pci_disable_link_state() API. But, this cannot be achieved using the
existing APIs.
Hence, add pci_force_enable_link_state() API for such callers. Unlike
pci_enable_link_state(), it re-enables the requested states even if they
were previously disabled via pci_disable_link_state() or disabled during
init. The caller is therefore responsible for only enabling states the
device actually supports, typically the ones previously reported by
pcie_aspm_enabled().
This API is implemented by adding a 'force' parameter to the shared
__pci_enable_link_state() helper. When 'force' is true, the requested
states are cleared from 'link->aspm_disable' before enabling.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-2-6bd72451746e@kernel.org
|
|
PCI core/ASPM service driver allows controlling ASPM state through
pci_disable_link_state() API. It was decided earlier (see the Link below),
to not allow ASPM changes when OS does not have control over it but only
log a warning about the problem 'commit 2add0ec14c25 ("PCI/ASPM: Warn when
driver asks to disable ASPM, but we can't do it")'.
A number of drivers have added workarounds to force ASPM off with own
writes into the Link Control Register (some even with comments explaining
why PCI core does not disable it under some circumstances). According to
the comments, some drivers require ASPM to be off for reliable operation.
Having custom ASPM handling in drivers is problematic because the state
kept in the ASPM service driver is not updated by the changes made outside
the link state management API.
As the first step to address this issue, make pci_disable_link_state() to
unconditionally disable ASPM so the motivation for drivers to come up with
custom ASPM handling code is eliminated.
To fully take advantage of the ASPM handling core provides, the drivers
that need to quirk ASPM have to be altered depend on PCIEASPM and the
custom ASPM code is removed. This is to be done separately. As PCIEASPM is
already behind EXPERT, it should be no problem to limit disabling it for
configurations that do not require touching ASPM.
Make pci_disable_link_state() function comment to comply kerneldoc
formatting while changing the description.
Link: https://lore.kernel.org/all/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ@mail.gmail.com/
Link: https://lore.kernel.org/all/20230511131441.45704-1-ilpo.jarvinen@linux.intel.com/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[mani: commit message fixup]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-1-6bd72451746e@kernel.org
|
|
If kasprintf() fails while setting up mailbox channels, already
requested channels from earlier iterations were never freed. Route
the failure through the existing cleanup path.
Fixes: ffbf23d50353 ("firmware: imx: Add DSP IPC protocol interface")
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
When mac80211 removes a sta, it calls .sta_state() which in turn calls
ath11k_mac_station_remove(). In that function we clean up both peers &
arsta related resources.
But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which
assumes that all driver related resources are cleaned up beforehand. This
cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not
in fact free arsta->rx_stats / tx_stats.
Extract the arsta cleanup from ath11k_mac_station_remove() into a
new ath11k_mac_station_cleanup() and call it from both there and
ath11k_mac_peer_cleanup_all().
This should handle kmemleaks reports like:
unreferenced object 0xffffff801ae66400 (size 1024):
comm "hostapd", pid 1306, jiffies 4295011565
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc d61c08ec):
kmemleak_alloc+0x3c/0x50
__kmalloc_cache_noprof+0x2b0/0x3e0
ath11k_mac_op_sta_state+0x1dc/0xb10
drv_sta_state+0xac/0x6f8
sta_info_insert_rcu+0x314/0x5e0
sta_info_insert+0x14/0x38
ieee80211_add_station+0x10c/0x1a0
nl80211_new_station+0x3e8/0x680
genl_family_rcv_msg_doit+0xc0/0x120
genl_rcv_msg+0x1b4/0x258
netlink_rcv_skb+0x4c/0x108
genl_rcv+0x38/0x60
netlink_unicast+0x190/0x278
netlink_sendmsg+0x15c/0x370
____sys_sendmsg+0x120/0x290
___sys_sendmsg+0x70/0xa0
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260731145830.769811-1-nico.escande@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(),
which only dequeues the timer and does not wait for a callback that is
already executing; the preceding free_irq() calls synchronize the
interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can
therefore be running past the teardown and use the wcn freed along
with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock,
reads wcn->tx_ack_skb and passes wcn->hw to
ieee80211_tx_status_irqsafe().
Fix this by using timer_shutdown_sync(), which waits for a running
callback and also prevents the timer from being rearmed again. The
timer is set up again by wcn36xx_dxe_init() on the next start, so the
start/stop cycle is unaffected.
This issue was found by an in-house static analysis tool.
Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Co-developed-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260910020907.3353-1-fanwu01@zju.edu.cn
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
Commit 96f46607bbce ("wifi: ath12k: add AHB platform descriptor
support") added undocumented OF ABI, by relying on a very specific node
name. This is not allowed and was never acked by Devicetree
maintainers.
Additionally that part of code is not even used, because all devices
have exactly the same user pd, so this was added "for future". Adding
dead code just "for future" is heavily discouraged in kernel coding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825081313.71351-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
* pm-cpufreq:
cpufreq/amd-pstate: Remove obsolete amd_dynamic_epp documentation
cpufreq/amd-pstate: Show a warning if missing EPP tunings
cpufreq/amd-pstate: Add EPP tunings for Zen6 client platforms
cpufreq/amd-pstate: Add per SoC and per core type EPP tuning values
cpufreq/amd-pstate-ut: Fix amd_pstate_ut_check_freq failure with 'Requested CPU Min frequency' BIOS option
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux
Pull amd-pstate 7.4 content (2026-09-14) from Mario Limonciello:
"* Fix for amd-pstate-ut with 'Requested CPU Min frequency' BIOS option
* New Zen6 tuning values for EPP
* Documentation fix"
* tag 'amd-pstate-v7.4-2026-09-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
cpufreq/amd-pstate: Remove obsolete amd_dynamic_epp documentation
cpufreq/amd-pstate: Show a warning if missing EPP tunings
cpufreq/amd-pstate: Add EPP tunings for Zen6 client platforms
cpufreq/amd-pstate: Add per SoC and per core type EPP tuning values
cpufreq/amd-pstate-ut: Fix amd_pstate_ut_check_freq failure with 'Requested CPU Min frequency' BIOS option
|
|
The Acer Nitro AN515-58 requires the same quirk entry as AN515-46, since
its firmware also advertises the NVIDIA WMI EC backlight GUID. However,
on this hybrid graphics setup, the internal display is wired to the
Integrated GPU (Intel Iris Xe Graphics).
As a result, the nvidia_wmi_ec_backlight driver fails to probe, leaving
no backlight device registered and rendering the brightness keys and
desktop brightness slider non-functional.
Setting acpi_backlight=native allows intel_backlight to register its
backlight interface and restoring brightness control. Add a DMI
quirk entry so this model uses the native backlight by default.
Signed-off-by: Dirga Yuza <dirgayuza123@gmail.com>
Link: https://patch.msgid.link/20260911143306.49015-1-dirgayuza123@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_sbs_probe() jumps to the common error path when kzalloc_obj()
fails, but platform_set_drvdata() is only called after the allocation
succeeds.
The error path calls acpi_sbs_remove(), which retrieves the unset
driver data and dereferences the resulting NULL pointer when locking
sbs->lock, causing a NULL pointer dereference.
Return -ENOMEM directly when the allocation fails, since no resources
have been initialized at that point and there is nothing to clean up.
This issue was found by manual code inspection.
Fixes: 9460eaae2ee42 ("ACPI: SBS: Convert the driver to a platform one")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260912113355.644238-1-lgs201920130244@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
pnp_device_probe() attaches the PNP device before it activates or
disables its resources. The attach changes the status from PNP_READY
to PNP_ATTACHED, but errors from either resource transition return
directly and leave that status behind. A later bind or manual PNP
configuration attempt then sees a device that is still marked in use.
Route both errors through the existing failure path so it restores the
status to PNP_READY. Do not disable the device or clean its resources:
pnp_activate_dev() only marks it active after a successful start, while
pnp_disable_dev() preserves the active state and resource table when
stopping fails.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/20260910203727.63489-1-mhun512@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Pull rdma fixes from Jason Gunthorpe:
"Lots of bug fixes from the last weeks:
- Various error unwind bugs
- Several more races and bugs in siw and rxe, including remote
triggerable
- HFI1 corruption with its credit scheme
- Remove a bogus user triggerable dev_warn
- Lock __ethtool_get_link_ksettings() properly
- Fix a lockdep loop with diassociation
- Several storage related bugs, some triggerable remotely
- Do no leak physical addresses to userspace in bnxt_re
- Fix wrong irq context for the xarrays in erdma
- User triggerable race in ucma with multicast
- Race in ipoib with multicast flushing and destruction"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (28 commits)
RDMA/siw: Bound fragmented header copies by the remaining length
RDMA/efa: Keep EQ resources alive while IRQ is registered
RDMA/efa: Keep admin queues alive while IRQ is registered
RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()
IB/IPoIB: Avoid restoring OPER_UP after multicast flush
RDMA/ucma: Serialize join and leave on copy_to_user failure
RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted
RDMA/irdma: Enforce local fence for IB_WR_REG_MR
RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables
RDMA/mad: Fix receive buffer leak when PKey enforcement fails
RDMA/uverbs: Fix potential leak of resources->collection in flow_resources_alloc()
RDMA/bnxt_re: Avoid exposing umdbr to userspace
RDMA/rtrs: guard against null kobj name
RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup
IB/isert: wait for deferred control PDU completions before releasing the connection
IB/iser: reject a remote invalidation of an unregistered direction
RDMA/srp: Fix srp_remove_target()
IB/mlx4: Fix use-after-free on pkey sysfs registration failure
RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency
RDMA/core: Reject unregistering netdevs in ib_get_eth_speed
...
|
|
We will soon want to auto provision all VFs in a single step, while
already holding the master mutex. Split existing function into two.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260911183257.14999-4-michal.wajdeczko@intel.com
|
|
We will soon want to unprovision all VFs in a single step, while
already holding the master mutex. Split existing function into two.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260911183257.14999-3-michal.wajdeczko@intel.com
|
|
We will soon want to provision VFs in a single step, while already
holding the master mutex. Split existing function into two.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260911183257.14999-2-michal.wajdeczko@intel.com
|
|
* edac-drivers
EDAC/ie31200: Disable PCI device when probing fails
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
