Age | Commit message (Collapse) | Author | Files | Lines |
|
Split out PHY detection into lan78xx_get_phy() and MAC-side setup into
lan78xx_mac_prepare_for_phy(), making the main lan78xx_phy_init() cleaner
and easier to follow.
This improves separation of concerns and prepares the code for a future
transition to phylink. Fixed PHY registration and interface selection
are now handled in lan78xx_get_phy(), while MAC-side delay configuration
is done in lan78xx_mac_prepare_for_phy().
The fixed PHY fallback is preserved for setups like EVB-KSZ9897-1,
where LAN7801 connects directly to a KSZ switch without a standard PHY
or device tree support.
No functional changes intended.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
RGMII timing correctness relies on the PHY providing internal delays.
This is typically ensured via PHY driver, strap pins, or PCB layout.
Explicitly checking for a PHY driver here is unnecessary and non-standard.
This logic applies to all MACs, not just LAN78xx, and should be left to
phylib, phylink, or platform configuration.
Drop the check and rely on standard subsystem behavior.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Ensure that return values from `lan78xx_write_reg()`,
`lan78xx_read_reg()`, and `phy_find_first()` are properly checked and
propagated. Use `ERR_PTR(ret)` for error reporting in
`lan7801_phy_init()` and replace `-EIO` with `-ENODEV` where appropriate
to provide more accurate error codes.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state
of zpci_dev's") the code to ignore power off of a PF that has child VFs
was changed from a direct return to a goto to the unlock and
pci_dev_put() section. The change however left the existing pci_dev_put()
untouched resulting in a doubple put. This can subsequently cause a use
after free if the struct pci_dev is released in an unexpected state.
Fix this by removing the extra pci_dev_put().
Cc: stable@vger.kernel.org
Fixes: bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's")
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "struct i915_wa *". The returned type, while
technically matching, will be const qualified. As there is no general
way to remove const qualifiers, adjust the allocation type to match
the assignment.
Signed-off-by: Kees Cook <kees@kernel.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250426061357.work.749-kees@kernel.org
|
|
This serves as specification for both, PWM consumers and the respective
callback for lowlevel drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/d2916bfa70274961ded26b07ab6998c36b90e69a.1746010245.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
While telling the caller of pwm_set_waveform_might_sleep() if the
request was completed by rounding down only or (some) rounding up gives
additional information, it makes usage this function needlessly hard and
the additional information is not used. A prove for that is that
currently both users of this function just pass the returned value up to
their caller even though a positive value isn't intended there.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/528cc3bbd9e35dea8646b1bcc0fbfe6c498bb4ed.1746010245.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
Up to now pwm_set_waveform_might_sleep() returned 1 for exact requests
that couldn't be served exactly. In contrast to
pwm_round_waveform_might_sleep() and pwm_set_waveform_might_sleep() with
exact = false this is an error condition. So simplify handling for
callers of pwm_set_waveform_might_sleep() by returning -EDOM instead of
1 in this case.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20538a46719584dafd8a1395c886780a97dcdf79.1746010245.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
Octo Memory Manager driver (OMM) manages:
- the muxing between 2 OSPI busses and 2 output ports.
There are 4 possible muxing configurations:
- direct mode (no multiplexing): OSPI1 output is on port 1 and OSPI2
output is on port 2
- OSPI1 and OSPI2 are multiplexed over the same output port 1
- swapped mode (no multiplexing), OSPI1 output is on port 2,
OSPI2 output is on port 1
- OSPI1 and OSPI2 are multiplexed over the same output port 2
- the split of the memory area shared between the 2 OSPI instances.
- chip select selection override.
- the time between 2 transactions in multiplexed mode.
- check firewall access.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20250428-upstream_ospi_v6-v11-2-1548736fd9d2@foss.st.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
With MMIO logging enabled, the MMIO access are traced and could be
sent to an STM device. Thus, an STM driver MMIO access could create
circular call chain with MMIO logging. Disable it for STM driver.
[] stm_source_write[stm_core]+0xc4
[] stm_ftrace_write[stm_ftrace]+0x40
[] trace_event_buffer_commit+0x238
[] trace_event_raw_event_rwmmio_rw_template+0x8c
[] log_post_write_mmio+0xb4
[] writel_relaxed[coresight_stm]+0x80
[] stm_generic_packet[coresight_stm]+0x1a8
[] stm_data_write[stm_core]+0x78
[] stm_source_write[stm_core]+0x7c
[] stm_ftrace_write[stm_ftrace]+0x40
[] trace_event_buffer_commit+0x238
[] trace_event_raw_event_rwmmio_read+0x84
[] log_read_mmio+0xac
[] readl_relaxed[coresight_tmc]+0x50
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20250506075743.1398257-1-quic_jinlmao@quicinc.com
|
|
On platforms with a static replicator, a kernel panic occurs during boot:
[ 4.999406] replicator_probe+0x1f8/0x360
[ 5.003455] replicator_platform_probe+0x64/0xd8
[ 5.008115] platform_probe+0x70/0xf0
[ 5.011812] really_probe+0xc4/0x2a8
[ 5.015417] __driver_probe_device+0x80/0x140
[ 5.019813] driver_probe_device+0xe4/0x170
[ 5.024032] __driver_attach+0x9c/0x1b0
[ 5.027900] bus_for_each_dev+0x7c/0xe8
[ 5.031769] driver_attach+0x2c/0x40
[ 5.035373] bus_add_driver+0xec/0x218
[ 5.039154] driver_register+0x68/0x138
[ 5.043023] __platform_driver_register+0x2c/0x40
[ 5.047771] coresight_init_driver+0x4c/0xe0
[ 5.052079] replicator_init+0x30/0x48
[ 5.055865] do_one_initcall+0x4c/0x280
[ 5.059736] kernel_init_freeable+0x1ec/0x3c8
[ 5.064134] kernel_init+0x28/0x1f0
[ 5.067655] ret_from_fork+0x10/0x20
A static replicator doesn't have registers, so accessing the claim
register results in a NULL pointer deference. Fixes the issue by
accessing the claim registers only after the I/O resource has been
successfully mapped.
Fixes: 7cd6368657f1 ("coresight: Clear self hosted claim tag on probe")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20250502111108.2726217-1-leo.yan@arm.com
|
|
Observe that i915->irq_lock is no longer used to protect anything
outside of display. Make it a display thing.
This allows us to remove the ugly #define irq_lock irq.lock hack from xe
compat header.
Note that this is slightly more subtle than it first looks. For i915,
there's no functional change here. The lock is moved. However, for xe,
we'll now have *two* locks, xe->irq.lock and display->irq.lock. These
should protect different things, though. Indeed, nesting in the past
would've lead to a deadlock because they were the same lock.
With the i915 references gone, we can make a handful more files
independent of i915_drv.h.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/6d8d2ce0f34a9c7361a5e2fcf96bb32a34c57e76.1746536745.git.jani.nikula@intel.com
[Jani: Fixed a comment while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Make the gt rps code and display irq code interact via
intel_display_rps.[ch], instead of direct access. Add no-op static
inline stubs for xe instead of having a separate build unit doing
nothing. All of this clarifies the interfaces between i915 core and
display.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/ef2a46dc8f30b72282494f54e98cb5fed7523b58.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With all users of i915_enable_asle_pipestat() inside
intel_display_irq.c, we can make the function static.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/9511e368c5244aaa04cc45f46e2425737acd29fb.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Split out i965_display_irq_postinstall() similar to other platforms.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/5d404dcd0c606d1cb11f2e09c45e151a75b5b2c6.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Split out i915_display_irq_postinstall() similar to other platforms.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/11de06206ff10c27104b0ac3efda085bf4c1f1a6.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
All users of vlv_display_irq_postinstall() outside of
intel_display_irq.c have a lock/unlock pair. Move the locking inside the
function. Add an unlocked variant for internal use, similar to the
_vlv_display_irq_reset() and vlv_display_irq_reset() functions.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/93ea785d2d9bdb4e18328aa42a00a492d9d783c0.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
All users of valleyview_enable_display_irqs() and
valleyview_disable_display_irqs() have a lock/unlock pair. Move the
locking inside the functions.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/bb6d941c47260aea11e4af5d52572b0e5f139929.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
All users of vlv_display_irq_reset() have a lock/unlock pair. Move the
locking inside the function.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/0f8176b777fa24921458996f7d6f982f955a52f6.1746536745.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The original nvme subsystem design didn't have a CONNECTING state; the
state machine allowed transitions from RESETTING to LIVE directly.
With the introduction of nvme fabrics the CONNECTING state was
introduce. Over time the nvme-pci started to use the CONNECTING state as
well.
Eventually, a bug fix for the nvme-fc started to depend that the only
valid transition to LIVE was from CONNECTING. Though this change didn't
update the firmware update handler which was still depending on
RESETTING to LIVE transition.
The simplest way to address it for the time being is to switch into
CONNECTING state before going to LIVE state.
Fixes: d2fe192348f9 ("nvme: only allow entering LIVE from CONNECTING state")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Daniel Wagner <wagi@kernel.org>
Closes: https://lore.kernel.org/all/0134ea15-8d5f-41f7-9e9a-d7e6d82accaa@roeck-us.net
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
|
|
Drop another reference to struct drm_i915_private.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/cb84073ff92a99e74ff6dfb8e395365b7cbb5332.1746529001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
struct intel_vbt_data is within struct intel_display nowadays, not
struct drm_i915_private.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/b7a9a7c64f41cf61749a42ed4102e04b500fde83.1746529001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Remove unused struct drm_i915_private forward declaration from
intel_display_core.h. Sort and group forward declarations while at it.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/fbccf45339a61711b377b35fd479a67b378c5571.1746529001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Remove final references to struct drm_i915_private and drop dependency
on i915_drv.h.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/2cee3cd9d7d9bec8dfe9c21fe5d172b1843b3d97.1746529001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Documentation/filesystems/sysfs.rst mentions that show() should only
use sysfs_emit() or sysfs_emit_at() when formating the value to be
returned to user space. So replace scnprintf() with sysfs_emit().
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Link: https://lore.kernel.org/r/aBkw_p9GkH2fm2UJ@pc
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
I put devlist.h into the wrong Makefile macro ("obj") to get it included
in "targets". Put it into "always" so nothing tries to link against it.
Solves CONFIG_EISA=y i386 build failure:
ld: vmlinux.a: member drivers/eisa/devlist.h in archive is not an object
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/all/4a8ba1d0-d2d9-41f8-abf1-d45ec8996d10@infradead.org
Fixes: dd09eb0e2cc4 ("EISA: Increase length of device names")
Signed-off-by: Kees Cook <kees@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20250423023743.work.350-kees@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For UHR, a version 3 of the rate API is being added, which
increases the number of bits used for MCSes by shifting the
NSS bit up. Handle that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.84cde65a603f.Ic3119ef77cbc6461abd2a6bda104c0d236adcc8d@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Add RFI_CONFIG_CMD into the names array to facilitate the
display of this command name when sending it to the firmware.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Link: https://patch.msgid.link/20250505215513.da89484cb838.I755709232f5e441ca159bdc5a151bac73d9744d3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
That mask should never have been 0xFFFF (mask also doesn't
make sense in that case) but rather 0xF000 since I combined
a few entries with 0xC___.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.63bdbd67b72d.Id9b93b695c91117967dfd339c76bdfcd2872bee6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This sets both fwrt->uats_valid and returns 0, but in the
static inline it returns 0 without setting uats_valid,
which is confusing and the iwlmvm code misbehaves in this
case.
Since it already sets uats_valid, just remove the extra
return value.
Reported-by: Bjoern A. Zeeb <bz@FreeBSD.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.e981a7911228.Ic94b5e03e2053a08b84cabeb58ce3b6598fd9fc6@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This RF module is now a product. No need to support the test chip
anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.01fb866e7c38.I23611aa4abb8fd031a6d63a21f4b87b0d38a36a1@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This is a new RF module and of course the firmware name for this new RF
module is different.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.c3481b1a4124.Id94c680636be2f59c9172919c79d80a48c7d1322@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
In order to set the CDB indication in the dump meta data, we read it from
a specific prph register.
There is a known issue with that register in Xnj setups - in that case it
will always indicate CDB.
Instead of detecting the jacket case and then hardcode whether the CDB
indication should or shouldn't be set (according the CRF),
we can retrieve the CDB bit from the hw_rf_id (CSR_HW_RF_ID).
There is also no reason to do it conditionally only for ax210 / BnJ.
Cleanup the code a bit.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.ea542a6c189e.I3d8cf5103b3747dfdd89985b45b592e419f97b63@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The beacon CCK flag should be set for any CCK rate, not
just for 1 Mbps. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20250505215513.fe18b7d92d7d.I7bb40a92cea102677b695beb1e2a62a5ea72678b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This was used for debug/bringup of 8000 devices, to be able to
unify between all 8000 devices with NVM override. However, this
is really no longer used, those are ancient devices by now, so
we can remove the logic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.6210ac6cda09.I83cc3e68f0ed99a922d435c203fef840a28eb0de@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
These should be zero, but we might as well be explicit about it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215513.1e943bf696f4.Id2d7a413dc594c4525ac7ad0650ec8a50e1970ca@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Add a debugfs option to use the ptp clock time for Rx device
timestamps on a monitor interface. This can be useful for e.g.
synchronizing multiple NICs or reporting the timestamp in the
system clock instead of the GP2.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Link: https://patch.msgid.link/20250505215513.fffe6718fbca.I75f034005851a2d0c8ba5b015b9fdcad8a7c550d@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Currently, there are two log messages at INFO level for
synchronous commands:
Attempting to send sync command ...
Setting HCMD_ACTIVE for command ...
and unfortunately none at all for async ones. Add one
for async commands as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215512.cc4457285889.I633fae8828e8a37bbebc578166f388dcf893f592@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
If there is an ongoing scan that lasts long, the MPDU counters may not
increase enough due the device being busy with scanning and not
because we are in a low throughput scenario.
In that case we don't want to block EMLSR.
Instead, stop checking the counters from the moment we started
scanning, and when the scan ends - clear the counters and schedule a
check in 5 seconds, as usual.
Note that this is only done for regular scan since MLO scan is too short
to affect the counters, and scheduled scan is mainly used when we are
not connected.
Also note that we only stop checking whether to block EMLSR, and not if to
unblock.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215512.330ea440d19c.Ib10dae0b7a0cb0e10c59a9edf5ff7af0f065ac60@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
We have such a print for ACPI, add one for UEFI.
This is needed for testing
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215512.f419c18c064e.I870a4537a4bfa3c54b03ec7ec29bb246e6aa75cb@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
If there's a failure and the op-mode didn't actually fully
initialize, it should leave the transport again. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.714c3517548b.I49557e7ba8c03be2b558cc9fb5efa2a9fbab890e@changeid
|
|
There's no need to build a list of individual configs
first and then compare them, we can just go through all
of them and compare if the pointers aren't the same.
The complexity (in terms of number of comparisons) is a
bit higher that way, but it's just a test and the code
complexity is much lower without that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.85911c59d96a.I540f464229da3566d1726dfb61b46002fbb73bde@changeid
|
|
For Sc 97 might get used (at least for now) and for Dr
the older 96 won't get used. Change them both to 97.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.2ab49f2265ce.I45623943fdcac3462d96e54dbb7fdad68bdf3693@changeid
|
|
For different MACs we maintain the configs in different
files, and while it's a small waste of space, this is a
worthwhile trade-off for maintenance and simplicity. So
allow different MAC types to have the same config. This
could allow the same config for two MACs in the same MAC
family, but that's not hugely important. Also simplify
the test to not build a config list, there's no good
reason to do that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.27f5d570eb32.I1649309a0e54a1d446a38c5b2124a582de9f6d61@changeid
|
|
Start supporting API version 99 for those devices.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.677db25ce2c7.Ie4a7a00ff3562bfed1e8ac1fb42c1382cd24a486@changeid
|
|
No hardware that uses iwlmvm actually supports HT greenfield.
Remove the support and then clean up the v1 rate API by doing
a conversion to v2 rate API, the only thing v1 covered that
couldn't be done in v2 was HT greenfield.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.805ec090c61f.Iafd87f62ceb463b72f861a5348078999dcaace92@changeid
|
|
In EHT, we shouldn't report a legacy rate to mac80211, that
might just be confusing. Set it to zero, since it's only
really relevant for radiotap.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.325d7ba6905f.I3bdd8854e1a784856a4973ff4d532c74f992af00@changeid
|
|
In EHT, we shouldn't report a legacy rate to mac80211, that
might just be confusing. Set it to zero, since it's only
really relevant for radiotap.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.8baf4efec182.Idc0cabf1919c05b35dc2341c08ea88a7157614c4@changeid
|
|
Instead of building the injected rate in version 1 of the
format and then converting, build it in version 2 directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.0e6e4ae4469f.Ib49eda9a3083b2e0f0bcaff08ad784e151978307@changeid
|
|
The modulation type values aren't masks, they're just values.
Rename them from RATE_MCS_CCK_* to RATE_MCS_MOD_TYPE_*.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.aa79635dd4e6.Ie97a01fee1ef4aedf8a2e5447489793ce8c15ca0@changeid
|