Issues reported with v6.18-rc:
- Revert the patch that removed the cap on MAX_OPS_PER_COMPOUND
- Address a kernel build issue
Issues that need expedient stable backports:
- Fix crash when a client queries new attributes on forechannel
- Fix rare NFSD crash when tracing is enabled
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEKLLlsBKG3yQ88j7+M2qzM29mf5cFAmj/uZAACgkQM2qzM29m
f5fj5Q//cMu68pn3+TOjOb6N1v0SBLLfjg6ailkHV4IX8lK5Kt9MhXSmBUzkjwX/
YDl4NYnLR5dG4vrw0Vx4xynnIg45EjbZkjHLDeeTB2knC8EFi0Ij1Cml0fM8RSyP
cgv7Z5Pg6QD9BVa6tBvgPh9+We1yHEip/FE0T9mADF3qrj4wqOhmf4JKNauaDsGH
2Lj0SSuN36AHv30+Yuur4saSFxpDKQyAVgrGqq8V247mIrI0BGAH6uIHentVXqIk
WdHVD9biPJ1bhpILOiGWH/yeF2/eG6WimWuCnw7uosyc+AI6pW00Mg/1cJDIQvc+
yMQLj8b0Nnt4QzF7BEu6TUof8yg8UKZLYQ34ch4E8uqYCy9VUSCYrB/Frb64HkqV
3/nC+IqX91SmGCa/5DHCJauWCjkNKkNbgzRceu+BfCpC9aCAuos05U/OP0E8doqM
yBPYBiULDcQNN8DmXKWyqJn6h+ZOMcBAMAj2cBYDcaxLI9HGbM8eTBXlC0/8G8Bc
gRc00/7D3Y4KazLDCc/2v+Y/vR/P4f44rGVdDOdDrPjCy4EVfe30eINLsy2Ng3Z9
ulenzTNaz1wjKIkxcg4SBF0QDfWpRRPw4YY7Gc+/T70zoTPNZHVpsRsWR3Auxs6w
wBWcE4al7Q9iWE+jmm+pIL64QNDyAkDJrU2FCT7SqaAOBiP/xw0=
=4PHG
-----END PGP SIGNATURE-----
Merge tag 'nfsd-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
Pull nfsd fixes from Chuck Lever:
"Regression fixes:
- Revert the patch that removed the cap on MAX_OPS_PER_COMPOUND
- Address a kernel build issue
Stable fixes:
- Fix crash when a client queries new attributes on forechannel
- Fix rare NFSD crash when tracing is enabled"
* tag 'nfsd-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"
nfsd: Avoid strlen conflict in nfsd4_encode_components_esc()
NFSD: Fix crash in nfsd4_read_release()
NFSD: Define actions for the new time_deleg FATTR4 attributes
Sean reported [1] the following splat when running KVM tests:
WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70
Call Trace:
<TASK>
fpu__clear_user_states+0x9c/0x100
arch_do_signal_or_restart+0x142/0x210
exit_to_user_mode_loop+0x55/0x100
do_syscall_64+0x205/0x2c0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Chao further identified [2] a reproducible scenario involving signal
delivery: a non-AMX task is preempted by an AMX-enabled task which
modifies the XFD MSR.
When the non-AMX task resumes and reloads XSTATE with init values,
a warning is triggered due to a mismatch between fpstate::xfd and the
CPU's current XFD state. fpu__clear_user_states() does not currently
re-synchronize the XFD state after such preemption.
Invoke xfd_update_state() which detects and corrects the mismatch if
there is a dynamic feature.
This also benefits the sigreturn path, as fpu__restore_sig() may call
fpu__clear_user_states() when the sigframe is inaccessible.
[ dhansen: minor changelog munging ]
Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1]
Fixes: 672365477a ("x86/fpu: Update XFD state where required")
Reported-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Tested-by: Chao Gao <chao.gao@intel.com>
Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2]
Cc:stable@vger.kernel.org
Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com
Add handling for events for the electronic privacy screen found on some
models (e.g. Dell Latitude 7300) being toggled on/off.
Emit KEY_EPRIVACY_SCREEN_OFF / KEY_EPRIVACY_SCREEN_ON events for this so
that userspace can show the usual on-screen-display (OSD) notification for
eprivacy screen on/off to the user.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Link: https://patch.msgid.link/20251020152331.52870-3-hansg@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add keycodes for hotkeys toggling the electronic privacy screen found on
some laptops on/off.
There already is an API for eprivacy screens as kernel-mode-setting drm
connector object properties:
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties
this API also supports reporting when the eprivacy screen is turned on/off
by the embedded-controller (EC) in response to hotkey presses.
But on some laptops (e.g. the Dell Latitude 7300) the firmware does not
allow querying the presence nor the status of the eprivacy screen at boot.
This makes it impossible to implement the drm connector properties API
since drm objects do not allow adding new properties after creation and
the presence of the eprivacy cannot be detected at boot.
The first notice of the presence of an eprivacy screen on these laptops is
an EC generated (WMI) event when the eprivacy screen hotkeys are pressed.
In this case the new keycodes this change adds can be generated to notify
userspace of the eprivacy screen on/off hotkeys being pressed, so that
userspace can show the usual on-screen-display (OSD) notification for eprivacy
screen on/off to the user. This is similar to how e.g. touchpad on/off
keycodes are used to show the touchpad on/off OSD.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20251020152331.52870-2-hansg@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add myself as the maintainer of the int3472 driver. Also update Daniel's
e-mail address while at it.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Daniel Scally <dan.scally@ideasonboard.com>
Link: https://patch.msgid.link/20251028084959.394795-1-sakari.ailus@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
regulator_unregister() already frees the associated GPIO device. On
ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
random failures when other drivers (typically Intel THC) attempt to
allocate interrupts. The root cause is that the reference count of the
pinctrl_intel_platform module unexpectedly drops to zero when this
driver defers its probe.
This behavior can also be reproduced by unloading the module directly.
Fix the issue by removing the redundant release of the GPIO device
during regulator unregistration.
Cc: stable@vger.kernel.org
Fixes: 1e5d088a52 ("platform/x86: int3472: Stop using devm_gpiod_get()")
Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Link: https://patch.msgid.link/20251028063009.289414-1-qiuwenbo@gnome.org
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[Why&How]
Return -EINVAL when userspace asks us to enable vblank on a crtc that is
not yet enabled.
Suggested-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1856
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Wayne Lin <wayne.lin@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit cb57b8cdb0)
Cc: stable@vger.kernel.org
[WHY & HOW]
Some eDP panels suffer from flicking when HDR is enabled in KDE or
Gnome.
This add another quirk to worksaround to skip VSC that is incompatible
with an eDP panel.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4452
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Wayne Lin <wayne.lin@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 99441824be)
Cc: stable@vger.kernel.org
This should be MIT. The driver in general is MIT and
the license text at the top of the file is MIT so fix
it.
Fixes: e8529dbc75 ("drm/amdgpu: add ip offset support for cyan skillfish")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 102c4f7c55)
This should be MIT. The driver in general is MIT and
the license text at the top of the file is MIT so fix
it.
Fixes: d1bb646510 ("drm/amdgpu: add irq source ids for VCN5_0/JPEG5_0")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 68c20d7b17)
This should be MIT. The driver in general is MIT and
the license text at the top of the file is MIT so fix
it.
Fixes: 523b69c654 ("drm/amd/include: Add amd cper header")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 72c5482cb0)
These should be MIT. The driver in general is MIT and
the license text at the top of the files is MIT so fix
it.
Fixes: 92d5d2a09d ("drm/amdgpu: Introduce funcs for populating CPER")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit abd3f87640)
Previously this was initialized with zero which represented PCIe Gen
1.0 instead of using the
maximum value from the speed table which is the behaviour of all other
smumgr implementations.
Fixes: 18aafc59b1 ("drm/amd/powerplay: implement fw related smu interface for iceland.")
Signed-off-by: John Smith <itistotalbotnet@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 92b0a6ae66)
Previously this was initialized with zero which represented PCIe Gen
1.0 instead of using the
maximum value from the speed table which is the behaviour of all other
smumgr implementations.
Fixes: 18edef19ea ("drm/amd/powerplay: implement fw image related smu interface for Fiji.")
Signed-off-by: John Smith <itistotalbotnet@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c52238c9fb)
'table_index' is a variable defined by the smu driver (kmd)
'table_id' is a variable defined by the hw smu (pmfw)
This code should use table_index as a bounds check.
Fixes: caad2613dc ("drm/amd/powerplay: move table setting common code to smu_cmn.c")
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fca0c66b22)
Before commit 33056a97ae ("drm/amd/display: Remove double checks for
`debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL)
checked the low-power debug flag before calling
dpp3_power_on_blnd_lut(false).
After commit 33056a97ae ("drm/amd/display: Remove double checks for
`debug.enable_mem_low_power.bits.cm`"), dpp3_program_blnd_lut(NULL)
unconditionally calls dpp3_power_on_blnd_lut(false). The BLNDGAM power
helper writes BLNDGAM_MEM_PWR_FORCE when CM low-power is disabled, causing
immediate SRAM power toggles instead of deferring at vupdate. This can
disrupt atomic color/LUT sequencing during transitions between
direct scanout and composition within gamescope's DRM backend on
Steam Deck OLED.
To fix this, leave the BLNDGAM power state unchanged when low-power is
disabled, matching dpp3_power_on_hdr3dlut and dpp3_power_on_shaper.
Fixes: 33056a97ae ("drm/amd/display: Remove double checks for `debug.enable_mem_low_power.bits.cm`")
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 13ff4f63fc)
Cc: stable@vger.kernel.org
v1:
Pause the workload setting in dm when doinn idle optimization
v2:
Rebase patch to latest kernel code base (kernel 6.16)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bc6d54ac7e)
Since the allocation of the drivers main structure was changed to
devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd
should be done by devres.
However, drm_put_dev() is still in the probe error and device remove
paths. When the driver fails to probe warnings like the following are
shown because devres is trying to drm_put_dev() after the driver
already did it.
[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22
[ 5.649605] ------------[ cut here ]------------
[ 5.649607] refcount_t: underflow; use-after-free.
[ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110
Fixes: a9ed2f052c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc")
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3eb8c0b4c0)
Since the allocation of the drivers main structure was changed to
devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling
kfree() on it.
This fixes things exploding if the driver probe fails and devres cleans up
the rdev after we already free'd it.
Fixes: a9ed2f052c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc")
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 16c0681617)
[Why]
Newer VPE microcode has functionality that will decrease DPM level
only when a workload has run for 2 or more seconds. If VPE is turned
off before this DPM decrease and the PMFW doesn't reset it when
power gating VPE, the SOC can get stuck with a higher DPM level.
This can happen from amdgpu's ring buffer test because it's a short
quick workload for VPE and VPE is turned off after 1s.
[How]
In idle handler besides checking fences are drained check PMFW version
to determine if it will reset DPM when power gating VPE. If PMFW will
not do this, then check VPE DPM level. If it is not DPM0 reschedule
delayed work again until it is.
v2: squash in return fix (Alex)
Cc: Peyton.Lee@amd.com
Reported-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com>
Tested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3ac635367e)
Cc: stable@vger.kernel.org
A recent change fixed device reference leaks when looking up drm
platform device driver data during bind() but failed to remove a partial
fix which had been added by commit 80805b62ea ("drm/mediatek: Fix
kobject put for component sub-drivers").
This results in a reference imbalance on component bind() failures and
on unbind() which could lead to a user-after-free.
Make sure to only drop the references after retrieving the driver data
by effectively reverting the previous partial fix.
Note that holding a reference to a device does not prevent its driver
data from going away so there is no point in keeping the reference.
Fixes: 1f403699c4 ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv")
Reported-by: Sjoerd Simons <sjoerd@collabora.com>
Closes: https://lore.kernel.org/r/20251003-mtk-drm-refcount-v1-1-3b3f2813b0db@collabora.com
Cc: stable@vger.kernel.org
Cc: Ma Ke <make24@iscas.ac.cn>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Sjoerd Simons <sjoerd@collabora.com>
Tested-by: Sjoerd Simons <sjoerd@collabora.com>
Tested-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/dri-devel/patch/20251006093937.27869-1-johan@kernel.org/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
The DWMAC1000 supports 2 timestamping configurations to configure how
frequency adjustments are made to the ptp_clock, as well as the reported
timestamp values.
There was a previous attempt at upstreaming support for configuring this
mode by Olivier Dautricourt and Julien Beraud a few years back [1]
In a nutshell, the timestamping can be either set in fine mode or in
coarse mode.
In fine mode, which is the default, we use the overflow of an accumulator to
trigger frequency adjustments, but by doing so we lose precision on the
timetamps that are produced by the timestamping unit. The main drawback
is that the sub-second increment value, used to generate timestamps, can't be
set to lower than (2 / ptp_clock_freq).
The "fine" qualification comes from the frequent frequency adjustments we are
able to do, which is perfect for a PTP follower usecase.
In Coarse mode, we don't do frequency adjustments based on an
accumulator overflow. We can therefore have very fine subsecond
increment values, allowing for better timestamping precision. However
this mode works best when the ptp clock frequency is adjusted based on
an external signal, such as a PPS input produced by a GPS clock. This
mode is therefore perfect for a Grand-master usecase.
Introduce a driver-specific devlink parameter "ts_coarse" to enable or
disable coarse mode, keeping the "fine" mode as a default.
This can then be changed with:
devlink dev param set <dev> name ts_coarse value true cmode runtime
The associated documentation is also added.
[1] : https://lore.kernel.org/netdev/20200514102808.31163-1-olivier.dautricourt@orolia.com/
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20251024070720.71174-3-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In preparation for fine/coarse support, let's move the subsecond increment
and addend configuration in a dedicated helper.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20251024070720.71174-2-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
says:
====================
net: macb: EyeQ5 support
This series' goal is adding support to the MACB driver for EyeQ5 GEM.
The specifics for this compatible are:
- HW cannot add dummy bytes at the start of IP packets for alignment
purposes. The behavior can be detected using DCFG6 so it isn't
attached to compatible data.
- The hardware LSO/TSO is known to be buggy: add a compatible
capability flag to force disable it.
- At init, we have to wiggle two syscon registers that configure the
PHY integration.
In past attempts [0] we did it in macb_config->init() using a syscon
regmap. That was far from ideal so now a generic PHY driver
abstracts that away. We reuse the bp->sgmii_phy field used by some
compatibles.
We have to add a phy_set_mode() call as the PHY power on sequence
depends on whether we do RGMII or SGMII.
[0]: https://lore.kernel.org/lkml/20250627-macb-v2-15-ff8207d0bb77@bootlin.com/
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
Changes in v3:
- Drop Fixes: trailer on [2/5]. We don't fix any platform using the
driver currently.
- Improve [5/5] commit message; add info about how an unconditional
phy_set_mode_ext() won't break existing platforms.
- Hardbreak 82 characters line in [2/5]; warning by patchwork.
- Trailers:
- 1x Acked-by: Conor Dooley on [1/5].
- 2x Reviewed-by: Andrew Lunn on [1/5] and [4/5].
- 2x Reviewed-by: Maxime Chevallier on [4/5] and [5/5].
- Link to v2: https://lore.kernel.org/r/20251022-macb-eyeq5-v2-0-7c140abb0581@bootlin.com
Changes in v2:
- Drop non net-next patches.
- Re-run get_maintainers.pl to shorten the To/Cc list.
- Rebase upon latest net-next; no changes. Tested on HW.
- Link to v1: https://lore.kernel.org/r/20251021-macb-eyeq5-v1-0-3b0b5a9d2f85@bootlin.com
Past versions of the MACB EyeQ5 patches:
- March 2025: [PATCH net-next 00/13] Support the Cadence MACB/GEM
instances on Mobileye EyeQ5 SoCs
https://lore.kernel.org/lkml/20250321-macb-v1-0-537b7e37971d@bootlin.com/
- June 2025: [PATCH net-next v2 00/18] Support the Cadence MACB/GEM
instances on Mobileye EyeQ5 SoCs
https://lore.kernel.org/lkml/20250627-macb-v2-0-ff8207d0bb77@bootlin.com/
- August 2025: [PATCH net v3 00/16] net: macb: various fixes & cleanup
https://lore.kernel.org/lkml/20250808-macb-fixes-v3-0-08f1fcb5179f@bootlin.com/
---
Théo Lebrun (5):
dt-bindings: net: cdns,macb: add Mobileye EyeQ5 ethernet interface
net: macb: match skb_reserve(skb, NET_IP_ALIGN) with HW alignment
net: macb: add no LSO capability (MACB_CAPS_NO_LSO)
net: macb: rename bp->sgmii_phy field to bp->phy
net: macb: Add "mobileye,eyeq5-gem" compatible
.../devicetree/bindings/net/cdns,macb.yaml | 10 +++
drivers/net/ethernet/cadence/macb.h | 6 +-
drivers/net/ethernet/cadence/macb_main.c | 94 +++++++++++++++++-----
3 files changed, 91 insertions(+), 19 deletions(-)
---
base-commit: 61b7ade9ba
change-id: 20251020-macb-eyeq5-fe2c0d1edc75
Best regards,
====================
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-0-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add support for the two GEM instances inside Mobileye EyeQ5 SoCs, using
compatible "mobileye,eyeq5-gem". With it, add a custom init sequence
that must grab a generic PHY and initialise it.
We use bp->phy in both RGMII and SGMII cases. Tell our mode by adding a
phy_set_mode_ext() during macb_open(), before phy_power_on(). We are
the first users of bp->phy that use it in non-SGMII cases.
The phy_set_mode_ext() call is made unconditionally. It cannot cause
issues on platforms where !bp->phy or !bp->phy->ops->set_mode as, in
those cases, the call is a no-op (returning zero). From reading
upstream DTS, we can figure out that no platform has a bp->phy and a
PHY driver that has a .set_mode() implementation:
- cdns,zynqmp-gem: no DTS upstream.
- microchip,mpfs-macb: microchip/mpfs.dtsi, &mac0..1, no PHY attached.
- xlnx,versal-gem: xilinx/versal-net.dtsi, &gem0..1, no PHY attached.
- xlnx,zynqmp-gem: xilinx/zynqmp.dtsi, &gem0..3, PHY attached to
drivers/phy/xilinx/phy-zynqmp.c which has no .set_mode().
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-5-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The bp->sgmii_phy field is initialised at probe by init_reset_optional()
if bp->phy_interface == PHY_INTERFACE_MODE_SGMII. It gets used by:
- zynqmp_config: "cdns,zynqmp-gem" or "xlnx,zynqmp-gem" compatibles.
- mpfs_config: "microchip,mpfs-macb" compatible.
- versal_config: "xlnx,versal-gem" compatible.
Make name more generic as EyeQ5 requires the PHY in SGMII & RGMII cases.
Drop "for ZynqMP SGMII mode" comment that is already a lie, as it gets
used on Microchip platforms as well. And soon it won't be SGMII-only.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-4-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
LSO is runtime-detected using the PBUF_LSO field inside register DCFG6.
Allow disabling that feature if it is broken by using bp->caps coming
from match data.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-3-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
If HW is RSC capable, it cannot add dummy bytes at the start of IP
packets. Alignment (ie number of dummy bytes) is configured using the
RBOF field inside the NCFGR register.
On the software side, the skb_reserve(skb, NET_IP_ALIGN) call must only
be done if those dummy bytes are added by the hardware; notice the
skb_reserve() is done AFTER writing the address to the device.
We cannot do the skb_reserve() call BEFORE writing the address because
the address field ignores the low 2/3 bits. Conclusion: in some cases,
we risk not being able to respect the NET_IP_ALIGN value (which is
picked based on unaligned CPU access performance).
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-2-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add "cdns,eyeq5-gem" as compatible for the integrated GEM block inside
Mobileye EyeQ5 SoCs. It is different from other compatibles in two main
ways: (1) it requires a generic PHY and (2) it is better to keep TCP
Segmentation Offload (TSO) disabled.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-1-af509422c204@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a missing NULL pointer check after kzalloc() in
iwl_mld_send_proto_offload(). Without this check, a failed
allocation could lead to a NULL dereference.
Fixes: d1e879ec60 ("wifi: iwlwifi: add iwlmld sub-driver")
Signed-off-by: Li Qiang <liqiang01@kylinos.cn>
Link: https://patch.msgid.link/20251017041128.1379715-1-liqiang01@kylinos.cn
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Modify EMLSR debug prints to use IWL_DL_EHT instead
of IWL_DL_INFO. This will allow better communication
with validation as they might enable only IWL_DL_EHT
or IWL_DL_INFO as required.
Add prints to log attempt to switch links when
missed beacons exceed threshold.
Print both link ids and missed beacons when in EMLSR
mode.
Signed-off-by: Nidhish A N <nidhish.a.n@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.3bfc2bc8f410.I405ab2aa81af1ba0ea5eaff343eae1778f2035d9@changeid
If the firmware sends a ROC notification after the driver
cancelled it, we can get into this WARN_ON(). Don't do that,
use IWL_FW_CHECK() instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.48aff2c8922e.Ie27b21eb26b67c8010d13ce9590751cad417d1ad@changeid
Non-HT frames can only be encoded in 20 MHz, however, they
could be duplicated on all/some of the subchannels (mostly
used for RTS/CTS), in which case the firmware will report
and estimate of the overall used bandwidth based on energy
detected. This could be confusing so don't report it that
way, always use 20 MHz for non-HT/legacy frames instead.
Note that currently the value doesn't appear to be used by
mac80211, it never checks the bandwidth field for legacy
encodings.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.23e6695039ca.I3da7c542bde6de4362755f200248dbcc12aa246e@changeid
Start supporting Core 100 FW on those devices.
In addition, the move to the new Core scheme (instead of API scheme)
will start Core 100 and not 99, as planned. Adjust for that as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.00c28b4259da.Idd6281cd647f1b33f2572a8c107c3a3228e03665@changeid
It is not very clear what values we put in min_umac_error_event_table.
For Ma (Meteor Lake), this value is wrong and we get the print:
Not valid error log pointer ...
Just remove the check.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.a64d0803150f.Ie2db385f68e17fb0adcdcb16e5bf0125289e177d@changeid
All wifi7 devices need CONFIG_IWLMLD to be enabled.
If we can't support the wifi7 device and the module is not enabled,
complain to the user.
The check in iwl_req_fw_callback is then no longer required.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.071dae9a5de2.I1603085bac5a796442faa75982f8675647becfec@changeid
This will break current sniffer functionality for firmware
versions that don't have the new API, but supporting both
would be very complex. Convert the code to use only the new
sniffer notification.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20251019114304.85b75a084a2f.I4a18b2043703c1f9a8f55c108dcaaeca7891e19c@changeid
Instead of having a static const array for each possible combination of
features, build the extended capabilities dynamically.
With this we will also stop setting EHT capabilities when it might
actually be disabled.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250915113137.b3c03b56d5a3.I38eaf8ebaf3256e78b4643bef7e3a54aeb4989df@changeid
