| Age | Commit message (Collapse) | Author |
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB serial fixes for 7.2-rc4
Here are some fixes for 7.2:
- fix data loss on keyspan_pda throttle
- fix memory corruption with malicious edgeport devices
- fix memory corruption with corrupt io_ti firmware
- fix OOB read with corrupt mxuport firmware
Included are also some new ftdi and modem device ids.
All have been in linux-next with no reported issues.
* tag 'usb-serial-7.2-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: io_edgeport: cap received transmit credits
USB: serial: option: add TDTECH MT5710-CN
USB: serial: io_ti: reject oversized boot-mode firmware
USB: serial: mxuport: validate firmware header size
USB: serial: ftdi_sio: add support for E+H FXA291
USB: serial: keyspan_pda: fix data loss on receive throttling
|
|
msm_iommu_probe() adds its devm-managed IOMMU object to
qcom_iommu_devices before adding the IOMMU sysfs device and registering
it with the IOMMU core.
If iommu_device_sysfs_add() fails, probe returns with the object still on
qcom_iommu_devices. The driver core then releases the devm allocation,
leaving a dangling list entry that later list walks may dereference.
If iommu_device_register() fails, the same dangling list entry remains
and the sysfs device is left registered as well.
Unwind the sysfs device and global list entry in reverse setup order on
the corresponding failure paths.
Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface")
Cc: stable@vger.kernel.org
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The OF translation path appends each unique stream ID from an IOMMU
specifier to the fixed mids array in the per-master object. It currently
has no capacity check before storing at mids[num_mids] and incrementing
num_mids.
Return -ENOSPC when the array is full rather than writing the next ID
beyond it.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
subdevice ID
The WCN6855 and WCN7851 combo chips are available in M.2 card variants
that differ by their BT interface: some expose BT over UART while others
expose BT over USB. Both variants use the same PCIe device ID for the
WiFi interface, distinguished only by their sub-system device ID.
The bare PCI_DEVICE() entries match all sub-system IDs, so both UART and
USB variants hit the same table entry and trigger UART serdev creation.
For USB variants this is wrong — there is no UART BT interface on such
a card, and the serdev probe will fail.
Narrow the matches to UART variants only by using PCI_DEVICE_SUB with
their respective sub-system IDs, so USB variants no longer trigger
UART serdev creation.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add support for querying and switching the graphics MUX mode on HP
systems via WMI. This introduces the 'gpu_mux_mode' sysfs attribute
under the hp-wmi platform device, allowing userspace tools to check
and safely switch between available graphics modes (e.g., UMA, Hybrid,
Discrete).
The hardware capabilities mask is primarily read using the modern
128-byte System Design Data query. However, to ensure backward
compatibility with older models, a fallback mechanism is implemented.
By mirroring the behavior of the Windows Omen Gaming Hub software, if
the modern query fails but the MUX WMI endpoint (0x52) responds
successfully to a read request, the driver defaults to a standard
Hybrid + Discrete support mask (0x06).
Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev>
Link: https://patch.msgid.link/20260723172734.18361-1-hello@kursatabayli.dev
[ij: add kstrtox.h]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
From xe2_lpd+ platforms, enabling FBC do not depend on the
surface size. So remove the check.
v2: changes to patch description
Bspec: 69560
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-3-vinod.govindapillai@intel.com
|
|
In xe2_lpd+ platforms, there are no restrictions to enable FBC
on planes with respect to the plane width - width can be as per
the platform's maximum supported resolution.
v2: patches squashed and changes in patch descriptions
Bspec: 69560
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-2-vinod.govindapillai@intel.com
|
|
Enabling features like FBC on platforms may depend on a plane's
maximum supported resolutions or some other arbitrary constant
values because of hw restrictions. Currently the helpers that
report a plane's max width and height are private to skl_plane
/ skl_universal_plane. Change the scope to golbal so that
this can be queried from other areas as well.
v2: function parameter alignment fixes
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-1-vinod.govindapillai@intel.com
|
|
On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a
very high chance (>90%) of causing the EC to lose the previous backlight
power state. When this happens, the laptop resumes normally from S3, but
the backlight remains off (when shining on the screen with a flash light,
we can see the screen contents are updating normally).
Since there is no generic way to query the EC's backlight state on
Loongson laptop platforms, assume the worst-case scenario and restart
the backlight power inside the kernel each time the system resumes.
Cc: stable@vger.kernel.org
Fixes: 53c762b47f72 ("platform/loongarch: laptop: Add backlight power control support")
Tested-by: Yao Zi <me@ziyao.cc>
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Zixing Liu <liushuyu@aosc.io>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The driver populates acpi_device_class() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically for
this purpose.
No intentional functional impact.
This change will facilitate the removal of "device_class" from "struct
acpi_device_pnp" in the future.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
drm-misc-fixes for v7.2-rc5:
- Improve damage handling in appletbdrm.
- Fix harmful fragmenting of MM by backing up TTM pages at native
page order.
- Fix timeout handling in amdxdna.
- Fix imagination locking for map/unmap operations.
- Fix mm leak in gpusvm eviction.
- Properly zero page array in gpusvm mm scanning.
- Prevent trusted shader bo's from being mapped again in vc4.
- Validate shader array size in vmwgfx.
- Fix length calculation bugs in ethosu.
- Better error handling during pagemap migration.
- Improve v3d suspend.
- Kconfig updates for some panels.
- Handle missing iovcc in ili9881c panel.
- Fix vc4 unbind.
- Add i2c error handling in gma500.
- Fix kunit tests on pp64le and s390x.
- Prevent rearming vc4 timer on shutdown.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/07284633-6b9b-40f9-8949-b1516a42a34c@linux.intel.com
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Message-ID: <20260722023523.42269-2-panchuang@vivo.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Message-ID: <20260704122324.80274-1-pengpeng@iscas.ac.cn>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Message-ID: <20260704121851.63805-1-pengpeng@iscas.ac.cn>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The pvr_job_create tracepoint was using pvr_fw_object::fw_addr_offset
to display the firmware address of the render target structure attached
to a job, but that's an offset into the firmware heap, not the expected
full address, which is more useful in general e.g. for cross referencing
against firmware logs.
Use pvr_fw_object_get_fw_addr() to get the full firmware address.
Fixes: c1079aebb4de ("drm/imagination: Add support for trace points")
Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Link: https://patch.msgid.link/20260720-fix-pvr-job-trace-hwrt-v1-1-b24551802efb@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
Support for this GPU is now in a very good state, with only a handful of
Vulkan CTS tests still failing when testing using CTS version 1.4.5.3 on
the BeagleV-Ahead SBC. With the firmware having been upstreamed [1], now
is the time to promote this GPU from experimental to supported.
[1] https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1138
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-2-39abcd1cf263@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
The list of supported GPUs contains the GPU model, along with the SoCs
they're found in. The SoC information can easily get out of date, as
typically GPU models will be integrated into many different SoCs and
upstream support for these can potentially happen over a long stretch
of time without necessarily requiring any GPU driver changes.
Replace the SoC information with the BVNC instead. This uniquely identifies
a GPU implementation and is useful in cases where a GPU model may have
multiple implementations due to, e.g. hardware errata having been fixed,
and the driver doesn't yet support all of them.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-1-39abcd1cf263@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
The TVE200 DRM driver can be built as a module and uses tve200_of_match
as its OF match table, but the table is not exported for module alias
generation.
Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF
module aliases for OF based module autoloading.
Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn
|
|
CONFIG_ARCH_ENABLE_THP_MIGRATION"
This reverts commit 04b177544a040cbafab760d6b766381c6b22e0a8.
The original author requested it to be reverted, as it conflicts with
changes in the -next branch for MM:
"I'm not sure who is doing the drm-misc-fixes PR, but if you are can
you omit this patch: https://patchwork.freedesktop.org/series/170865/
I guess this conflicts with MM changes in their next tree and it easy
enough on our side to do this slightly differently to avoid a conflict
so going to post revert + a different change. If this is already sent nbd."
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its
DSC max FRL rate whenever the sink supports DSC 1.2.
However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies
to compressed video transport, which requires a DSC 1.2 encoder in
the PCON (configured via intel_dp_pcon_dsc_configure()).
Without such an encoder the HDMI link always carries uncompressed
video, for which the regular Max_FRL_Rate is the correct limit.
Applying the DSC limit unconditionally trains the FRL link at a lower
rate than both the PCON and the sink support.
E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps)
behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC
encoder):
Sink max rate from EDID = 24 Gbps
FRL trained with : 24 Gbps
while Windows/macOS train the same hardware at 40/48 Gbps.
The too low FRL rate needlessly constrains the formats available to
the sink.
Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2
encoder, matching the gate in intel_dp_pcon_dsc_configure().
PCONs with a DSC encoder keep the current conservative behavior,
since the link is trained once and compressed transport may be used
for any subsequent mode.
With this the setup above trains at 48 Gbps.
Tested on PTL (xe) with the above PCON/sink combo.
Fixes: 10fec80b48c5 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de
|
|
For modes which fit through the link uncompressed only with a 6 bpc
pipe BPP, the link config currently selects 6 bpc with dithering even
if the sink supports DSC.
For HDMI sinks behind a DP to HDMI protocol converter this is the
wrong preference: HDMI knows no 6 bpc transport format, so the
converter has to expand the dithered 6 bpc stream back to 8 bpc for
the HDMI link anyway, and DSC with an at least 8 bpc input provides
a better output quality than that.
Prefer DSC, following the pattern commit ba49a4643cf5 ("drm/i915/dp:
Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the
uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC,
making the uncompressed link config fail for such modes and the mode
fall back to DSC.
As there, if the DSC computation fails, the mode falls back to YCbCr
4:2:0 where supported, or gets rejected.
Besides the output quality, some converters can't even display a
6 bpc stream at high pixel clocks.
Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device
families (branch device IDs SYNAq and SYNAa) output corrupted FRL
timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream,
resulting in a black screen, while the same mode works with DSC
(12 bpc input) and 6 bpc works at lower pixel clocks.
Windows and macOS drive 4k120 on these devices only via DSC.
A lower bpc limit explicitly requested via the max bpc connector
property is still honored.
This keeps the current uAPI behavior (exercised by IGT kms_dither)
and provides an escape hatch for sinks with a broken DSC
implementation.
DP and eDP sinks, and HDMI sinks without DSC support, are not
affected and keep falling back to 6 bpc.
Tested on PTL (xe) with the above PCONs and an LG OLED G4.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260718105207.5565-2-alexander.kaplan@sms-medipool.de
|
|
The RTL8822CE on the ASUS TUF Gaming A15 FA506II wedges during normal
use. The driver watchdog toggles PCIe ASPM while leaving power save;
the DBI read of the ASPM link-config register fails with -EIO, the PCIe
link becomes unstable, and the device drops off the bus, taking Wi-Fi
down until a cold power cycle:
rtw88_8822ce 0000:03:00.0: failed to read ASPM, ret=-5
rtw88_8822ce 0000:03:00.0: firmware failed to leave lps state
rtw88_8822ce 0000:03:00.0: mac power on failed
This is the same platform ASPM inter-operability problem already
handled for other machines through rtw_pci_quirks[]. Disabling PCI
ASPM and deep power save on this model stops the failure. Add a DMI
quirk so the workaround is applied automatically.
Signed-off-by: Mihail Dimoski <mihaildimoski@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260718124045.23493-1-mihaildimoski@gmail.com
|
|
Newer firmware is using the new TLV-Header format, without this patch
it will lead driver run into length mismatch state.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-14-pkshih@realtek.com
|
|
The structure active_role which describes the using Wi-Fi role format is
different with the exist v1. Add branch to cover the difference.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-13-pkshih@realtek.com
|
|
The exists version 5 format has FDDT(frequency divided training) related
information. But the feature wasn't support for RTL8852C now, so firmware
will not send the related reference value.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-12-pkshih@realtek.com
|
|
Slots structure version 2 uses new TLV-Header to package slots information,
patch related entry for version 2.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-11-pkshih@realtek.com
|
|
TDMA version 4 uses new TLV-Header to package TDMA information,
patch related entry for version 4.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-10-pkshih@realtek.com
|
|
The new firmware modified GPIO setup structure format for third party
chip set I/O control & offloaded Wi-Fi TRX status to firmware for training
traffic RF-Parameters & TDMA mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-9-pkshih@realtek.com
|
|
The function to filled up H2C command data is the last step in the driver,
the next step is going to firmware. So the structure version number should
not included driver local branch number (like firmware is v5, but driver
branch to v105), it should be assigned as a explicit version number which
paired with firmware.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-8-pkshih@realtek.com
|
|
The 0.29.133.X firmware driver info H2C index maximum is 5, to prevent
switch case fall through and send unexpected H2C commands, add version
code 103 as judgment.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-7-pkshih@realtek.com
|
|
Due to the firmware version become more and more, the version divided
branch coding method make the related code scattered everywhere, and
too much version macro, rearrange the code, assign the value to version
format only when H2C commands.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-6-pkshih@realtek.com
|
|
RTL8852B in firmware 0.29.133.X do not support BT-TX-PWR report, re-index
and branch out to version 105.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-5-pkshih@realtek.com
|
|
The C2H report is for knowing what the grant-signal setting is now,
not for applying new grant-signal setting.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-4-pkshih@realtek.com
|
|
WiFi firmware will save its build date/time and package into C2H event then
send to driver. It helps to analyze what kind of firmware was loaded now.
Remove unnecessary memory set.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-3-pkshih@realtek.com
|
|
The previous version 7 format is for Dual-Bluetooth using. This patch
is for single Bluetooth solution using. Driver will summary Wi-Fi now
status for firmware to train RF parameters & TDMA mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-2-pkshih@realtek.com
|
|
The CFR (Channel Frequency Response) manual mode condition for 2GHz is
missing to limit on bandwidth for specific channels, which are channel
13 with 20MHz bandwidth and channel 11 with 40MHz bandwidth. Also add
a band check to avoid affecting 5GHz/6GHz bands.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-10-pkshih@realtek.com
|
|
To improve initial time, merge some IO to reduce IO times. Two registers
are:
1. R_BE_SYS_PW_CTRL: 0x4[12:11]=0, 0x4[18]=1, 0x4[15]=0, and 0x4[10]=0
2. R_BE_SYS_ADIE_PAD_PWR_CTRL: Merge 0x18[6] and 0x18[5]
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-9-pkshih@realtek.com
|
|
Set TS1 (training sequence 1) to 1024 when PCIe enters recovery state to
improve RF interference while entering and leaving L1ss.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-8-pkshih@realtek.com
|
|
With original timeout unit, it might trigger SER false alarm causing
WiFi card lost. Extend timeout unit to avoid wrong SER.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-7-pkshih@realtek.com
|
|
When connected to an AP and a scan is triggered, the FW may fail to
transmit probe request because switching channels may load an
uninitialized TXIQK table. Therefore, bypass TXIQK during scanning
to avoid using invalid calibration values.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-6-pkshih@realtek.com
|
|
TX IQK is a RF calibration, the v1 format adds a field for the thermal
re-calibration parameter for RTL8922D after FW 0.35.113.0. Update the
format accordingly.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-5-pkshih@realtek.com
|
|
Add RTW89_QUIRK_DISABLE_2GHZ to the rtw89_quirks enum to allow
per-device suppression of the 2.4 GHz band.
Apply the quirk only for the 0x28de:0x2432 (VID:PID) USB device,
which operates only in 5/6 GHz bands.
Signed-off-by: David Lee <sc.lee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-4-pkshih@realtek.com
|
|
Add multicolor LED support for the RTL8852CU valve board to reflect
wireless connection status (by default, green LED is ON when associated
and OFF when disconnected).
Extend the rtw89 LED subsystem with a multicolor path via led_classdev_mc,
for board-level variants with more than one LED GPIO channel.
Add a new RTW89_LEDS_MC Kconfig option and support multicolor LEDs
through led_classdev_mc, with per-channel caching to minimize
redundant register writes. The RTL8852CU valve board is wired up as
the first user, driving a multicolor WRGB LED over four GPIO channels
(8, 18, 16, and 17) that map to LED_COLOR_ID_WHITE/RED/GREEN/BLUE.
Usage:
- Auto-triggered (default):
Green LED ON when connected, OFF when disconnected
- Manual override (e.g., set red; channel order: WHITE RED GREEN BLUE):
echo "0 1 0 0" > /sys/class/leds/rtw89-phyX-multicolor/multi_intensity
echo 1 > /sys/class/leds/rtw89-phyX-multicolor/brightness
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-3-pkshih@realtek.com
|
|
Add a new RTW89_LEDS Kconfig option, along with LED structures to describe
flexible GPIO mappings for chip common LED definition. Core LED lifecycle
and registration logic default to the mac80211 association trigger, and
chips are wired up as the first user with a single-GPIO monochrome LED.
Usage:
- Auto-triggered (default):
ON when connected, OFF when disconnected
- Manual override:
echo <1|0> > /sys/class/leds/rtw89-phyX/brightness
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-2-pkshih@realtek.com
|
|
The Spacemit K3 Pico ITX Board has a RTL8852BE pcie card behind a PCIe
root port, but the SoC doesn't have any 32 bit DMA addreseses which the
rtw89 seems to use by default. Enable 36 bit DMA ability that the driver
has when this particular root port is detected so that the driver can
probe on this SoC.
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260716-rtw89-spacemit-k3-v2-2-392b577ebf75@oss.tenstorrent.com
|
|
Move the vendor and device ID for the existing Spacemit K1 PCIe Root
Complex to include/linux/pci_ids.h. Also add K3's Root Complex device ID
to this header. This is done so that these values can be referenced in
the rtw89 driver to enable 36-bit DMA ability in it for WiFi to function
on the K3 Pico ITX board.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260716-rtw89-spacemit-k3-v2-1-392b577ebf75@oss.tenstorrent.com
|
|
Change personal email to the Linux specific one,
to have a single and focused point of interaction.
Signed-off-by: Siratul Islam <siratul.islam@linux.dev>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/linux-iio/a509d034-de90-4e46-bd7e-75f61002d6ba@kernel.org/
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Since commit
55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"),
devm_request_threaded_irq() automatically logs detailed error messages
on failure. Remove the now-redundant driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Period measurement can be difficult when using high sampling
frequency where the jitter criteria is hard to meet because of the
system jitter.
This new version is using the delta time between 2 distant interrupts
to measure an interval of at least 20ms. 20ms is a good compromise
between the mitigation of system jitter and the delay to update
period. This way we decorrelate the period measurement from the
interrupt timestamps syncing using only the 2 last interrupts.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Current interrupt timestamp alignment only changes the final timestamp.
When the watermark is in use, we have a batch of samples for each
interrupt. The current code doesn't manage to align the timestamp
because the jitter is too high.
Instead modify the estimated inter interrupt period and use that to
adjust the timestamp alignment over the batch in a linear fashion.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|