| Age | Commit message (Collapse) | Author |
|
AGDI has two types of signaling modes: SDEI and interrupt.
Currently, the AGDI driver only supports SDEI.
Therefore, add support for interrupt signaling mode.
The interrupt vector is retrieved from the AGDI table, and call panic
function when an interrupt occurs.
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Signed-off-by: Kazuhiro Abe <fj1078ii@aa.jp.fujitsu.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The drm_warn() calls in the default cases of various switch statements
in xe_vm.c were missing trailing newlines, which can cause log messages
to be concatenated with subsequent output. Add '\n' to all affected
messages.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Link: https://patch.msgid.link/20251224212116.59021-1-osama.abdelkader@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The GuC reset policy is global, so disabling it on PF can affect all
running VFs. To avoid unintended side effects, restrict setting
upon-any-hang (2) wedged mode on the PF to debug builds only.
Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260107174741.29163-5-lukasz.laguna@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
In upon-any-hang (2) wedged mode, engine resets need to be disabled,
which requires changing the GuC reset policy. VFs are not permitted to
do that.
Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260107174741.29163-4-lukasz.laguna@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Previously, the driver's internal wedged.mode state was updated without
verifying whether the corresponding engine reset policy update in GuC
succeeded. This could leave the driver reporting a wedged.mode state
that doesn't match the actual reset behavior programmed in GuC.
With this change, the reset policy is updated first, and the driver's
wedged.mode state is modified only if the policy update succeeds on all
available GTs.
This patch also introduces two functional improvements:
- The policy is sent to GuC only when a change is required. An update
is needed only when entering or leaving XE_WEDGED_MODE_UPON_ANY_HANG,
because only in that case the reset policy changes. For example,
switching between XE_WEDGED_MODE_UPON_CRITICAL_ERROR and
XE_WEDGED_MODE_NEVER doesn't affect the reset policy, so there is no
need to send the same value to GuC.
- An inconsistent_reset flag is added to track cases where reset policy
update succeeds only on a subset of GTs. If such inconsistency is
detected, future wedged mode configuration will force a retry of the
reset policy update to restore a consistent state across all GTs.
Fixes: 6b8ef44cc0a9 ("drm/xe: Introduce the wedged_mode debugfs")
Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260107174741.29163-3-lukasz.laguna@intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Check correctness of the wedged_mode parameter input to ensure only
supported values are accepted. Additionally, replace magic numbers with
a clearly defined enum.
Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260107174741.29163-2-lukasz.laguna@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The ufshcd driver defines ufshcd_rpm_put() to return an int, but that
return value is never used. It also passes the return value of
pm_runtime_put() to the caller which is not very useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Modify ufshcd_rpm_put() to discard the pm_runtime_put() return value
and change its return type to void.
No intentional functional impact.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Link: https://patch.msgid.link/2781685.BddDVKsqQX@rafael.j.wysocki
|
|
Passing pm_runtime_put() return value to the callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update hps_release() to simply discard the return value of
pm_runtime_put() and always return success to the caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/2302270.NgBsaNRSFp@rafael.j.wysocki
|
|
Failing a debugfs write due to pm_runtime_put() returning a negative
value is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel
has been configured with CONFIG_PM unset, in which case
debug_disable_func() in the coresight driver will always return an
error.
For this reason, update debug_disable_func() to simply discard the
return value of pm_runtime_put(), change its return type to void, and
propagate that change to debug_func_knob_write().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://patch.msgid.link/2058657.yKVeVyVuyW@rafael.j.wysocki
|
|
Failing driver probe due to pm_runtime_put() returning a negative value
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel
has been configured with CONFIG_PM unset.
Accordingly, update omap_hwspinlock_probe() to simply discard the
return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/883243465.0ifERbkFSE@rafael.j.wysocki
|
|
Failing device probe due to pm_runtime_put() returning an error is not
particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return
value of pm_runtime_put() and return success to the caller after
invoking that function.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/1867890.VLH7GnMWUR@rafael.j.wysocki
|
|
Failing a watchdog stop due to pm_runtime_put() returning a negative
value is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzg2l_wdt_stop() and rzv2h_wdt_stop() to simply
discard the return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/3340071.5fSG56mABF@rafael.j.wysocki
|
|
Passing the pm_runtime_put() return value to callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update ccs_post_streamoff() to simply discard the return
value of pm_runtime_put() and always return success to the caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/22966634.EfDdHjke4D@rafael.j.wysocki
|
|
We've been historically ignoring GT resume failure. Since the function
can return error, handle it properly.
v2: Bring up display before bailing (Matt Roper, Rodrigo)
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20251220073657.166810-1-raag.jadav@intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The omap-cpufreq driver is not used in the corresponding defconfigs.
The pseudo platform device to use it was removed by
commit cb6675d6a868 ("ARM: OMAP2+: Remove legacy PM init")
10 years ago.
Checking if there is any need to reactivate it:
For omap3, dra7 there is ti-cpufreq to create cpufreq-dt device
For omap2/4/5 there is cpufreq-dt-plat to create cpufreq-dt device.
For omap1 this driver cannot be selected at all.
So no users, no need to reactivate the driver somehow. So remove it.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Link: https://patch.msgid.link/20260108-omap-cpufreq-removal-v1-1-8fe42f130f48@kemnade.info
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
GC12 VRAM surfaces"
This reverts commit 22a36e660d014925114feb09a2680bb3c2d1e279 once,
which was merged twice due to an incorrect backmerge resolution.
Fixes: ce0478b02ed2 ("Merge tag 'v6.18-rc6' into drm-next")
Signed-off-by: Peter Colberg <pcolberg@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Although NVL-S has a similar Xe3 to PTL/WCL, it requires a unique GuC
firmware.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20251016-xe3p-v3-12-3dd173a3097a@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patch.msgid.link/20260108181956.1254908-9-julia.filipchuk@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260108175145.3535441-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use XOR instead of ANDNOT to fix the logic. The current approach with
(foo & BAR & ~baz) is harder to process, and it proved to be wrong,
than more usual pattern for the comparing misconfiguration using
((foo ^ baz) & BAR) which can be read as "find all different bits
between foo and baz that are related to BAR (mask)". Besides that
it makes the binary code shorter.
Function old new delta
mchp_corespi_setup 103 99 -4
Fixes: 059f545832be ("spi: add support for microchip "soft" spi controller")
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Tested-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260108175100.3535306-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Cross-merge networking fixes after downstream PR (net-6.19-rc5).
No conflicts, or adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Dan has reported two uses of uninitialized variables in __ris_msmon_read().
If an unknown monitor type is encountered then the local variable, now, is
used uninitialized. Fix this by returning early on error. If a non-mbwu
monitor is being read then the local variable, overflow, is not initialized
but still read. Initialize it to false as overflow is not relevant for csu
monitors.
Fixes: 823e7c3712c5 ("arm_mpam: Add mpam_msmon_read() to read monitor value")
Fixes: 9e5afb7c3283 ("arm_mpam: Use long MBWU counters if supported")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202512091519.RBwiJcSq-lkp@intel.com/
Closes: https://lore.kernel.org/r/202512100547.N7QPYgfb-lkp@intel.com/
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The VOP on rk3506:
- Support 2 lane MIPI DSI interface, 1.5Gbps/lane.
- Support RGB interface.
- Max output resolution is 1280x1280@60fps.
- WIN1 layer support RGB888/ARGB8888/RGB565.
- Support Gamma LUT.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-10-kernel@airkyi.com
|
|
The dsi controller found on RK3506 supports up to 2 lanes.
Signed-off-by: Hongming Zou <hongming.zou@rock-chips.com>
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-8-kernel@airkyi.com
|
|
Make it a little less convoluted, and just directly check if the
combination of plane + format + modifier is supported.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-8-83463c075a8d@collabora.com
|
|
We don't need to do a long open-coded walk here; we can simply check the
modifier value.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-7-83463c075a8d@collabora.com
|
|
Make sure we can't break the hardware by requesting an unsupported
configuration.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-6-83463c075a8d@collabora.com
|
|
Planes can only source AFBC framebuffers at multiples of 4px wide on
RK3566/RK3568. Instead of clipping on all SoCs when the user asks for an
unaligned source rectangle, reject the configuration in the plane's
atomic check on RK3566/RK3568 only.
Signed-off-by: Daniel Stone <daniels@collabora.com>
[Make RK3566/RK3568 specific, reword message, s/byte/pixel/]
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-5-83463c075a8d@collabora.com
|
|
It seems only cluster windows are capable of applying downscaling when
the source region has an odd width. Instead of applying a workaround
inside atomic_update, fail the plane check if this is requested.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-4-83463c075a8d@collabora.com
|
|
If we want to find out if a window is Esmart or not, test for not being
a cluster window, rather than AFBDC presence.
No functional effect as only cluster windows support AFBC decode.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-3-83463c075a8d@collabora.com
|
|
We already clip the plane to the display bounds in atomic_check, and
ensure that it is sufficiently sized. Instead of trying to catch this
and adjust for it in atomic_update, just assert that atomic_check has
done its job.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-2-83463c075a8d@collabora.com
|
|
We should never be able to create a framebuffer with an unsupported
format, so throw a warning if this ever happens.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-1-83463c075a8d@collabora.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter and wireless.
Current release - fix to a fix:
- net: do not write to msg_get_inq in callee
- arp: do not assume dev_hard_header() does not change skb->head
Current release - regressions:
- wifi: mac80211: don't iterate not running interfaces
- eth: mlx5: fix NULL pointer dereference in ioctl module EEPROM
Current release - new code bugs:
- eth: bnge: add AUXILIARY_BUS to Kconfig dependencies
Previous releases - regressions:
- eth: mlx5: dealloc forgotten PSP RX modify header
Previous releases - always broken:
- ping: fix ICMP out SNMP stats double-counting with ICMP sockets
- bonding: preserve NETIF_F_ALL_FOR_ALL across TSO updates
- bridge: fix C-VLAN preservation in 802.1ad vlan_tunnel egress
- eth: bnxt: fix potential data corruption with HW GRO/LRO"
* tag 'net-6.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (70 commits)
arp: do not assume dev_hard_header() does not change skb->head
net: enetc: fix build warning when PAGE_SIZE is greater than 128K
atm: Fix dma_free_coherent() size
tools: ynl: don't install tests
net: do not write to msg_get_inq in callee
bnxt_en: Fix NULL pointer crash in bnxt_ptp_enable during error cleanup
net: usb: pegasus: fix memory leak in update_eth_regs_async()
net: 3com: 3c59x: fix possible null dereference in vortex_probe1()
net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset
wifi: mac80211: collect station statistics earlier when disconnect
wifi: mac80211: restore non-chanctx injection behaviour
wifi: mac80211_hwsim: disable BHs for hwsim_radio_lock
wifi: mac80211: don't iterate not running interfaces
wifi: mac80211_hwsim: fix typo in frequency notification
wifi: avoid kernel-infoleak from struct iw_point
net: airoha: Fix schedule while atomic in airoha_ppe_deinit()
selftests: netdevsim: add carrier state consistency test
net: netdevsim: fix inconsistent carrier state after link/unlink
selftests: drv-net: Bring back tool() to driver __init__s
net/sched: act_api: avoid dereferencing ERR_PTR in tcf_idrinfo_destroy
...
|
|
The latest firmware increases the major version number. Update
aie2_check_protocol() to accept and support the new firmware version.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20251219014356.2234241-2-lizhi.hou@amd.com
|
|
The latest firmware requires the message DMA buffer to
- have a minimum size of 8K
- use a power-of-two size
- be aligned to the buffer size
- not cross 64M boundary
Update the buffer allocation logic to meet these requirements and support
the latest firmware.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20251219014356.2234241-1-lizhi.hou@amd.com
|
|
These methods just read the values stored in the op pointers without
modifying them, so it is appropriate to use const ptrs here.
This allows us to avoid const -> mut pointer casts in Rust.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-3-dbd014005a0b@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
In commit 9ce4aef9a5b1 ("drm/gpuvm: take GEM lock inside
drm_gpuvm_bo_obtain_prealloc()") we update
drm_gpuvm_bo_obtain_prealloc() to take locks internally, which means
that it's only usable in immediate mode.
In this commit, we notice that drm_gpuvm_bo_obtain() requires you to use
staged mode. This means that we now have one variant of obtain for each
mode you might use gpuvm in.
To reflect this information, we add a warning about using it in
immediate mode, and to make the distinction clearer we rename the method
with a _locked() suffix so that it's clear that it requires the caller
to take the locks.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-2-dbd014005a0b@google.com
[ Slightly reword commit message to refer to commit 9ce4aef9a5b1
("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()").
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-01-06 (idpf)
This series contains updates to idpf driver only.
Emil fixes issues related to resets; among them timeouts, NULL pointer
dereferences, and memory leaks.
Sreedevi resolves issues around RSS; mainly involving operations when
the interface is down and resets. She also addresses some incomplete
cleanups for ntuple filters and interrupts.
Erik fixes incomplete output of ntuple filters.
Josh sets restriction of Rx buffer size to follow hardware restrictions.
Larysa adds check to prevent NULL pointer dereference when RDMA is not
enabled.
* '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
idpf: fix aux device unplugging when rdma is not supported by vport
idpf: cap maximum Rx buffer size
idpf: Fix error handling in idpf_vport_open()
idpf: Fix RSS LUT NULL ptr issue after soft reset
idpf: Fix RSS LUT configuration on down interfaces
idpf: Fix RSS LUT NULL pointer crash on early ethtool operations
idpf: fix issue with ethtool -n command display
idpf: fix memory leak of flow steer list on rmmod
idpf: fix error handling in the init_task on load
idpf: fix memory leak in idpf_vc_core_deinit()
idpf: fix memory leak in idpf_vport_rel()
idpf: detach and close netdevs while handling a reset
idpf: keep the netdev when a reset fails
====================
Link: https://patch.msgid.link/20260107000648.1861994-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The max buffer size of ENETC RX BD is 0xFFFF bytes, so if the PAGE_SIZE
is greater than 128K, ENETC_RXB_DMA_SIZE and ENETC_RXB_DMA_SIZE_XDP will
be greater than 0xFFFF, thus causing a build warning.
This will not cause any practical issues because ENETC is currently only
used on the ARM64 platform, and the max PAGE_SIZE is 64K. So this patch
is only for fixing the build warning that occurs when compiling ENETC
drivers for other platforms.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601050637.kHEKKOG7-lkp@intel.com/
Fixes: e59bc32df2e9 ("net: enetc: correct the value of ENETC_RXB_TRUESIZE")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260107091204.1980222-1-wei.fang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Couple of fixes:
- mac80211:
- long-standing injection bug due to chanctx rework
- more recent interface iteration issue
- collect statistics before removing stations
- hwsim:
- fix NAN frequency typo (potential NULL ptr deref)
- fix locking of radio lock (needs softirqs disabled)
- wext:
- ancient issue with compat and events copying some
uninitialized stack data to userspace
* tag 'wireless-2026-01-08' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: mac80211: collect station statistics earlier when disconnect
wifi: mac80211: restore non-chanctx injection behaviour
wifi: mac80211_hwsim: disable BHs for hwsim_radio_lock
wifi: mac80211: don't iterate not running interfaces
wifi: mac80211_hwsim: fix typo in frequency notification
wifi: avoid kernel-infoleak from struct iw_point
====================
Link: https://patch.msgid.link/20260108140141.139687-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The size of the buffer is not the same when alloc'd with
dma_alloc_coherent() in he_init_tpdrq() and freed.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Link: https://patch.msgid.link/20260107090141.80900-2-fourier.thomas@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When calling drm_gpuvm_bo_obtain_prealloc() and using immediate mode,
this may result in a call to ops->vm_bo_free(vm_bo) while holding the
GEMs gpuva mutex. This is a problem if ops->vm_bo_free(vm_bo) performs
any operations that are not safe in the fence signalling critical path,
and it turns out that Panthor (the only current user of the method)
calls drm_gem_shmem_unpin() which takes a resv lock internally.
This constitutes both a violation of signalling safety and lock
inversion. To fix this, we modify the method to internally take the GEMs
gpuva mutex so that the mutex can be unlocked before freeing the
preallocated vm_bo.
Note that this modification introduces a requirement that the driver
uses immediate mode to call drm_gpuvm_bo_obtain_prealloc() as it would
otherwise take the wrong lock.
Fixes: 63e919a31625 ("panthor: use drm_gpuva_unlink_defer()")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-1-dbd014005a0b@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
When bnxt_init_one() fails during initialization (e.g.,
bnxt_init_int_mode returns -ENODEV), the error path calls
bnxt_free_hwrm_resources() which destroys the DMA pool and sets
bp->hwrm_dma_pool to NULL. Subsequently, bnxt_ptp_clear() is called,
which invokes ptp_clock_unregister().
Since commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to
disable events"), ptp_clock_unregister() now calls
ptp_disable_all_events(), which in turn invokes the driver's .enable()
callback (bnxt_ptp_enable()) to disable PTP events before completing the
unregistration.
bnxt_ptp_enable() attempts to send HWRM commands via bnxt_ptp_cfg_pin()
and bnxt_ptp_cfg_event(), both of which call hwrm_req_init(). This
function tries to allocate from bp->hwrm_dma_pool, causing a NULL
pointer dereference:
bnxt_en 0000:01:00.0 (unnamed net_device) (uninitialized): bnxt_init_int_mode err: ffffffed
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
Call Trace:
__hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72)
bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517)
ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66)
ptp_clock_unregister (drivers/ptp/ptp_clock.c:518)
bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134)
bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889)
Lines are against commit f8f9c1f4d0c7 ("Linux 6.19-rc3")
Fix this by clearing and unregistering ptp (bnxt_ptp_clear()) before
freeing HWRM resources.
Suggested-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
Fixes: a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events")
Cc: stable@vger.kernel.org
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260106-bnxt-v3-1-71f37e11446a@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When an eGPU is unplugged the KFD topology should also be destroyed
for that GPU. This never happens because the fini_sw callbacks never
get to run. Run them manually before calling amdgpu_device_ip_fini_early()
when a device has already been disconnected.
This location is intentionally chosen to make sure that the kfd locking
refcount doesn't get incremented unintentionally.
Cc: kent.russell@amd.com
Closes: https://community.frame.work/t/amd-egpu-on-linux/8691/33
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Replace legacy DRM_ERROR()/DRM_INFO() logging in the UVD v1.0 code
with drm_err() and drm_info() helpers that take a struct drm_device.
Using drm_* logging provides proper device context in dmesg, which is
important for systems with multiple DRM devices, and aligns the radeon
driver with current DRM logging practices.
No functional change intended.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mukesh Ogare <mukeshogare871@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In SRIOV, guest drivers no longer setup/destory
VMR starting from mp0 v11_0_7.
In bare-metal, if boot-time TMR is enabled, some
generation (e.g., mp0 v13_0_x) don’t need runtime
TMR allocation but still require SETUP_TMR command
with tmr address 0 for backward compatibility.
some newer generations require neither SETUP_TMR nor
DESTROY_TMR and will return errors if they are sent.
Driver relies on boot_time_tmr and autoload_supported
to handle these cases correctly.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add helper amdgpu_gtt_mgr_alloc/free_entries, define
GART_ENTRY_WITHOUT_BO_COLOR color for GART node not allocated with GTT
bo, then amdgpu_gtt_mgr_recover skip those mm_node.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Change to switch style checks and return the correct size for gpu board
metrics.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Asad Kamal <asad.kamal@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix several places where %ld or %d has been used in place of
%lu or %u.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When driver not support atomic, fb using plane->fb rather than
plane->state->fb.
Fixes: fe151ed7af54 ("drm/amdgpu: add generic display panic helper code")
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add SMU 15_0_0
v2: rebase (Alex)
v3: fix clang build (Alex)
Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|