| Age | Commit message (Collapse) | Author |
|---|
|
Successful driver probing should be silent. Drop unconditional
dev_info() call that is done at nmk_gpio_probe() exit.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260701-gpio-nomadik-silent-v1-5-644d10316cef@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
gpio-nomadik depends on a few resources. In one case the reset is taking
time to show up leading to a boot log containing:
[ 0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
Fix by replacing all dev_err() calls that might be made at probe with
dev_err_probe().
On nomadik platforms, the nmk_gpio_populate_chip() log calls might
attach their reasons to the gpio or pinctrl device depending on boot
order.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260701-gpio-nomadik-silent-v1-4-644d10316cef@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Now that all error codepaths in nmk_gpio_populate_chip() log an error,
drop dev_err() call that is made on nmk_gpio_populate_chip() failure.
Current boot log:
[ 0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
[ 0.544274] nomadik-gpio 1400000.gpio: could not populate nmk chip struct
The second line is always redundant (or is logged when we shouldn't log,
like ioremap or alloc failures).
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260701-gpio-nomadik-silent-v1-3-644d10316cef@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
All error paths of nmk_gpio_populate_chip() lead to logging errors but
this one (ignoring the alloc or ioremap failures that must not log).
Add the single missing dev_err() call.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260701-gpio-nomadik-silent-v1-2-644d10316cef@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Remove duplicate teardown code that is found in all error if
statements. Replace by goto-based cleanup labels.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260701-gpio-nomadik-silent-v1-1-644d10316cef@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
numa_register_meminfo() sets node_possible_map to numa_nodes_parsed. The
later assignment in numa_register_nodes() is therefore redundant, so remove
it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260703041329.2797584-9-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
numa_add_memblk() now sets the node in numa_nodes_parsed itself, so the
caller's own node_set() is redundant. Remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260703041329.2797584-6-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
numa_add_memblk() now sets the node in numa_nodes_parsed itself, so the
caller's own node_set() is redundant. Remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260703041329.2797584-4-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
numa_add_memblk() now sets the node in numa_nodes_parsed itself, so the
caller's own node_set() is redundant. Remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260703041329.2797584-3-ekffu200098@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux
Pull mod_devicetable.h header split from Uwe Kleine-König:
"Split <linux/mod_devicetable.h> in per subsystem headers
<linux/mod_devicetable.h> is included transitively in nearly every
driver in an x86_64 allmodconfig build of v7.1:
$ find drivers -name \*.o -not -name \*.mod.o | wc -l
21330
$ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
17038
The result of this mixture of different and unrelated subsystem
details is that even when touching an obscure device id struct most of
the kernel needs to be recompiled. Given that each driver typically
only needs one or two of these structures, splitting into per
subsystem headers and only including what is really needed reduces the
amount of needed recompilation.
This split is implemented in the first commit and then after some
preparatory work in the following commits, the last two replace
includes of <linux/mod_devicetable.h> by the actually needed more
specific headers.
There are still a few instances left, but the ones with high impact
(that is in headers that are used a lot) and the easy ones (.c files)
are handled. These remaining includes will be addressed during the
next merge window"
* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)
Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers)
parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h>
media: em28xx: Add include for struct usb_device_id
LoongArch: KVM: Add include defining struct cpu_feature
ALSA: hda/core: Add include defining struct hda_device_id
usb: dwc2: Add include defining struct pci_device_id
platform/x86: int3472: Add include defining struct dmi_system_id
platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
i2c: Let i2c-core.h include <linux/i2c.h>
of: Explicitly include <linux/types.h> and <linux/err.h>
platform/x86: msi-ec: Ensure dmi_system_id is defined
usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>
driver core: platform: Include header for struct platform_device_id
driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
media: ti: vpe: #include <linux/platform_device.h> explicitly
mod_devicetable.h: Split into per subsystem headers
|
|
otx2_init_hw_resources() initializes SQ aura and pool resources before
several later setup steps. On failure, err_free_sq_ptrs only frees SQB
pages, leaving the per-SQ sqb_ptrs arrays behind.
Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs
even when sq->sqe has not been allocated yet.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
OcteonTX2 PF device and the corresponding AF mailbox setup to test with,
no runtime testing was able to be performed.
Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues")
Cc: stable@vger.kernel.org
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Link: https://patch.msgid.link/20260630071625.349996-1-dawei.feng@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
apple_soc_cpufreq_init() adds OPP tables from firmware, but
some failure paths do not remove them. The driver also uses
dev_pm_opp_remove_all_dynamic(), which is not the right cleanup
helper for OPP tables loaded from firmware.
Use the cpumask OPP helper after the policy CPU mask has been
populated. Pair it with the matching cpumask remove helper on
failure paths and in apple_soc_cpufreq_exit(). This also removes
the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask
helper loads the DT OPP tables for all CPUs in the policy.
Fixes: 6286bbb40576 ("cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
For an even packet_len, net1080_rx_fixup() reads the pad byte at
skb->data[packet_len] before the skb->len != packet_len check further
down, and packet_len is only bounded against NC_MAX_PACKET. A malicious
NetChip 1080 device can send a short frame advertising a large even
packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the
skb:
BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup
Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14
...
net1080_rx_fixup (drivers/net/usb/net1080.c:384)
usbnet_bh (drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3708)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
...
Reject the frame when packet_len >= skb->len before reading.
Fixes: 904813cd8a0b ("[PATCH] USB: usbnet (4/9) module for net1080 cables")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260630045121.1565324-1-xmei5@asu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Set maple driver data before calling input_register_device() to
ensure that it is available if the device is opened immediately and
the callback is triggered.
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Set maple driver data before calling input_register_device() to
ensure that it is available if the device is opened immediately and
the callback is triggered.
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Tested-by: Florian Fuchs <fuchsfl@gmail.com>
Link: https://patch.msgid.link/akNYib9hQFNN1fA9@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Set maple driver data before calling input_register_device() to
ensure that it is available if the device is opened immediately and
the callback is triggered.
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Tested-by: Florian Fuchs <fuchsfl@gmail.com>
Link: https://patch.msgid.link/akNXw45L_8bxD6QV@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Cross-merge networking fixes after downstream PR (net-7.2-rc2).
No conflicts.
Adjacent changes:
MAINTAINERS:
56114690ff3c ("MAINTAINERS: Update Marvell octeontx2 driver maintainers")
eb56577ae9a5 ("ehea: remove the ehea driver")
net/core/netpoll.c:
45f1458a8501 ("netpoll: fix a use-after-free on shutdown path")
84c0ff1efb62 ("netpoll: do not warn when the best-effort pool refill fails")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
(headers)
<linux/mod_devicetable.h> is included in a many files:
$ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l
1598
; some of them are widely used headers. To stop mixing up different and
unrelated driver( type)s let the subsystem headers only use the subset
of the recently split <linux/mod_devicetable.h> that are relevant for
them.
The fallout (I hope) is addressed in the previous commits that handle
sources relying on e.g. <linux/i2c.h> pulling in the full legacy header
and thus providing pci_device_id.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Traditionally <linux/mod_devicetable.h> was a header defining a plethora
of structs, among them struct usb_device_id. This was split now with the
objective that only the relevant bits are included.
Currently <linux/mod_devicetable.h> is transitively included in
drivers/media/usb/em28xx/em28xx.h via:
drivers/media/usb/em28xx/em28xx.h ->
<linux/i2c.h> ->
<linux/acpi.h> ->
<linux/device.h> ->
<linux/device/driver.h> ->
<linux/mod_devicetable.h
To keep struct usb_device_id available once <linux/device/driver.h>
stops including <linux/mod_devicetable.h>, include it the header
providing that struct explictly.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/e72de5b4b9f1aa77a3c19a5e698a195dfd81ae0b.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Up to now <linux/acpi.h> includes <linux/mod_devicetable.h> that
provides struct pci_device_id. However <linux/mod_devicetable.h> was
split into per bus headers and <linux/acpi.h> will only include the acpi
related one (and similar for other bus headers).
As struct pci_device_id is used in drivers/usb/dwc2/core.h, add an
include to ensure it's defined also after the includes in <linux/acpi.h>
are tightened.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/bddfcdfaf36d735c244e03efada6083ef98ebd51.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Currently <linux/i2c.h> includes <linux/mod_devicetable.h> transitively
which ensures that struct dmi_system_id is defined in
drivers/platform/x86/x86-android-tablets/x86-android-tablets.h. However
this include in <linux/i2c.h> will be replaced by one for i2c_device_id
only. To ensure that dmi_system_id is available add the include for that
explicitly.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/32928d9ee47cefc7dfc4c385c06bd5e598b0fca1.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
The subsystem private header i2c-core.h uses several symbols defined in
<linux/i2c.h>, e.g. struct i2c_board_info and i2c_lock_bus()). This
doesn't pose a problem in practise because all files including
"i2c-core.h" also include <linux/i2c.h>.
To make this more robust add an include statement for <linux/i2c.h>
making the header self-contained.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/46aa85ab3dc4e63bfb5bd8ff1fd212a3d0e31f58.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Currently <linux/acpi.h> includes <linux/mod_devicetable.h> and thus
dmi_system_id is available for the driver. To disentangle includes
<linux/acpi.h> will be changed to only include the header for
acpi_device_id instead of the full <linux/mod_devicetable.h>. To prepare
for that include the dedicated header for struct dmi_device_id.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/600c7ab3263dcb8cee39b43dbd313eba8abef376.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
The driver uses several symbols and structs defined in that header. The
header is currently included transitively via
"vip.h" ->
<media/v4l2-ctrls.h> ->
<media/media-request.h> ->
<media/media-device.h> ->
<linux/platform_device.h>
which seems to be on the lower end of the scale between random and
reliable.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://patch.msgid.link/9f2e0e001eec087f00ac2c5af2de2e8f6d0978c1.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
The function ata_scsi_rbuf_fill() is used to copy the response of
emulated SCSI commands from ata_scsi_rbuf to the SCSI command's
scatterlist.
Currently, sg_copy_from_buffer() is called with the size argument
set to ATA_SCSI_RBUF_SIZE (2048 bytes). Since ata_scsi_rbuf is
zeroed out before the simulation actor is invoked, copying the
full buffer size causes the remainder of the SCSI command's
transfer buffer (beyond the actual response length 'len') to be
overwritten with zeroes. This clobbers any pre-existing sentinel
values or data in the caller's buffer tail, even though the
correct residual count is reported via scsi_set_resid().
Fix this by passing the actual response length 'len' as the copy
size to sg_copy_from_buffer(), ensuring that the tail of the
caller's buffer remains untouched. Also, add a defensive check
to ensure that the actor does not return a length exceeding the
static buffer capacity. If this occurs, trigger a WARN_ON(),
fail the command with an aborted command error, and return
immediately without copying any data.
The fix was tested by invoking an SCSI SG_IO INQUIRY on
an ATA disk on vanilla build, and build with the fix. Confirmed
that the input buffer's tail end remains unmodified with the fix.
Fixes: 5251ae224d8d ("ata: libata-scsi: Return residual for emulated SCSI commands")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Karuna Ramkumar <rkaruna@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
When dmaengine_slave_config() fails, the DMA channel acquired by
dma_request_chan() is not released before returning the error,
leaking the channel reference.
Fix by adding dma_release_channel() in the error path.
The ata_host_activate() error path already correctly releases the
DMA channel.
Cc: stable@vger.kernel.org
Fixes: 88622d80af82 ("ata: pata_pxa: dmaengine conversion")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
gemini_sata_bridge_init() prepares and enables both SATA PCLKs, then
disables them again while keeping the clocks prepared for later bridge
start and stop operations. If gemini_setup_ide_pins() fails after that,
gemini_sata_probe() returns directly and skips the existing
out_unprep_clk unwind path.
Route the IDE pinctrl failure through out_unprep_clk so the clocks
prepared by gemini_sata_bridge_init() are unprepared before probe
fails.
Fixes: d872ced29d5f ("ata: sata_gemini: Introduce explicit IDE pin control")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
ata_dev_config_cpr() takes the number of range descriptors from buf[0]
of the concurrent positioning ranges log (up to 255), which the device
reports independently of the log size in the GPL directory. The count is
then walked at a fixed 32-byte stride in two places with no bound: the
log read here, and the INQUIRY VPD page B9h emitter, which writes one
descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device
reporting a count larger than its own log overflows the read buffer (up
to 7704 bytes past a 512-byte slab), and a count above 62 overflows the
response buffer on the emit side.
Bound the count once, on probe, against both the log the device returned
and the number of descriptors the VPD B9h response buffer can hold
(ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range
count with a warning; this keeps the emitter in bounds with no separate
change there.
Suggested-by: Damien Le Moal <dlemoal@kernel.org>
Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
Fixes: c745dfc541e7 ("libata: fix reading concurrent positioning ranges log")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
The PNY CS900 1TB SSD (Phison PS3111-S11, DRAM-less) drops off the bus
after entering Device-Initiated Slumber during idle. With the default
med_power_with_dipm policy the link goes down (SStatus 1 SControl 300)
and does not recover, forcing the filesystem read-only. Forcing
max_performance keeps the link stable across prolonged idle.
Add a NOLPM quirk so link power management is disabled for this drive
specifically, leaving it intact for other devices on the host.
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
RTL8723BE outputs a large amount of PCIe AER errors during and
after boot, even before probe and when driver is never loaded.
This causes significant system slowdown.
The errors are the same as reported by
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
Add the RTL8723BE with subsystem ID 17aa:b736 to the rtl_aspm_quirks
table to stop the AER errors. AER errors can still be present prior to
pci probe, as the device by default may have ASPM enabled.
Testing on a Razer Blade 14 2017 which shipped from the
OEM equipped with an RTL8723BE card with this subsystem ID
confirms that this patch resolves the AER flood and allows the
wireless card to function normally once the driver takes over.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260630141553.785769-4-william.hansen.baird@gmail.com
|
|
Refactor the ASUSTek quirk logic from an if-statement to a standard
rtl_aspm_quirks pci_device_id table. This allows future devices with
the same quirk to be added more easily while avoiding a large if-chain.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260630141553.785769-3-william.hansen.baird@gmail.com
|
|
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
adds code which sets ppsc->support_aspm to false in
_rtl_pci_update_default_setting() in order to disable ASPM.
This does not, however, disable ASPM. Rather, it disables driver
control of ASPM, and blocks calls to rtl_pci_enable_aspm()
and rtl_pci_disable_aspm().
In some cases, the pci device supplied to the probe function has
ASPM enabled. The code would therefore not disable ASPM, as it means to,
but rather just leave it enabled.
This was discovered through testing on a Razer Blade 14 2017.
Implement a new __rtl_pci_disable_aspm(hw) function which does not check
ppsc->support_aspm before disabling and call it from
rtl_pci_disable_aspm().
Then move the code added in the previous commit to rtl_pci_init_aspm() to
allow adding a call to __rtl_pci_disable_aspm(hw).
This makes sure ASPM is disabled while still disabling
driver control of ASPM to block it from being enabled later.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260630141553.785769-2-william.hansen.baird@gmail.com
|
|
rtw89_mac_check_he_obss_narrow_bw_ru_iter() reads extended capability
byte 10, but rejects only datalen values below 10. Byte 10 requires at
least 11 bytes.
Require datalen >= 11 before reading data[10].
Fixes: 8d540f9d2916 ("wifi: rtw89: disable 26-tone RU HE TB PPDU transmissions")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2026063009025530.2-ccfa108-0024-wifi-rtw89-fix-HE-extended--pengpeng@iscas.ac.cn
|
|
Several functions called in rtw89_ops_start_ap() may fail to allocate
skb or fail to send H2C command to firmware, returning -ENOMEM or an
error code. Their return values are ignored, so subsequent commands
are executed with incorrect state.
Check the return values and propagate errors.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: a52e4f2ce0f5 ("rtw89: implement ieee80211_ops::start_ap and stop_ap")
Signed-off-by: Dmitry Morgun <d.morgun@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260629094452.8709-1-d.morgun@ispras.ru
|
|
Only the WiFi 6 chips need to initialize RF register when WoWLAN download
FW for some power save issue. Applying the same initialization flow to
WiFi 7 chips might trigger the error
'RF parameters exceed size. path=1, idx=1500.'.
This happens because normal mode uses rtw89_phy_config_rf_reg_v1(), which
skips registers with addresses below 0x100. However, WoWLAN mode uses
rtw89_phy_config_rf_reg_noio(), and WiFi 7 chips do not satisfy the
rtw89_chip_rf_v1() condition. As a result, more RF registers are
configured, causing the size overflow error.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-11-pkshih@realtek.com
|
|
Some MLO APs expect WoWLAN ARP response frames to be transmitted as
QoS data frames and may discard frames that do not contain a QoS
Control field.
Add a QoS Control field and use the QoS Data subtype when generating
WoWLAN ARP responses for MLD vifs. Keep the existing frame format
unchanged for non-MLO connections.
This allows WoWLAN ARP responses to be accepted by MLO APs while
preserving compatibility with legacy APs.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-10-pkshih@realtek.com
|
|
Currently, WoWLAN ARP replies for MLO stations use the link address in
the ARP hardware address fields.
As a result, peers may learn the link address from the ARP reply and
use it as the destination address for subsequent traffic. Some APs may
not forward frames addressed to the link address, causing connectivity
issues.
Use the MLD address instead when generating WoWLAN ARP replies so peers
learn the correct address for MLO stations.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-9-pkshih@realtek.com
|
|
The link ID field in H2C command of LPS MLO common info is incorrectly
filled with the PHY index. Fix it with the target link ID.
Fixes: 20380a039ddd ("wifi: rtw89: phy: add H2C command to send detail RX gain and link parameters for PS mode")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-8-pkshih@realtek.com
|
|
On some platforms, refclk is not available up to 15 ms after entering
suspend. The delayed clock cause the hardware to detect falsely error
and trigger an unexpected hardware reset. Disable the phy error flag
related to refclk to fix it.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-7-pkshih@realtek.com
|
|
7 chips
Sniffer mode is enabled by default in the RX filter on Wi-Fi 7 chips,
which causes all packets to be received regardless of the ADDR_CAM
lookup result. This may result in unexpected packets being received.
Therefore, disable it by default.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-6-pkshih@realtek.com
|
|
issue
A special case is when C2H done ack has been completed, but the
corresponding packet offload response has not actually been received,
which causes the add packet offload to fail. In this state, firmware
treats the entry as added, so subsequent add requests for the same id
are rejected as duplicates. To recover from this, send a delete packet
offload H2C command to roll back the normal state. It has been tested and
verified to have no functional side effect.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-5-pkshih@realtek.com
|
|
The UDM1 is user define message to record count of H2C command sent by
driver and received by firmware. Normally, this value should be zero.
Otherwise, throw a warning.
For the new chip RTL8922DE, its default value is not zero, causing a
warning at first time probe. Since this is a debug purpose and the
value will be set to zero right after this checking, lower the debug level.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-4-pkshih@realtek.com
|
|
Set chip version to register shared with firmware before downloading
firmware, so firmware can run proper flow according to the version.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-3-pkshih@realtek.com
|
|
Currently active TX only finishes after ensuring PCIE and DMAC become idle.
However, the waiting time might be long. Since the packet is already
transmitted over the air, update the registers to finish active TX
immediately, regardless of the PCIE/DMAC status.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260625061545.44808-2-pkshih@realtek.com
|
|
`max_response` and `sensor_num` are read from different EC commands:
- `max_response` is from cros_ec_get_proto_info().
ec_dev->max_response = info->max_response_packet_size -
sizeof(struct ec_host_response);
- `sensor_num` is from cros_ec_get_sensor_count().
sensor_num = cros_ec_get_sensor_count(ec);
With a malfunctioning EC firmware, it is possible that the `msg->insize`
(i.e., `fifo_info_length` in the context) could be clamped in
cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`.
int fifo_info_length =
sizeof(struct ec_response_motion_sense_fifo_info) +
sizeof(u16) * sensorhub->sensor_num;
This means the number of read bytes could be less than expected. As a
result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler()
overreads the `resp->fifo_info` buffer.
Check the return value of cros_ec_cmd_xfer_status() and abort if the
number of bytes read does not match the expected length.
Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Add string for logic using and show logs.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-11-pkshih@realtek.com
|
|
The firmware 0.35.94.1 included several new features. Wi-Fi TX power
setting offload to firmware. Including dual BT / dual Wi-Fi MAC related
configurations.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-10-pkshih@realtek.com
|
|
It's more closing to the original meaning. It is defined for rearranging
driver info index by firmware support version.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-9-pkshih@realtek.com
|
|
In order to support external Zigbee/Thread/Bluetooth etc module,
the version 8 add the parameter for the case. And also update the
related configuration function.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260624033941.45918-8-pkshih@realtek.com
|
