| Age | Commit message (Collapse) | Author |
|---|
|
Replace the hand-rolled devm_hdmirx_of_reserved_mem_device_release()
devres action with devm_of_reserved_mem_device_init(), which handles the
cleanup automatically. This removes both the wrapper function and the
devm_add_action_or_reset() call.
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
mmc_of_find_child_device() returns a device node with its reference count
incremented. mmc_add_card() stores the reference before calling
device_add(), while the card is marked present only after device_add()
succeeds.
If device_add() fails, the callers release the card through
mmc_remove_card(). However, mmc_remove_card() only drops the OF node
reference for a present card, leaking the reference on this error path.
Move of_node_put() outside the present-card conditional so the reference
is released for both registered cards and card-add failures.
Fixes: 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing")
Cc: stable@vger.kernel.org
Signed-off-by: Zhu Ling <zhuling0805@qq.com>
Reviewed-by: Shawn Lin <shawn.lin@linux.dev>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The combined struct-definition-with-initializer pattern confuses the
kernel-doc parser. Split into separate struct definition and array
declaration.
Also now that it's fixed, it warns on missing members. Add those as
well.
Since this is just a lookup table and not modified, make it const so
that it can be moved to read only memory.
Assisted-by: Opencode:Big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260817015903.137062-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
rzg3s_pcie_init_irqdomain() installs chained handlers for the INTx
parent interrupts before creating the INTx irqdomain and initializing
MSI support.
If any subsequent step fails, such as obtaining an INTx IRQ,
creating the irqdomain, or initializing MSI, the error path returns
without removing any chained handlers that were already installed.
This leaves stale handler and data pointers attached to the parent
interrupts.
Add a helper to tear down the INTx IRQ setup, including removing the IRQ
domain and clearing the chained handlers. Use it to unwind partially
completed initialization and from the normal IRQ domain teardown path.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-4-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
platform_get_irq_byname() may return specific error codes such as
-EPROBE_DEFER, but rzg3s_pcie_init_irqdomain() replaces all failures
with -EINVAL.
This breaks probe deferral by preventing the driver core from retrying
probe once the interrupt provider becomes available.
Propagate the original error code instead.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-3-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
rzg3s_pcie_host_init_port() enables the PCIe reference clock using
clk_prepare_enable(), but if rzg3s_pcie_probe() subsequently fails, for
example because pci_host_probe() returns an error, the probe error path
only releases the clock handle with clk_put().
Balance clk_prepare_enable() by calling clk_disable_unprepare() in the
probe cleanup path before releasing the clock, ensuring the reference
clock is properly disabled on probe failure.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-2-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
Functions like bcom_task_alloc() use if (!bcom_eng) as a safety readiness
check. If the probe fails and hits this error path, subsequent or concurrent
API calls will bypass the check and dereference the freed memory.
Fixes: 9560aea4e9d1 ("[POWERPC] mpc5200: Fix null dereference if bestcomm fails to initialize")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260817015442.136038-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Debugging hangs on the request legs now means asking 'what was the
watchdog guarding and until when?' Expose the awaited events, the
valid states, and the absolute deadline of the current watch next to
the existing pending_events/completed_events nodes; all three zero out
once a leg is settled or the watch fired.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The voltage switch (CMD11) keeps its dedicated 500ms deadline, but it
is now just another arm of the central watchdog; cmd11_timer is
deleted. The synthesized payload is identical to what the command leg
watchdog produces (cmd_status = RTO plus EVENT_CMD_COMPLETE), so the
request state machine cannot tell the difference.
Behavior notes for review:
* The extra jiffy in the legacy '500ms + 1' arming was pure jiffies
rollover paranoia and disappears together with the jiffies math.
* Since patch 1 arms the regular command watch on every RESP_EXP
command -- including voltage switches -- the subsequent arm here
replaces it, as documented there. For a genuinely stuck CMD11 the
abort latency therefore becomes exactly 500ms instead of racing
min(cto_ms, 500ms) between two timers as before; the reported
error (-ETIMEDOUT either way) is unchanged.
* dw_mci_cmd_interrupt() already delivers the watched events under
irq_lock on any completion path, so the former out-of-lock
timer_delete() next to the VOLT_SWITCH branch simply goes away.
No functional change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The data timeout joins the command timeout on the central watchdog;
dto_timer is deleted.
dw_mci_set_drto() arms DW_MCI_WD_DATA_EVENTS with EVENT_DATA_COMPLETE
as its precheck mask: a DATA_ERROR that arrived while still waiting
for the paired completion must not prevent the watch -- the legacy
mod_timer() guard tested exactly that one bit, and the fault-injection
machinery relies on this by injecting DATA_ERROR early.
The EXTENDED_TMOUT quirk semantics fall out naturally now:
* On quirk hosts the data-error branch delivers the whole watched
set, stopping the watch since no further data events will come --
this mirrors the former conditional timer_delete() plus the manual
EVENT_DATA_COMPLETE side-post.
* Without the quirk nothing is delivered there and the outstanding
watch keeps guarding until a genuine DATA_OVER arrives, exactly
like leaving dto_timer running did.
The DATA_OVER branch delivers unconditionally, superseding its
unconditional timer_delete(). The stale-timer WARN_ON +
timer_delete_sync() dance in dw_mci_clear_pending_data_complete() goes
away for the same reason as on the command leg: a callback racing past
its checks is idempotent under irq_lock.
No functional change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The driver keeps three independent fallback timers (cmd11, cto, dto)
whose callbacks all re-implement the same race handling: peek MINTSTS
in case the interrupt is in flight, check whether the event was
delivered meanwhile, verify host->state matches the leg being guarded,
and finally synthesize the missed event. This series replaces them
with a single hrtimer watchdog.
This first step introduces the watchdog and moves the command timeout
onto it; cto_timer is deleted. Later steps convert the data timeout
and the voltage-switch timer onto the same watch.
The new protocol relies on two simple facts which hold for all current
event producers:
* every site posting EVENT_CMD_COMPLETE (dw_mci_cmd_interrupt() and
the command-error branch of dw_mci_interrupt()) runs under
irq_lock,
* every site arming a watch does so under irq_lock as well.
Consequently a watchdog callback holding irq_lock can neither miss nor
race an already-delivered event: the bookkeeping part of the former
're-read MINTSTS' paranoia is subsumed by checking the awaited mask
against pending_events under the same lock the producers use. The
hardware-latency part of that paranoia is kept verbatim, see below.
A callback that raced past every check nonetheless degrades to at most
one idempotent extra state machine run instead of completing a foreign
leg.
The callback classifies what expired by comparing the awaited set
against the named DW_MCI_WD_{CMD,DATA}_EVENTS masks so that subsequent
conversions only add call sites. dw_mci_wd_arm() takes a separate
'already delivered' precheck mask because guarding the data legs must
tolerate a DATA_ERROR that arrived while still waiting for the paired
completion -- exactly like mod_timer() paths did before.
Behavioral notes for review:
* dw_mci_wd_arm() replaces any previously armed watch. During a
voltage switch (CMD11) both cto_timer and cmd11_timer were armed
concurrently before, racing each other with duplicated warnings;
now only the last arm on that path survives.
* The stale-timer defensiveness of dw_mci_clear_pending_cmd_complete()
(WARN_ON + timer_delete_sync) is dropped because the callback is now
idempotent by construction; timer_delete_sync from the BH would also
be wrong-context sleeping on hrtimers.
* Before declaring a timeout the callback re-reads MINTSTS: when the
completion interrupt is already latched in hardware and only its
handler has not been scheduled yet, the firing grants further
DW_MCI_WD_INFLIGHT_GRACE_MS rounds instead of failing an about-to-
complete transfer. This replicates the interrupt-latency paranoia
of the retired cto_timer()/dto_timer() callbacks; unlike them it
keeps re-watching rather than going passive, so if that latched
interrupt is ultimately lost the request still unwedges with a
timeout error instead of hanging forever.
No functional change intended beyond the deduplication described above.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Drop words accidentally written twice, reported by checkpatch.pl as a
possible repeated word. Only touches comments, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260907065047.26773-3-hemanth.selam@gmail.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260907065047.26773-2-hemanth.selam@gmail.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Inline Crypto Engine (ICE) keys are lost after hibernation entry and this
needs to be restored when hibernation exits. ICE keys are re-programmed
during sdhci_msm_ice_init() but it may not cover cases where the
hibernation image is already restored.
Unwrap the pm ops and use directly in driver to add the call to restore
Inline Crypto Engine (ICE) keys. This ensures that ICE is brought into
same state as before hibernation. If hibernation image creation itself
fails then device boots through normal flow where there is no need to
reprogram the keys.
Also set MMC_CAP2_CRYPTO_NO_REPROG to indicate that re-programming of ICE
keys is not needed during MMC runtime suspend/resume or suspend-to-RAM
since the rail powering the ICE will not be turned off.
During CQE recovery, key would be lost only when BCR reset is performed
which do not happen right now and will be taken up once it is fixed as part
of recovery flow.
Signed-off-by: Ram Prakash Gupta <ram.gupta@oss.qualcomm.com>
Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com>
Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>
Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The register context for the crypto profile belongs to the sdhci/cqhci host
and not the mmc card, hence re-programming should be managed by the host
driver itself.
Add the flag MMC_CAP2_CRYPTO_NO_REPROG as part of host->caps2 to control
reprogramming keys to crypto engine for SoCs which do not require this
feature.
Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com>
Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Our HW always handles GMV BT pages with a fixed 4K size, but the driver
calculates the needed GMV BT pages number with PAGE_SIZE, which is 64K
in 64K system. Only the first 4K (GMV index 0-127) can be reached by HW,
causing GID capacity loss and memory waste.
Split a single 64K BT page into multiple 4K pages and register them to
HW per 4K block so that HW can correctly reach all GMV entries.
Fixes: 32053e584e4a ("RDMA/hns: Add support for filling GMV table")
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20260907084901.2420703-4-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
The GMV entry is a HW object corresponding to a GID. Since gid_table_len
is already limited to a maximum of 256, there is no need to allocate
memory for those extra GMV entries as they will never be touched.
Fixes: 7243396aaf12 ("RDMA/hns: Add a max length of gid table")
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20260907084901.2420703-3-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
The gid_table_len is always read from HW registers or derived from
u32 arithmetic, and it is never negative. Change its type from int
to u32 to avoid signed/unsigned mixed-type operations with other
u32 fields such as gmv_entry_num.
Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
Link: https://patch.msgid.link/20260907084901.2420703-2-huangjunxian6@hisilicon.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
We lost the proper display reset deadlock handling in
commit d59cf7bb73f3 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence").
Currently the only thing that eventually breaks the deadlock is the
10 second fence timeout, which is very slow.
I tried to essentially restore the previous mechanism via a custom
dma_fence in
https://lore.kernel.org/intel-gfx/20260408233458.22666-6-ville.syrjala@linux.intel.com/
but Christian didn't want it.
The ideal solution would be to allow the reset time modesets to proceed
ahead of any already queued atomic commits, but that is quite involved
since we need to be able to track the already committed (to the
hardware) atomic states in addition to the userspace queued atomic states.
Years ago I did implement something like that in
https://lore.kernel.org/intel-gfx/20170629134948.5614-1-ville.syrjala@linux.intel.com/
but Sima didn't want it.
In order to get rid of the dependency on the timeout, and make things
faster, let's just effectively revert the remainders of
commit 9db529aac938 ("drm/i915: More surgically unbreak the modeset vs reset deadlock").
The upside is that the reset is fast again, but the downside is that
we now do a full wedge on all display resets, which will also kill
innocent batches. But perhaps no one really cares since this is
currently only needed for old pre-g4x hardware. But if anyone has plans on
using eg. FLR as a backup GPU reset on new hardware then we probably need
to come up with something better...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260903130116.19089-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Document the compatible for SDHCI on Qualcomm Maili SoC.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
A UHS session can leave the SD pads and SD18 regulator configured for
1.8V. The power-off path disables card power and suspends the regulator,
but does not restore their voltage selection.
On the next power-up, this stale state remains until after the MMC core
requests its initial signal voltage. Restore the SD pads and SD18 regulator
to 3.3V before enabling card power, as the old rts5139 driver did.
Tested: StarLite ADL with an RTS5129 tray reader; repeated 1.8V UHS
sessions, power cycles, and tray removal/reinsertion.
Tested: StarFighter MTL with an RTS5129 trayless reader; repeated 1.8V
UHS sessions, power cycles, and card removal/reinsertion.
Tested: Both systems re-enumerated the card after every cycle.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The calc_allowed_config_filter() function passes the return value of
iter_pos_to_idx() directly to BIT(), but the helper can return -1 for
an invalid iterator.
The iterator already rejects negative indices before doing a
configuration, so this should not matter in normal flows. In any
case, for robustness, check the index explicitly and warn if it is
negative, avoiding an undefined shift.
Fixes: 39e30bdf2f92 ("drm/i915/dp_link_caps: Add link configuration iterator")
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260908100659.113555-1-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The Realtek RTS522A card reader in the Lenovo ThinkPad X260
(subsystem 17aa:504a) incorrectly reports inserted SD cards as
write-protected.
This causes the MMC core to expose the card as read-only:
mmcblk0: mmc0:aaaa SN256 238 GiB (ro)
and /sys/block/mmcblk0/ro reports 1.
Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again.
Limit the quirk to the affected Lenovo subsystem.
Assisted-by: ChatGPT:GPT-5.6 Sol
Signed-off-by: Florian Maillard <florian.maillard@mailoo.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Aleksei Sviridkin says:
====================
net: restore EEE on MediaTek switches and SoC MACs
Both drivers fill in phylink_config.lpi_capabilities and
lpi_timer_default but never lpi_interfaces. phylink treats a MAC as
supporting managed EEE only when the tx_lpi methods are implemented and
BOTH bitmaps are non-empty, which phylink_create() decides once and for
all, so EEE has been off on every mt753x port and on every mtk_eth_soc
MAC that uses mtk_phylink_ops since the two commits named in the
Fixes: tags. Because the tx_lpi methods ARE implemented, phylink takes
the other branch and calls phy_disable_eee(), which fills
eee_disabled_modes - so userspace cannot enable EEE either.
On an MT7981B board with an MT7531 switch, before these patches:
== lan1
Cannot get EEE settings: Not supported
== lan2
Cannot get EEE settings: Not supported
== lan3
Cannot get EEE settings: Not supported
== lan4
Cannot get EEE settings: Not supported
== wan
Cannot get EEE settings: Not supported
lan1-3 are the MT7531 internal PHYs, lan4 is an EN8811H on switch port
5 whose MAC side runs 2500BASE-X rate matched to a 1 Gbps media link,
and wan is the mtk_eth_soc MAC with its directly attached 1 Gbps PHY -
so both drivers are covered.
Each patch fills lpi_interfaces from supported_interfaces and leaves
2.5 Gbps out of both bitmaps for now. LPI above 1 Gbps is unvalidated
rather than unsupported: both MACs fold 2.5 Gbps onto their 1 Gbps
speed encoding, so the 1 Gbps EEE force bit is what would govern it.
MediaTek's SDK driver sets the force bits for 100 Mbps and 1 Gbps only,
EEE signalling on 2500BASE-X is outside 802.3, and the 1 us unit of the
wakeup timers is undocumented at 2.5 times the port clock.
The SoC MAC patch fills lpi_interfaces only on SoCs carrying a new
MTK_GMAC_EEE capability. mtk_mac_enable_tx_lpi() programs wake-up times
taken from MT7531's reset values, and the capability marks the SoCs
where those have been measured to work: MT7981 for now. The others keep
today's behaviour, EEE unreachable from userspace, until someone with
the hardware confirms them.
Neither driver sets eee_enabled_default, so LPI stays off until
userspace asks for it with ethtool --set-eee. The EEE advertisement is
a different matter: phylink stops force-clearing it, so a PHY that
advertises EEE out of reset advertises it again and the link may
negotiate EEE, without this MAC asserting LPI. MT7531's internal PHYs
and EN7528 are the exceptions, for the reasons in patch 1. Devicetree
eee-broken-* marks act at the PHY level and keep working, so a board
that already distrusts its PHYs stays protected: OpenWrt marks all
modes broken on MT7621's internal PHYs.
The two patches are independent and touch different subsystems; they
are sent together because they are the same bug.
Targeted at net as a regression fix with an active userspace lockout;
can be retargeted at net-next if maintainers prefer.
Based on net-next at 91ec20351349. All three files touched are byte
identical in net/main and the series applies there unchanged.
After the series, all five ports report:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: Not reported
No 2.5G mode is offered, which is the narrowed lpi_capabilities, and
nothing is advertised until userspace asks. On this board no PHY came
out of reset advertising EEE, so the case where the advertisement
returns once phylink stops clearing it is not exercised here.
Enabling it on lan1, whose partner advertises EEE at both speeds:
# ethtool --set-eee lan1 eee on
EEE status: enabled - active
Advertised EEE link modes: 100baseT/Full 1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full
# ethtool --set-eee lan1 eee on tx-lpi on
EEE status: enabled - active
Tx LPI: 30 (us)
With LPI armed, 30 parallel ICMPv6 streams of 1400-byte payload, 300
packets each one second apart - so every gap crosses the LPI threshold
and the link enters and leaves LPI thousands of times over 300 s - lost
nothing: 300/300 on every stream, tx and rx error counters unchanged,
carrier_changes unchanged, and no mac_enable_tx_lpi errors in dmesg.
On wan, cabled for this round to a partner that advertises EEE (a
BCM5720), the MT7981 GMAC's own LPI was exercised. With tx-lpi armed
the wan PHY's MMD 3.1 reads 0x0f44, Tx LPI indication set, so the MAC
is asserting LPI; it drops to 0x0044 with tx-lpi off and comes back
with it on. The same 30-stream test at 1 Gbps lost nothing over 9000
packets with the link cycling through LPI at every 1 s gap. At
100 Mbps the only losses were the first packet or two of some
streams, and those reproduce with EEE disabled on both ends:
neighbour discovery for 30 streams starting at once. The 17 and 36 that
mtk_mac_enable_tx_lpi() programs therefore hold on MT7981 against this
partner at both speeds. Its Tx LPI reads 1000 (us) against lan1's 30;
see the note below the scissors of patch 1.
lan4 keeps EEE disabled and never arms LPI, which is what dropping
2500BASE-X from lpi_interfaces is for. Forwarding through it was
lossless with no carrier change.
====================
Link: https://patch.msgid.link/20260903123644.23800-1-f@lex.la
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
phylink_create() decides once and for all that a MAC supports managed
EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and
lpi_interfaces. mtk_add_mac() leaves lpi_interfaces empty.
So ever since EEE support was added, ethtool has answered "Not
supported" on every MAC that uses mtk_phylink_ops, and
phy_disable_eee() has locked userspace out of turning EEE on. MT7628
is unaffected, as rt5350_phylink_ops has no tx_lpi methods.
Leave 2.5 Gbps out of both bitmaps, and the xGMII modes that
mtk_mac_enable_tx_lpi() already refuses. MAC_MCR folds SPEED_2500 onto
MAC_MCR_SPEED_1000, so MAC_MCR_EEE1G would govern LPI on such a link,
and that is unvalidated rather than known unsupported: MediaTek's SDK
driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the
unit of the wakeup timers is undocumented with the port clock at
2.5 times the rate.
mtk_mac_enable_tx_lpi() programs wake-up times taken from MT7531's
reset values, and the SoC's own field has no reset value to fall
back on. Only MT7981 has been seen to exit LPI cleanly with them, so
the LPI interfaces sit behind a new MTK_GMAC_EEE capability that only
MT7981 sets; every other SoC keeps the current behaviour until it has
been confirmed.
LPI stays off until userspace enables it, but the EEE advertisement of
a PHY that advertises it out of reset comes back, since phylink stops
force-clearing it.
Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260903123644.23800-3-f@lex.la
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
phylink_create() decides once and for all that a MAC supports managed
EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and
lpi_interfaces. mt753x_phylink_get_caps() leaves lpi_interfaces empty.
So ever since the conversion to phylink managed EEE, ethtool has
answered "Not supported" on every mt753x port, and phy_disable_eee()
has locked userspace out of turning EEE on. That undoes what
commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531
switch on all boards") arranged: EEE off by default, but reachable
with ethtool.
Leave the speeds above 1 Gbps out of both bitmaps. PMCR folds
SPEED_2500 and SPEED_10000 onto PMCR_FORCE_SPEED_1000, so
PMCR_FORCE_EEE1G would govern LPI on such a link, and that is
unvalidated rather than known unsupported: MediaTek's SDK driver sets
the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the
wakeup timers is undocumented with the port clock at 2.5 times the
rate.
LPI stays off until userspace enables it, but the EEE advertisement of
a PHY that advertises it out of reset comes back, since phylink stops
force-clearing it.
Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260903123644.23800-2-f@lex.la
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Periodic AS SDP (skip frames) drives a Panel Replay panel down toward its
minimum refresh rate. It is a new, panel- and platform-sensitive behaviour,
so keep it opt-in rather than enabling it unconditionally.
Expose it as a per-device debugfs knob, enable_periodic_assdp, rather than a
module parameter. The behaviour is panel-specific, so the correct granularity
is per-device, not per-module. The knob is added through the intel_display_params
infrastructure (shared by i915 and xe) with a debugfs entry only. It defaults to
false (feature disabled); write 1 to the debugfs file to enable periodic AS SDP
at runtime.
Gate the feature at its single choke point, intel_pr_as_sdp_skip_frames():
returning a zero skip count when the knob is off makes both the PR_ALPM_CTL
programming (intel_alpm_configure_pr_as_sdp()) and the DC3co force-disable
predicate (intel_alpm_pr_as_sdp_skip_frames_enabled()) a no-op, so AS SDP
continues to be sent on every frame as before.
v2: Switch to debugfs entry and drop module param
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-5-uma.shankar@intel.com
|
|
All existing DTS users already name the INTx child node
"interrupt-controller". Use of_get_child_by_name() to find it instead
of assuming it is the first child node.
Signed-off-by: Zhengping Zhang <aquapinn@qq.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/tencent_5E7D6E7FB25B4CD732F08547C11F5DA24808@qq.com
|
|
In calibrate_ccount(), of_clk_get() acquires a reference to the CPU
clock, but clk_put() is never called to release it. The clock
reference is used only to read the frequency via clk_get_rate(),
then the function returns immediately, leaking the reference.
Fix this by calling clk_put(clk) before returning.
Signed-off-by: 赵宇 <1466528493@qq.com>
Message-ID: <tencent_7AF43562265F45B58A25576CAFCE66967708@qq.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
check_mbox_seq_id_and_seg_len() validates that seq_id does not
exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed
MBOX_SEG_LEN (48). However, this allows the last segment
(seq_id=42) to carry a full 48-byte payload, writing to offset
42*48=2016 for 48 bytes (ending at byte 2064). The receive
buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a
16-byte heap buffer overflow.
The hinic3 driver already handles this correctly by defining
MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it
exceeds the remaining buffer space. Apply the same fix to the
hinic driver.
Fixes: a425b6e1c69b ("hinic: add mailbox function support")
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
Link: https://patch.msgid.link/AS8P251MB0001AE870B09020B46B5D7DBC8B22@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The AS SDP skip-frame count is written to PR_ALPM_CTL only from
lnl_alpm_configure(), which runs from intel_psr_enable_locked() on a
Panel Replay disabled->enabled transition. VRR, however, can be enabled
and disabled seamlessly - without a modeset and without cycling Panel
Replay (intel_crtc_vrr_enabling()/disabling() in the pipe update path).
As a result, when a panel comes up with VRR off the non-zero skip count
is programmed, and when VRR is later turned on seamlessly PR stays
enabled, lnl_alpm_configure() is not re-invoked, and the stale skip
count is left in the register. This also leaves the coupled AS SDP
transmission / DC3CO idle-protocol bits inconsistent with the DC3co
state, which is recomputed on every commit.
Factor the PR_ALPM_CTL AS SDP programming out of lnl_alpm_configure()
into intel_alpm_configure_pr_as_sdp() and expose
intel_alpm_pr_as_sdp_update(), which recomputes those fields for the
current VRR state. Call it from the seamless VRR enable and disable
sites (non-modeset only; a modeset re-runs PR enable anyway) so the skip
counter always matches whether VRR is actively driving the refresh rate.
v2: Fixed Sashiko review comments
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-4-uma.shankar@intel.com
|
|
Periodic AS SDP (skip frames) relies on the AS SDP still being
transmitted while Panel Replay is active. DC3co uses the idle protocol
which suppresses AS SDP transmission entirely, so the two are mutually
exclusive: leaving DC3co enabled while skip frames is programmed breaks
the periodic AS SDP and the panel never sees the slower refresh.
Add intel_alpm_pr_as_sdp_skip_frames_enabled() as the single predicate
for "skip frames will be programmed" (mirroring the gating in
lnl_alpm_configure(), including that it only applies when VRR is not
active) and use it in intel_display_power_dc3co_compute() to force the
DC3co trigger to NONE. This drops the pipe onto the
DC_STATE_EN_UPTO_DC6 target instead of DC3co whenever skip frames is
active, without touching the DC state module parameter or the allowed
DC mask, and only for the skip-frame case.
v2: Fixed Sashiko review findings
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-3-uma.shankar@intel.com
|
|
When Panel Replay is active the transcoder timing generator runs at the
panel's maximum refresh rate. To drive the panel down to its minimum
refresh rate the Adaptive-Sync SDP (AS SDP) only needs to reach the panel
once per minimum-rate frame, so transmitting it on every (maximum-rate)
frame is redundant and shows up as repeated SDPs on the link.
Xe3p_LPD adds a HW skip-frame counter in PR_ALPM_CTL that lets the source
send a single AS SDP and then suppress it for a programmed number of
frames. Program this counter so that one AS SDP is followed by
(max_vrefresh / min_vrefresh - 1) idle frames, i.e. one AS SDP per
slowest panel frame, allowing the link to be driven down to as low as
1Hz when the hardware supports it.
The maximum and minimum refresh rates come from the panel's adaptive-sync
monitor range, so the skip count is a function of the sink's capabilities
and independent of the current content/flip rate. If the panel does not
advertise a usable range the skip counter is left at zero, i.e. the
feature is a no-op and AS SDP continues to be sent on every frame.
Periodic AS SDP drives the panel down to its minimum refresh rate on its
own, so it is only programmed when VRR is not actively driving the
refresh rate.
The skip-frame mechanism relies on the AS SDP still being transmitted
(just less often) while Panel Replay is active, so when a non-zero
skip-frame count is programmed both
PR_ALPM_CTL_AS_SDP_TRANSMISSION_IN_ACTIVE_DISABLE and
PR_ALPM_CTL_USE_DC3CO_IDLE_PROTOCOL are left cleared. The previous
behaviour (honouring disable_as_sdp_when_pr_active and the DC3CO idle
protocol) is retained for the non skip-frame case.
v3: Fixed Sashiko review findings
v2: Decoupled CMMRR dependency and using sink refresh rate range for
skip frame claculations. This addresses Dibin's review feedback as well.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-2-uma.shankar@intel.com
|
|
of_parse_phandle() returns a node pointer with an elevated refcount.
Add the missing of_node_put() on the probe error path after
register_netdev() fails and in emac_remove().
Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's")
Signed-off-by: Li Youhong <liyouhong@kylinos.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260904080758.2432748-1-dayou5941@163.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Tianyi Chen <hi@tychen.cc> says:
memblock tests: cover low-address allocations
Model a low allocation limit within the memory registered by the simulator,
then exercise memblock_alloc_low() in both allocation directions.
Validation with ASan and UBSan enabled:
- Default and 32BIT_PHYS_ADDR_T=1: 189 tests pass in each runtime mode.
- NUMA=1, 32BIT_PHYS_ADDR_T=1 with NUMA=1, and MEMBLOCK_DEBUG=1 with NUMA=1:
272 tests pass in each runtime mode.
- Both ./main -v and ./main -v -m were run for those configurations.
- BUILD=32 builds without warnings from alloc_low_api.c. Its runtime still
hits the pre-existing basic_api.c memblock_free_near_max_check assertion
before reaching the low-allocation tests.
Link: https://patch.msgid.link/cover.1788997523.git.hi@tychen.cc
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Add memblock_alloc_low() coverage using the simulator's low address
limit. Exercise aligned allocation, an allocation whose last byte is
immediately below the limit, an alignment constraint that prevents
fitting below it, and fully reserved low memory with high memory still
available.
Run each case with bottom-up and top-down allocation. Check zeroing
and reserved-region accounting as well as returned addresses. Verify
that an unrestricted allocation can use the free high memory after
the low allocation fails.
Document the simulated limit and remove the completed TODO.
Assisted-by: LLM
Signed-off-by: Tianyi Chen <hi@tychen.cc>
Link: https://patch.msgid.link/142ab1025fd1e4b5dcd2a1591b964626ebce9d23.1788997523.git.hi@tychen.cc
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
The simulator represents physical addresses using the address of its
allocated buffer. That buffer can lie above the default
ARCH_LOW_ADDRESS_LIMIT, preventing meaningful memblock_alloc_low()
tests.
Use the architecture override in asm/dma.h to place the limit halfway
through the memory registered by setup_memblock(). Resolve the limit
after allocating the buffer, leaving registered memory on both sides.
Assisted-by: LLM
Signed-off-by: Tianyi Chen <hi@tychen.cc>
Link: https://patch.msgid.link/f16c272cd52316b83c35d87987b4d8687c4a3182.1788997523.git.hi@tychen.cc
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
If a netlink socket sends RTM_GETCHAIN requests repeatedly
without recv()ing the responses, tc_ctl_chain() hogs CPU and
triggers Hung Task splat. [0]
As caught in the stack trace, netlink_attachskb() could confuse
tc_ctl_chain() by returning -EAGAIN when the userspace netlink
socket's receive buffer is full.
The replay: label exists since commit 32a4f5ecd738 ("net: sched:
introduce chain object to uapi") but was not used initially.
Since commit 9f407f1768d3 ("net: sched: introduce chain templates"),
the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops()
may release RTNL to call request_module().
However, the replay logic is unnecessary for RTM_GETCHAIN.
Let's apply the replay logic only for RTM_NEWCHAIN.
[0]:
INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022.
task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000
Call Trace:
<TASK>
? clockevents_program_event (kernel/time/clockevents.c:372)
? pskb_expand_head (net/core/skbuff.c:615)
? skb_release_data (net/core/skbuff.c:1122)
? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232)
? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499)
? tc_chain_notify (net/sched/cls_api.c:3045)
? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041)
? netlink_unicast (net/netlink/af_netlink.c:1335)
? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985)
? tc_ctl_chain (net/sched/cls_api.c:3242)
? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146)
? netlink_unicast (net/netlink/af_netlink.c:1354)
? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177)
? netlink_rcv_skb (net/netlink/af_netlink.c:2556)
? netlink_unicast (net/netlink/af_netlink.c:1319)
? netlink_sendmsg (net/netlink/af_netlink.c:1900)
? __sock_sendmsg (net/socket.c:800)
? __sys_sendto (net/socket.c:2281)
? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284)
? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
</TASK>
Fixes: 2ed9db3074fc ("net: sched: cls_api: fix dead code in switch")
Reported-by: Taras Madan <tarasmadan@google.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Tested-by: hybris@mojatatu.ai
Link: https://patch.msgid.link/20260908205537.863484-1-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
David Howells <dhowells@redhat.com> says:
netfs: Miscellaneous preparatory changes
This a collection of miscellaneous modifications to netfslib that I want to
make ahead of bigger changes, including:
(1) Convert "unsigned long long" to "uoff_t". This makes it a little more
obvious as to the meaning of the value. Also convert some "loff_t" to
"uoff_t" as most of the time it's used the value really should never
be negative.
(2) Remove the writethrough code as the locking is really tricky to get
right and it looks like it could deadlock with Ceph if snapshots are
used.
(3) Adjust some tracepoints, including adding the cache object ID to
certain tracepoinits.
(4) Make use of PG_private_2 opt-in. Use of PG_private_2 is deprecated
and the MM people would like their page bit back, so we need to stop
using it soon.
(5) Add some helper functions to handle the barriering needed for the
NETFS_RREQ_ALL_QUEUED flag.
(6) Set the subrequest type at allocation time so that the allocation
trace records the proposed type.
* patches from https://patch.msgid.link/20260909072105.1663687-1-dhowells@redhat.com:
netfs: Set subrequest->source at alloc before trace emission
netfs: Add some functions to wrap the all-queued handling
netfs: Make deprecated PG_private_2 support opt-in
netfs: Add the cache object ID to netfs_read/write tracepoints
netfs: trace: Rejig a couple of the tracepoints
netfs: trace: Change the "clear" folio traces to "endwb"
netfs: Remove the writethrough code
netfs: Use uoff_t instead of unsigned long long and loff_t
Link: https://patch.msgid.link/20260909072105.1663687-1-dhowells@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Set subrequest->source in netfs_alloc_subrequest() before we emit the trace
line indicating we allocated the subrequest. Note that this requires the
allocation of the subreq in netfs_read_to_pagecache() to be pushed to after
the decision about what sort of subreq it should be.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-9-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
cc: linux-mm@kvack.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Add some helper functions to wrap the handling of the NETFS_RREQ_ALL_QUEUED
flag and to insert the appropriate barriers. Also add an
smb_mb__after_atomic() after the set_bit() to make sure stuff after the
set_bit() in the same thread doesn't get ordered before.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-8-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Make the deprecated PG_private_2 support opt-in, requiring it to be
selected by the filesystems that might want to use it.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-7-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: Trond Myklebust <trondmy@kernel.org>
cc: Anna Schumaker <anna@kernel.org>
cc: Ilya Dryomov <idryomov@gmail.com>
cc: Alex Markuze <amarkuze@redhat.com>
cc: Viacheslav Dubeyko <slava@dubeyko.com>
cc: netfs@lists.linux.dev
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Add the cache object debug ID to netfs_read/write tracepoints to make
debugging easier as there's now a direct cross-reference with the
cachefiles tracepoints that only log that debug ID.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-6-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Rejig the following tracepoints:
(1) Change netfs_folio to show the pfn.
(2) Change netfs_collect_folio to show a folio index range rather than
file position range and don't show the cleaned_to or collected_to
points.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-5-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Change the "clear" folio traces to "endwb" as it's more obvious what it
means.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-4-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Remove the netfs writethrough code as it's very tricky to get the locking
right and it will probably deadlock if used in conjunction with Ceph
snapshots because it excludes writeback for the duration, but to flush out
old snapshots, it does a synchronous flush that invokes writeback.
Instead, O_SYNC writes do a flush after performing the write - which is
already there as the callers of netfs_perform_write() all call
generic_write_sync().
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-3-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Use uoff_t instead of unsigned long long and loff_t for file positions that
can't be negative.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260909072105.1663687-2-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
The scratch_phys documentation incorrectly tells users to use it
together with scratch_phys. It should refer to scratch_len, which
provides the length of each scratch region.
Signed-off-by: Kamalesh Babulal <kamalesh.babulal@oracle.com>
Link: https://patch.msgid.link/20260909103001.2423403-1-kamalesh.babulal@oracle.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
No architecture provides an implementation of
arch_kexec_locate_mem_hole(). Use kexec_locate_mem_hole() directly
and remove the unused fallback wrapper from the kexec header.
This simplifies the kexec memory allocation path without changing
its behavior. No functional changes intended.
The arch hook was introduced by commit f891f19736bd ("kexec_file: Allow
archs to handle special regions while locating memory hole"), and its
last user was removed by commit 6e5250eaa665 ("powerpc/crash: use
generic APIs to locate memory hole for kdump").
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: linux-riscv@lists.infradead.org
Cc: kexec@lists.infradead.org
Acked-by: Baoquan He <baoquan.he@linux.dev>
Reviewed-by: Mukesh Pilaniya <mpilaniy@redhat.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Link: https://patch.msgid.link/20260905145835.501635-1-sourabhjain@linux.ibm.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Victor Nogueira says:
====================
net/sched: cls_route: fix bucket retention and handle recomputation
Patch 1 is the v1 patch, unchanged. route4_change() can move an existing
filter to a different top-level bucket, since route4_set_parms()
recomputes the handle from TCA_ROUTE4_TO/FROM/IIF. The filter is
unlinked from the old bucket, but the bucket itself is never freed once
it goes empty, so route4_delete() keeps reporting *last=false after the
last live filter is gone. That pins the empty tcf_proto and leaks it.
The filters linked to a bucket are refcounted now, and the bucket is
dropped from head->table[] as soon as the count reaches zero.
Reviewing v1, Sashiko pointed out that the duplicate scan in
route4_set_parms() compares against the wrong handle [1]. Patches 2 and
3 fix the two symptoms of that.
Patch 2 makes the scan compare against nhandle. f->handle is the handle
the filter has before the update, not the one it is about to be linked
under, so a change that moves a filter into a chain already holding
nhandle misses the collision and links a second filter under the same
handle. The newcomer is then unreachable: route4_get() returns the
incumbent, and route4_classify() stops at the first filter whose f->id
matches.
Patch 3 handles the mirror case. An in-place replace computes an nhandle
that the filter being replaced already carries, so the scan finds that
filter and rejects the request with -EEXIST. The older filter is passed
to route4_set_parms() and skipped in the scan. Skipping it alone would
rename the filter it replaces: the 0x7F00 order bits are carried in no
attribute and were folded into nhandle on the create path alone, so an
order 1 filter came back as order 0, and a sibling sharing its key could
then no longer be replaced at all. They are carried over now whenever
the request builds the key the filter already has, which leaves a
request that does change the key renaming the filter as before.
Patch 4 adds tdc coverage for all three, including the cross-bucket move
case Sashiko noted route.json had no test for.
[1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829205422.854785-1-victor%40mojatatu.com
====================
Link: https://patch.msgid.link/20260907192133.2639067-1-victor@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
