For ath12k:
- Add thermal throttling and cooling device support
- Add support for handling incumbent signal interference in 6 GHz
- Add support for channel 177 in the 5 GHz band
In addition, a large number of cleanup and minor bug fixing across
all supported drivers.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCahXEHAAKCRAsFbugiYzL
e4+OAQCK3CILFdb8JbEVgROb/bfAmGWCAkdEBIMxEbGITQSQCAEAsdLEntym8eJA
rjCjLNz62Dn5KoQLaV436nCjC+UjWwo=
=3Pqg
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260526' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.2 (PR #2)
For ath12k:
- Add thermal throttling and cooling device support
- Add support for handling incumbent signal interference in 6 GHz
- Add support for channel 177 in the 5 GHz band
In addition, a large number of cleanup and minor bug fixing across
all supported drivers.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This contains mainly:
UHR support (DPS, DUO, multi-link PM), NAN enhancements
(multicast, schedule config v2, multiple stations), EMLSR fixes, new
Killer/LNL device IDs, firmware API cleanups, and a few bugfixes
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCahWQRAAKCRDacY7uyt+O
fSziAP9kJeU1HvEsGF4k5GHP65F/eLvq7hVrQGfx7Q/vP+ZnkAD+O3SZsyoL8mL1
LAr+ixjuMQ6yLd5xonTJvvtyPQwmVAw=
=SpPv
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2026-05-26' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
iwlwifi - next: 2026-05-26
This contains mainly:
UHR support (DPS, DUO, multi-link PM), NAN enhancements
(multicast, schedule config v2, multiple stations), EMLSR fixes, new
Killer/LNL device IDs, firmware API cleanups, and a few bugfixes
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, there are 2 kernel cmdline ways to setup numa cma area:
"cma_pernuma=" and "numa_cma=", and there are 2 cma arrays as well,
while they have no difference technically. Robin suggested to cleanup
the code and only use one array [1], as "the apparent intent that
users only want one _or_ the other".
Simplify the code by only using one array to save the numa cma area.
And in rare case that a user really setup the 2 cmdline parameters
at the same time, let the per-node specific size setting 'numa_cma='
take priority over the global numa cma setting.
Link[1]: https://lore.kernel.org/lkml/43c5301c-fe6a-41e4-9482-ccfc7b62f2a7@arm.com/
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260525015111.6267-1-feng.tang@linux.alibaba.com
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmoTZAYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGKZ0H/A8Ti79DXqEl4M6V
S1ZYfteuvyWCdygPfY7+CQsxS1EjfmeRXd0213n95jijUoXvAVe7HJ5FuroTltsF
LYqH3CAedeEWMO1rIZjuDs5J1BzWAh7b0/QoanTlAjI1ZL8c3Btj/o//PoQfztiS
HWlN/aCcsZTi9n0ewV9eQM9jdiuhBlpZujfDX90vYurxAB+3K2c1b0UN+Y4/zMXO
83zaDLMYhIh8cEaU52+23H9UpyfrT0B8n6YgqbU4ZBRIbgA1BC4gloT6B7OHFKfq
PAfjAOBfpe43K8lLUyfbkfNohNblLOboiMmekdf+j2y4wqpCO64o6WigCrZtxtHe
9znkJpM=
=H+I9
-----END PGP SIGNATURE-----
Merge v7.1-rc5 into drm-next
Boris Brezillion needs the gem lru fixes 379e8f1ca5 ("drm/gem: Make
the GEM LRU lock part of drm_device") backmerged for drm-misc-next.
That also means we need to sort out the rename conflict in panthor with
the fixup patch from Boris from drm-tip.
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
When we try to assign a chanctx to a link, if
ieee80211_find_or_create_chanctx() failed, we try to evacuate a NAN
channel and call it again.
This logic is broken:
In case there are not enough chanctxs we will fail earlier,
when we check ieee80211_check_combinations().
To fix this, do the following in case ieee80211_check_combinations()
failed:
- check if there is a NAN channel that can be evacuated
- make ieee80211_check_combinations() not consider the chanctx of that NAN
channel, so we pretend that it was already evacuated
- If now ieee80211_check_combinations() is successful, we know that it
helped, and we can remove that NAN channel for real.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260527224745.5f7b10505145.I1712bc64f9eec9c99f05994208ad124624a29f1c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sometimes, ieee80211_check_combinations fails, but it is hard to know
why exactly. We will have to return an array of reasons, one per
combination.
In cases where we want to check if it failed because there are not
enough chanctxs (and maybe remove one if needed), we can just not fill
in that chanctx(s) in iface_combination_params::num_different_channels
in ieee80211_fill_ifcomb_params, so that chanctx(s) won't be taken into
account.
To allow that, add an option to pass a callback to
ieee80211_fill_ifcomb_params. This callback will be called for each
chanctx we consider to count in num_different_channels and will return
whether or not this chanctx should be skipped and not counted.
This mechanism will be used later.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260527224745.0042232f996e.I5d323125e34f3b253510e85ceb7a770d59f689fb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's useful to be able to see the link addresses when the
interface links change, so add some prints to hwsim for the
vif link change callback.
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/20260527224151.b22a048abc7c.Ief2132c5c4bb67fa56e90eb8e7d59dfd9f2b9378@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit 79240f3f6d ("wifi: nl80211: re-check wiphy netns in
nl80211_prepare_wdev_dump() continuation") fixed one dumpit path that
looked the wiphy up by index on a later call without confirming it was
still in the caller's netns. Two more dumpit paths have the same gap.
nl80211_testmode_dump() and nl80211_prepare_vendor_dump() both keep the
wiphy index in cb->args[] and look it up again on later calls, through
cfg80211_rdev_by_wiphy_idx() and wiphy_idx_to_wiphy(). The first call
binds to the caller's netns. A later call does not check it again. In
between, the wiphy can move to another netns via
NL80211_CMD_SET_WIPHY_NETNS.
Add the same net_eq() check to both. On a mismatch, return -ENODEV and
the dump ends.
No mainline driver registers .testmode_dump or
wiphy_vendor_command.dumpit, so these paths are not reachable today.
Drivers outside the tree can register either.
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Link: https://patch.msgid.link/20260527133358.2853238-1-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The current S1G channel list in mac80211_hwsim does not represent
what S1G drivers would advertise that being 1MHz primaries. Also,
include the NO_PRIMARY flag on the edgeband 1MHz primaries to emulate
US operation such that it can also be tested.
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260527033828.183821-3-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211_hwsim_sta_rc_update() is unable to handle S1G widths so
when a new STA is added under a S1G vif the WARN is hit preventing
hwsim use for S1G. For now, skip calling rc_update() for S1G
interfaces. This is required such that the soon-to-be S1G hwsim tests
can successfully run.
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260527033828.183821-2-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We know that "start_raw" is true so remove this check and pull the code
in an tab.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/ahPypOdz-KXh5KAJ@stanley.mountain
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add KUnit coverage for ieee80211_parse_neg_ttlm() to lock the sparse
link_map_presence layout against future regressions.
The sparse_presence_no_oob_read case crafts a negotiated TTLM element
with link_map_presence = BIT(0) | BIT(7) and bm_size = 2 in a buffer
sized exactly to the validated element length. Without the parser
fix this would read 14 bytes past the buffer when processing TID 7;
under KASAN that is a slab-out-of-bounds report.
The dense_presence_baseline case crafts a fully populated
link_map_presence = 0xff element to confirm that the cursor-advance
fix does not regress the path that was already correct.
Export ieee80211_parse_neg_ttlm via VISIBLE_IF_MAC80211_KUNIT so the
test can call it directly.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Link: https://patch.msgid.link/20260515151719.1317659-3-michael.bommarito@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Lenovo Yoga Pro 7 15ASH11 with AMD RYZEN AI MAX+ 388 (Strix Halo, ACP
7.0) uses Realtek ALC287 series codec. The ALC269_FIXUP_LENOVO_XPAD_ACPI
in alc269_fixup_vendor_tbl[] can load lenovo_wmi_hotkey_utilities module
by default in this laptop, but the driver doesn't control mic mute LED.
If users run below command and the mic mute LED can work normally.
$sudo echo 'Capture Switch' >/sys/class/sound/ctl-led/mic/card1/attach
After added the SND_PCI_QUIRK quirk special for Lenovo Yoga Pro 7
15ASH11, the mic mute LED works well.
Fixes: 83dca2530f ("ALSA: hda/realtek: ALC269 fixup for Lenovo Yoga Pro 7 15ASH111 audio")
Signed-off-by: Jackie Dong <xy-jackie@139.com>
Link: https://patch.msgid.link/20260527130353.5658-1-xy-jackie@139.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_ctl_new1() can return NULL when memory allocation fails. In
layout.c, the function does not check the return value before
dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can
lead to a NULL pointer dereference.
Add NULL checks after snd_ctl_new1() calls and return early if any
fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: f3d9478b2c ("[ALSA] snd-aoa: add snd-aoa")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_35F3A25FEEBF190A2E15ED787754C57E3708@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All the other struct dev_pm_ops hooks are named i915_pm_*(), but the
.runtime_suspend and .runtime_resume hooks are called
intel_runtime_suspend() and intel_runtime_resume(), respectively.
Rename intel_runtime_suspend() to i915_pm_runtime_suspend() and
intel_runtime_resume() to i915_pm_runtime_resume() to unify.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/fc5b796a3fd764a64b257edfdbe08e54b690efbc.1779876087.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_display_power_suspend() and intel_display_power_resume()
functions are supposed to be called from the struct dev_pm_pops
.runtime_suspend and .runtime_resume hook paths. Name them accordingly
to intel_display_power_runtime_suspend() and
intel_display_power_runtime_resume().
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.coM>
Link: https://patch.msgid.link/4a8ae520e3151d6cf5d9e9e3a452f620cf781ee5.1779876087.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
snd_ctl_new1() can return NULL when memory allocation fails.
snd_cmipci_spdif_controls() does not check the return value before
dereferencing kctl->id.device, which can lead to a NULL pointer
dereference.
Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any
fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: f2f312ad88 ("ALSA: cmipci: Fix kctl->id initialization")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_964433DCD132125D5EDA79EE068A2D6EFA09@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_ctl_new1() can return NULL when memory allocation fails.
snd_ymfpci_create_spdif_controls() does not check the return value
before dereferencing kctl->id.device, which can lead to a NULL pointer
dereference.
Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any
fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: c9b83ae4a1 ("ALSA: ymfpci: Fix kctl->id initialization")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_4745C5DC2333325C0EDAB1EFC88A136E6809@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_ctl_new1() can return NULL when memory allocation fails. The
ice1712 driver calls snd_ctl_new1() without checking the return value
before dereferencing the pointer in multiple places (ice1712.c,
ice1724.c, aureon.c), which can lead to NULL pointer dereferences.
Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any
fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: b9a4efd61b ("ALSA: ice1712,ice1724: fix the kcontrol->id initialization")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_42E5E2AB1B6A5101F7EE8C2117F1F687BB07@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_ctl_new1() can return NULL when memory allocation fails.
snd_gf1_pcm_volume_control() does not check the return value before
dereferencing kctl->id.index, which can lead to a NULL pointer
dereference.
Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: c5ae57b1bb ("ALSA: gus: Fix kctl->id initialization")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_F644A3DCAD32945D62DB2FEEBE8A996F6809@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a device's default substream attaches to an identity domain, the SMMU
driver currently sets the device's STE between two modes:
Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1
Mode 2: Cfg=bypass (EATS is ignored by HW)
When there is an active PASID (non-default substream), mode 1 is used. And
when there is no PASID support or no active PASID, mode 2 is used.
The driver will also downgrade an STE from mode 1 to mode 2, when the last
active substream becomes inactive.
However, there are PCIe devices that demand ATS to be always on. For these
devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2.
Change the driver accordingly:
- always use the mode 1
- never downgrade to mode 2
- allocate and retain a CD table (see note below)
Note that these devices might not support PASID, i.e. doing non-PASID ATS.
In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to
a !0 value in order to keep the S1DSS field effective. Thus, when a master
requires ats_always_on, set its s1cdmax to at least 1, meaning that the CD
table will have a dummy entry (SSID=1) that will never be used.
Now for these devices, arm_smmu_cdtab_allocated() will always return true,
v.s. false prior to this change. When its default substream is attached to
an IDENTITY domain, its first CD is NULL in the table, which is a totally
valid case. Thus, add "!master->ats_always_on" to the condition.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Some NVIDIA GPU/NIC devices, though they don't implement CXL config space,
have many CXL-like properties. Call this kind "pre-CXL".
Similar to CXL.cache capability, these pre-CXL devices also require the ATS
function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on"
v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases.
Introduce pci_dev_specific_ats_required() quirk function to scan a list of
IDs for these devices. Then, include it in pci_ats_required().
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
snd_ctl_new1() can return NULL when memory allocation fails.
snd_es1938_mixer() does not check the return value before dereferencing
the pointer, which can lead to a NULL pointer dereference.
Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.
Assisted-by: Opencode:DeepSeek-V4-Flash
Cc: stable@vger.kernel.org
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Link: https://patch.msgid.link/tencent_E0DC65165FDF2C8982BAFB6794B854B53B0A@qq.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Controlled by IOMMU drivers, ATS can be enabled "on demand", when a given
PASID on a device is attached to an I/O page table. This is working, even
when a device has no translation on its RID (i.e., RID is IOMMU bypassed).
However, certain PCIe devices require non-PASID ATS on their RID even when
the RID is IOMMU bypassed. Call this "ATS always on" in IOMMU term.
For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other words, the CXL.cache capability requires ATS; otherwise, it can't
access host physical memory.
Introduce a new pci_ats_required() helper for the IOMMU driver to scan a
PCI device and shift ATS policies between "on demand" and "always on".
Add the support for CXL.cache devices first. Pre-CXL devices will be added
in quirks.c file.
Note that pci_ats_required() validates against pci_ats_supported(), so we
ensure that untrusted devices (e.g. external ports) will not be always on.
This maintains the existing ATS security policy regarding potential side-
channel attacks via ATS.
Cc: linux-cxl@vger.kernel.org
Suggested-by: Vikram Sethi <vsethi@nvidia.com>
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Smatch complains about the NULL check on "iommu" because list_entry()
can't be NULL. Clean up this code by using list_for_each_entry().
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
When -Wformat-security is enabled, it catches a call to
iommu_device_sysfs_add() that passes a string variable in
place of a format:
drivers/iommu/vsi-iommu.c: In function 'vsi_iommu_probe':
drivers/iommu/vsi-iommu.c:717:9: error: format not a string literal and no format arguments [-Werror=format-security]
717 | err = iommu_device_sysfs_add(&iommu->iommu, dev, NULL, dev_name(dev));
| ^~~
Pass this indirectly using "%s" as the format instead.
Fixes: 917ace84b7 ("iommu: Add verisilicon IOMMU driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
In init_iommu_one(), when processing IOMMU EFR attributes, the code checks
whether GASUP is enabled. If GASUP is not enabled, the code falls back to
legacy guest IR mode and then breaks out of the switch statement.
This break incorrectly skips the subsequent initialization steps that
follow the GASUP check. These initializations are independent of GASUP
support and must always be performed.
Fix this by replacing the early break with a conditional else block,
ensuring that the XTSUP check is only skipped when GASUP is not available.
Fixes: a44092e326 ("iommu/amd: Use IVHD EFR for early initialization of IOMMU features")
Reported-by: Sudheer Dantuluri <dantuluris@google.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
- Fix the Vec::reserve() doc test to properly account for the existing
vector length in the capacity assertion
- Fix an incorrect operator in the Vec::extend_with() SAFETY comment;
add a doc test demonstrating basic usage and the zero-length case
- Cleanup all imports in the alloc module and its doctests to use the
"kernel vertical" import style
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS2q/xV6QjXAdC7k+1FlHeO1qrKLgUCahOgcAAKCRBFlHeO1qrK
LnUJAP4qD/Mdo35beMgEMzql2vK1Gxcc/tKg4dc8gccHYBtXJgD/cwHcwfjuoSIH
R4a4B43Jz7r+XA1ej9hNr5Ci1f47xgQ=
=ZrNv
-----END PGP SIGNATURE-----
Merge tag 'alloc-7.2-rc1' of https://github.com/Rust-for-Linux/linux into rust-next
Pull alloc updates from Danilo Krummrich:
- Fix the 'Vec::reserve()' doctest to properly account for the existing
vector length in the capacity assertion.
- Fix an incorrect operator in the 'Vec::extend_with()' SAFETY comment;
add a doc test demonstrating basic usage and the zero-length case.
- Cleanup all imports in the alloc module and its doctests to use the
"kernel vertical" import style.
* tag 'alloc-7.2-rc1' of https://github.com/Rust-for-Linux/linux:
rust: alloc: cleanup doctest imports to "kernel vertical" style
rust: alloc: cleanup imports and use "kernel vertical" style
rust: alloc: fix `Vec::extend_with` SAFETY comment
rust: alloc: add doc test for `Vec::extend_with`
rust: alloc: fix assert in `Vec::reserve` doc test
The exynos_gem->base.size argument is a size_t rather than an
unsigned long, so adapt the printk() format string accordingly:
In file included from drivers/gpu/drm/exynos/exynos_drm_gem.c:16:
drivers/gpu/drm/exynos/exynos_drm_gem.c: In function 'exynos_drm_alloc_buf':
drivers/gpu/drm/exynos/exynos_drm_gem.c:69:49: error: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
69 | DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev), "dma_addr(0x%lx), size(0x%lx)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
70 | (unsigned long)exynos_gem->dma_addr, exynos_gem->base.size);
| ~~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka unsigned int}
The dma_addr in the same line is already printed using a cast
to unsigned long, so change that similarly to use the correct
%pad format.
Fixes: 11e898373f ("drm/exynos: Drop exynos_drm_gem.size field")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patch.msgid.link/20260527194525.45762-1-arnd@kernel.org
gcc-16 has gained some more advanced inter-procedual optimization
techniques that enable it to inline the dummy_tlb_add_page() and
dummy_tlb_flush() function pointers into a specialized version of
__arm_v7s_unmap:
WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)
ERROR: modpost: Section mismatches detected.
>From what I can tell, the transformation is correct, as this is only
called when __arm_v7s_unmap() is called from arm_v7s_do_selftests(),
which is also __init. Since __arm_v7s_unmap() however is not __init,
gcc cannot inline the inner function calls directly.
In debug_objects_selftest(), the same thing happens. Both the
caller and the leaf function are __init, but the IPA pulls
it into a non-init one:
WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc+0x7c (section: .text.lookup_object_or_alloc) -> is_static_object (section: .init.text)
Marking the affected functions as not "__init" would reliably avoid this
issue but is not a good solution because it removes an otherwise correct
annotation. I tried marking the functions as 'noinline', but that ended
up not covering all the affected configurations.
With some more experimenting, I found that marking these functions as
__attribute__((noipa)) is both logical and reliable.
In order to keep the syntax readable, add a custom macro for this in
include/linux/compiler_attributes.h next to other related macros and
use it to annotate both files.
Link: https://lore.kernel.org/all/abRB6g-48ZX6Yl2r@willie-the-truck/
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: linux-kbuild@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
All published NPU firmware versions support D0i3 delayed entry
flow, making this workaround obsolete. It was originally added as
a safety measure for potential firmware bugs.
Recent firmware dropped legacy D0i3 entry support, so the workaround
can't be used anyway. Hardcode d0i3_delayed_entry boot param to 1 to
ensure older firmware works in the correct mode.
No functional changes, just dead code cleanup.
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260526125521.594479-1-andrzej.kacprowski@linux.intel.com
Introduce a rwsem for protecting `ec_dev` to prevent Use-After-Free on
the `ec_dev`.
- Writers: In driver's probe() and remove().
- Readers: In file operations.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-5-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
For the purposes of memory bandwidth calculations tile4
should not be considered the same as tileY. Make it so.
This should not actually change anything as the affected
code only applies to pre-MTL integrated GPUs, which don't
have tile4.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-11-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Remove the deinterleave fallback calculation from the TGL+ codepath.
The fallback is using the ICL deinterleave calculation which was never
in the TGL+ algorithm. All supported memory types have the correct
deinterleave already specified for TGL+ anyway, so this is dead code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-10-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Bspec asks us to round down instead of closest doing the /100 for
the PM demand bandwidth. Make it so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-9-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
We have several copies of the same memory peak bandwidth calculations,
and the rounding directions are all over the place in some of them.
Unify it all into one small function (with rounding matching what Bspec
says).
Note that 'channel_width' is always a multiple of 8 anyway, so for
'channel_width / 8' the rounding direction doesn't actually matter.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-8-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
DEPROGBWPCLIMIT is specified in %, so divide by 100 instead of 10.
Fortunately the deprobbwlimit is much lower than the peak memory
bandwidth on BMG, so whether we take 60% or 600% of the peak
bandwidth doesn't matter as the min() will pick the lower
deprobbwlimit anyway.
Eg. on the BMG here I get (with or without the fix):
QGV 0: deratedbw=33600 peakbw=48000
QGV 1: deratedbw=53000 peakbw=456000
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-7-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
The '8/num_channels' in the clperchgroup is supposed to be rounded
down according to the spec. Make it so.
Not sure we can ever actually have a non-power of two number of
channels, so this might not matter.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-6-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
For some reason we're rounding up when calculating the deinterleave
value. But the spec says we should round down. Fix it.
But I suppose this doesn't actually matter since the deinterleave
values should always be power of two. The only exception is therefore
the deinterleave==1 case, which gets handled by the max(..., 1).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-5-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
The DRAM bandwidth value should be rounded down, not up.
Bspec: 64631
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-4-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Fix up the total mess when calculating the DCLK
frequency. Some codepaths are trying to do both DIV_ROUND_UP()
and an open coded "round to nearest" at the same time. The
MTL+ codepath was the only one that was correct (using
DIV_ROUND_CLOSEST()).
Let's unify all of them, and borrow the actual '100/6'
approach from adl_calc_psf_bw() so that we get even less
rounding errors.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-3-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The TGL+ bw code has an off by one error on the num_planes
calculation, and tgl_max_bw_index() incorrectly bumps
the num_planes to 1 from 0.
That approach made sense on ICL where num_planes is more or
less a minimum number of planes to consider for the group,
but on TGL+ num_planes really is a maximum number of planes,
so these adjustments no longer make any sense there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260522200346.17377-2-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Introduce an event relayer mechanism. Instead of each open file
registering directly with `ec_dev->event_notifier`, the platform device
registers a single relayer notifier. Individual files then register
with a local subscribers list in `chardev_pdata`.
This allows the driver to safely disconnect from the event chain
`ec_dev->event_notifier` during cros_ec_chardev_remove(), preventing
events from being delivered to open files after the device is removed,
while still allowing those files to be closed safely later.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-4-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Move `ec_dev` and `cmd_offset` from `chardev_priv` to `chardev_pdata` as
they are per-device properties but not per-open-file properties.
Hold a reference to `chardev_pdata` for each open file to ensure the
data remains valid even if the underlying platform device is removed.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-3-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Introduce struct chardev_pdata to hold platform driver data.
The platform driver data is allocated by kzalloc() instead of devm
variant, allowing for managed cleanup that can eventually extend beyond
device removal if files are still open.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20260525052654.4076429-2-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
ipv6_rpl_srh_decompress() computes:
outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);
hdrlen is __u8. For n >= 127 the result exceeds 255 and silently
truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):
(128 * 16) >> 3 = 256, truncated to 0 as __u8
The caller in ipv6_rpl_srh_rcv() then places the compressed header
at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8,
but the decompressed region occupies buf[0..2055] (8-byte header
plus 128 full addresses). The compressed header overlaps the
decompressed data, and ipv6_rpl_srh_compress() writes into this
overlap, corrupting the routing header of the forwarded packet.
The existing guard at exthdrs.c:546 checks (n + 1) > 255, which
prevents n+1 from overflowing unsigned char (the segments_left
field), but does not prevent the computed hdrlen from overflowing
__u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not
fit.
Tighten the bound to (n + 1) > 127. This caps n at 126, giving
hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed
header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly
past the decompressed region (buf[0..2039]). No overlap. 127
segments is well beyond any realistic RPL deployment.
Fixes: 8610c7c6e3 ("net: ipv6: add support for rpl sr exthdr")
Signed-off-by: Rahul Chandelkar <rc@rexion.ai>
Link: https://patch.msgid.link/20260525154031.2290876-1-rc@rexion.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that KVM correctly handles Host-Only and Guest-Only bits in the
event selector MSRs, allow the guest to set them if the vCPU advertises
SVM and uses the mediated PMU.
Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260527234711.4175166-14-yosry@kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>