| Age | Commit message (Collapse) | Author |
|---|
|
Pull virtio fixes from Michael Tsirkin:
"Just a bunch of fixes, mostly trivial ones in tools/virtio"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vhost/vsock: improve RCU read sections around vhost_vsock_get()
tools/virtio: add device, device_driver stubs
tools/virtio: fix up oot build
virtio_features: make it self-contained
tools/virtio: switch to kernel's virtio_config.h
tools/virtio: stub might_sleep and synchronize_rcu
tools/virtio: add struct cpumask to cpumask.h
tools/virtio: pass KCFLAGS to module build
tools/virtio: add ucopysize.h stub
tools/virtio: add dev_WARN_ONCE and is_vmalloc_addr stubs
tools/virtio: stub DMA mapping functions
tools/virtio: add struct module forward declaration
tools/virtio: use kernel's virtio.h
virtio: make it self-contained
tools/virtio: fix up compiler.h stub
|
|
mtk_eint_do_init() allocates several pointer arrays which are then
populated in a per-instance loop and freed on error. The arrays are
currently allocated with devm_kmalloc(), so their entries are left
uninitialised until the per-instance allocations succeed.
On a failure in the middle of the loop, the error path iterates over
the full nbase range and calls devm_kfree() on each element. For
indices which were never initialised, the corresponding array entries
contain stack garbage. If any of those happen to be non-zero,
devm_kfree() will pass them to devres_destroy(), which will WARN
because there is no matching devm_kmalloc() resource for such bogus
pointers.
Improve the robustness and readability by:
- Using devm_kcalloc() for the pointer arrays so that all entries
start as NULL, ensuring that only genuinely initialised elements
may be freed and preventing spurious WARN_ON()s in the error path.
- Switching the allocations to sizeof(*ptr) / sizeof(**ptr) forms,
avoiding hard-coded element types and making the code more resilient
to future type changes.
- Dropping the redundant NULL checks before devm_kfree(), as
devm_kfree() safely handles NULL pointers.
The functional behaviour in the successful initialisation path remains
unchanged, while the error handling becomes simpler and less
error-prone.
Reviewed-by: fanggeng <fanggeng@lixiang.com>
Signed-off-by: Liang Jie <liangjie@lixiang.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Pull smb server fixes from Steve French:
- Fix parsing of SMB1 negotiate request by adjusting offsets affected
by the removal of the RFC1002 length field from the SMB header
- Update minimum PDU size macros for both SMB1 and SMB2
- Rename smb2_get_msg function to smb_get_msg to better reflect its
role in handling both SMB1 and SMB2 requests
* tag 'v6.19-rc2-smb3-server-fixes' of git://git.samba.org/ksmbd:
smb/server: fix minimum SMB2 PDU size
smb/server: fix minimum SMB1 PDU size
ksmbd: rename smb2_get_msg to smb_get_msg
ksmbd: Fix to handle removal of rfc1002 header from smb_hdr
|
|
In mt8189-pinctrl driver, a previous commit changed the register base
name array (mt8189_pinctrl_register_base_names) entry name and order to
align it with the same name and order as the "mediatek,mt8189-pinctrl"
devicetree bindings. The new order (by ascending register address) now
causes an issue with MT8189 pinctrl configuration.
MT8189 SoC has multiple base addresses for the pin configuration
registers. Several constant data structures, declaring each pin
configuration, are using PIN_FIELD_BASE() macro which i_base parameter
indicates for a given pin the lookup index in the base register address
array of the driver internal data for the configuration register
read/write accesses. But in practice, this parameter is given a
hardcoded numerical value that corresponds to the expected base
register entry index in mt8189_pinctrl_register_base_names array.
Since this array reordering, the i_base index matching is no more
correct.
So, in order to avoid modifying over a thousand of PIN_FIELD_BASE()
calls, restore previous mt8189_pinctrl_register_base_names entry order.
Fixes: 518919276c41 ("pinctrl: mediatek: mt8189: align register base names to dt-bindings ones")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The cdns_pcie_host_dma_ranges_cmp() element comparison function used by
list_sort() is of type list_cmp_func_t, so it returns a 32-bit int.
cdns_pcie_host_dma_ranges_cmp() computes a resource_size_t difference that
may be a 64-bit value, and truncating that difference to a 32-bit return
value may change the sign and result in an invalid sort order.
Avoid the truncation and invalid sort order by returning -1, 0, or 1.
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20251209223756.2321578-1-irogers@google.com
|
|
Change the module macro back to builtin, which does not define an exit
function. This will prevent the module from being unloaded. There are
concerns with modules not cleaning up IRQs on unload, thus unload must be
specifically disallowed. Drop the remove callback as it is unused.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250731-pci-tegra-module-v7-3-cad4b088b8fb@gmail.com
|
|
Export tegra_cpuidle_pcie_irqs_in_use() to allow pci-tegra to be built as a
module.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250731-pci-tegra-module-v7-2-cad4b088b8fb@gmail.com
|
|
Export irq_domain_free_irqs() to allow PCI/MSI drivers like pci-tegra to be
built as a module.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://patch.msgid.link/20250731-pci-tegra-module-v7-1-cad4b088b8fb@gmail.com
|
|
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI battery driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3187448.CbtlEUcBR6@rafael.j.wysocki
|
|
Notice that sysfs_battery_cleanup() calls sysfs_remove_battery() under
battery->update_lock which is also done in acpi_battery_remove(), so
adjust the latter to use it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/1866517.TLkxdtWsSY@rafael.j.wysocki
|
|
Adjust acpi_battery_notify() to cast its "data" argument to a struct
acpi_battery pointer istead of a struct acpi_device one, which allows
the use of acpi_driver_data() to be limited and will facilitate
subsequent changes.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/4344406.1IzOArtZ34@rafael.j.wysocki
|
|
In the process of handling system resume, acpi_thermal_resume() attempts
to power up active cooling devices to guarantee that they will be
operational when the ACPI thermal check queued by it runs. However,
the only kind of cooling devices that can be bound to ACPI thermal zones
is fans and they are already powered up by the ACPI fan driver resume,
which additionally takes "ACPI 4" fans that don't need to be powered
up into account.
For this reason, remove the part of acpi_thermal_resume() related to
fans and in order to ensure that it will run after powering up all fans,
rename it to acpi_thermal_complete() and point the .complete() driver
callback to it. Analogously, rename acpi_thermal_suspend() to
acpi_thermal_prepare() and point the .prepare() driver callback to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: lihuisong@huawei.com
Link: https://patch.msgid.link/3024049.e9J7NaK4W3@rafael.j.wysocki
|
|
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI thermal zone driver to a platform
one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: lihuisong@huawei.com
Link: https://patch.msgid.link/2249483.irdbgypaU6@rafael.j.wysocki
|
|
Adjust acpi_thermal_notify() to cast its "data" argument to a struct
acpi_thermal pointer istead of a struct acpi_device one, which allows
the use of acpi_driver_data() to be limited and will facilitate
subsequent changes.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: lihuisong@huawei.com
Link: https://patch.msgid.link/5035876.GXAFRqVoOG@rafael.j.wysocki
|
|
Currently, platform devices are not registered for ACPI thermal zones
because they are not represented as device objects in the ACPI namespace.
Instead, they are represented as thermal zone objects, so in particular
the platform_id flag is not set for them during enumeration because it
is only set for objects of type ACPI_BUS_TYPE_DEVICE, but otherwise they
are handled similarly at the ACPI core level.
To facilitate converting the ACPI thermal zone driver into a platform
one, modify acpi_set_pnp_ids() to set the platform_id flag for thermal
zones in analogy with device objects to cause platform devices to be
registered for them.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: lihuisong@huawei.com
Link: https://patch.msgid.link/4701463.LvFx2qVVIh@rafael.j.wysocki
|
|
It is generally questionable to mark struct acpi_device "devices" as
wakeup-capable because they represent firmware entities that by
themselves have no wakeup capabilities.
It was done for struct acpi_device "devices" corresponding to buttons
because the ACPI button driver was binding to them directly, but now
that corresponding platform devices are created for the buttons and
they are marked as wakeup-capable by the ACPI button driver, there is
no reason to continue doing it.
Update acpi_wakeup_gpe_init() accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2891119.BEx9A2HvPv@rafael.j.wysocki
|
|
Both ACPI button drivers have been converted to platform ones, so there
is no reason to attempt to bind an ACPI driver to a struct acpi_device
representing a fixed event device button.
Update the relevant code accordingly.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2213073.OBFZWjSADL@rafael.j.wysocki
|
|
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI tiny-power-button driver to a
platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ rjw: White space fixup ]
Link: https://patch.msgid.link/5629403.Sb9uPGUboI@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI button driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2461734.NG923GbCHz@rafael.j.wysocki
|
|
Adjust the event notification routines in the ACPI button driver to
take a struct acpi_button pointer as an argument istead of a struct
acpi_device one where applicable, which allows the use of
acpi_driver_data() to be limited and will facilitate subsequent
changes.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2260995.Icojqenx9y@rafael.j.wysocki
|
|
Move duplicate fixed event device registration code
from acpi_bus_scan_fixed() into a new function called
acpi_bus_add_fixed_device_object() and make acpi_bus_scan_fixed()
invoke that function as needed.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/1916860.atdPhlSkOF@rafael.j.wysocki
|
|
On platforms using ACPI, power and sleep buttons may be so called "fixed
event devices" in which case they are hooked up directly to the Fixed
Events register in the platform via dedicated lines and there are no
corresponding device objects in the ACPI namespace. Nevertheless, in
Linux they get corresponding struct acpi_device objects with special
device IDs, either LNXPWRBN or LNXSLPBN, which are then used for driver
binding in a ususal way.
However, the function creating those struct acpi_device objects for
"fixed event device" buttons, acpi_bus_scan_fixed(), does not register
platform devices for them, unlike the generic code handling device
enumeration based on the ACPI namespace. Consequently, if an ACPI power
or sleep button is represented by a device object in the ACPI namespace,
it will get a corresponding platform device, but if it is a "fixed event
device", it will not get one, which is inconsistent and prevents the
ACPI power button driver from being converted into a platform driver.
For the sake of consistency and to allow the ACPI power button driver to
become a platform one going forward, modify acpi_bus_scan_fixed() to
register platform devices for "fixed event device" buttons and update
ACPI platform device registration code to work with non-device ACPI
object types, so it can handle the buttons in question.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3731144.R56niFO833@rafael.j.wysocki
|
|
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI NFIT core driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
This change was mostly developed by Michal Wilczynski [1].
Linu: https://lore.kernel.org/linux-acpi/20231011083334.3987477-6-michal.wilczynski@intel.com/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/6221453.lOV4Wx5bFT@rafael.j.wysocki
Acked-by: Ira Weiny <ira.weiny@intel.com>
Tested-by: Ira Weiny <ira.weiny@intel.com>
|
|
It looks like the buffer allocated and mapped in add_card() is done
with size RCV_BUFFER_SIZE which is 16 KB and 4KB.
Fixes: 286468210d83 ("firewire: new driver: nosy - IEEE 1394 traffic sniffer")
Co-developed-by: Thomas Fourier <fourier.thomas@gmail.com>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Co-developed-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20251216165420.38355-2-fourier.thomas@gmail.com
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The ARM MALI TYR DRM DRIVER is already maintained through the drm-rust
tree, hence exclude it from drm-misc.
Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251223120436.33233-1-dakr@kernel.org
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
Fix a missing ':' in the ARM MALI TYR DRM DRIVER entry, which does
prevent script/get_maintainer.pl to properly work and pick up the
corresponding maintainers.
Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs")
Reported-by: Tamir Duberstein <tamird@kernel.org>
Closes: https://lore.kernel.org/lkml/CAJ-ks9mrZtnPUjp5tD03hW+TyS0M9i-KRF_ramNY-oh-0X+ayA@mail.gmail.com/
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
Link: https://patch.msgid.link/20251223115949.32531-1-dakr@kernel.org
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for 6.20:
Core Changes:
- dma-buf: Add tracepoints
- sched: Introduce new helpers
Driver Changes:
- amdxdna: Enable hardware context priority, Remove (obsolete and
never public) NPU2 Support, Race condition fix
- rockchip: Add RK3368 HDMI Support
- rz-du: Add RZ/V2H(P) MIPI-DSI Support
- panels:
- st7571: Introduce SPI support
- New panels: Sitronix ST7920, Samsung LTL106HL02, LG LH546WF1-ED01, HannStar HSD156JUW2
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/20251219-arcane-quaint-skunk-e383b0@houat
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for 6.19:
UAPI Changes:
- panfrost: Add PANFROST_BO_SYNC ioctl
- panthor: Add PANTHOR_BO_SYNC ioctl
Core Changes:
- atomic: Add drm_device pointer to drm_private_obj
- bridge: Introduce drm_bridge_unplug, drm_bridge_enter, and
drm_bridge_exit
- dma-buf: Improve sg_table debugging
- dma-fence: Add new helpers, and use them when needed
- dp_mst: Avoid out-of-bounds access with VCPI==0
- gem: Reduce page table overhead with transparent huge pages
- panic: Report invalid panic modes
- sched: Add TODO entries
- ttm: Various cleanups
- vblank: Various refactoring and cleanups
- Kconfig cleanups
- Removed support for kdb
Driver Changes:
- amdxdna: Fix race conditions at suspend, Improve handling of zero
tail pointers, Fix cu_idx being overwritten during command setup
- ast: Support imported cursor buffers
-
- panthor: Enable timestamp propagation, Multiple improvements and
fixes to improve the overall robustness, notably of the scheduler.
- panels:
- panel-edp: Support for CSW MNE007QB3-1, AUO B140HAN06.4, AUO B140QAX01.H
Signed-off-by: Dave Airlie <airlied@redhat.com>
[airlied: fix mm conflict]
From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/20251212-spectacular-agama-of-abracadabra-aaef32@penduick
|
|
Internally wiphy writes to individual channels in this structure,
so we must not share one static definition of channel list between
multiple device instances, because that causes hard to debug
breakage.
For example, with two rtw88 driven devices in the system, channel
information may get incoherent, preventing channel use.
Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing
of struct ieee80211_supported_band data").
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.com
|
|
Simplify the code by using device managed memory allocations.
This also fixes a memory leak in rtw_register_hw(). The supported bands
were not freed in the error path.
Copied from commit 145df52a8671 ("wifi: rtw89: Convert
rtw89_core_set_supported_band to use devm_*").
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.com
|
|
rtw_core_enable_beacon() reads 4 bytes from an address that is not a
multiple of 4. This results in a crash on some systems.
Do 1 byte reads/writes instead.
Unable to handle kernel paging request at virtual address ffff8000827e0522
Mem abort info:
ESR = 0x0000000096000021
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x21: alignment fault
Data abort info:
ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000
[ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13
Internal error: Oops: 0000000096000021 [#1] SMP
Modules linked in: [...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...]
CPU: 0 UID: 0 PID: 73 Comm: kworker/u32:2 Tainted: G W 6.17.9 #1-NixOS VOLUNTARY
Tainted: [W]=WARN
Hardware name: FriendlyElec NanoPC-T6 LTS (DT)
Workqueue: phy0 rtw_c2h_work [rtw88_core]
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : rtw_pci_read32+0x18/0x40 [rtw88_pci]
lr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core]
sp : ffff800080cc3ca0
x29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828
x26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00
x23: ffff000112fdef18 x22: ffff000111c29970 x21: 0000000000000001
x20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522
Call trace:
rtw_pci_read32+0x18/0x40 [rtw88_pci] (P)
rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core]
rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core]
rtw_c2h_work+0x50/0x98 [rtw88_core]
process_one_work+0x178/0x3f8
worker_thread+0x208/0x418
kthread+0x120/0x220
ret_from_fork+0x10/0x20
Code: d28fe202 8b020000 f9524400 8b214000 (b9400000)
---[ end trace 0000000000000000 ]---
Fixes: ad6741b1e044 ("wifi: rtw88: Stop high queue during scan")
Cc: stable@vger.kernel.org
Closes: https://github.com/lwfinger/rtw88/issues/418
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/6345300d-8c93-464c-9b05-d0d9af3c97ad@gmail.com
|
|
The driver reduces the RX gain while connected to a network located
close by. In this condition scans return few results because the more
distant networks can't be heard.
Temporarily increase the RX gain before scanning in order to detect
all available networks. Reset the RX gain back to the last recorded
value once the scan finishes.
Link: https://github.com/lwfinger/rtw88/issues/337
Signed-off-by: Martin Hrůza <martin.hruza123@gmail.com>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c2e72aff-190d-4f59-9914-2588de756385@gmail.com
|
|
For BE chips, needs to transmit QoS null data periodically to ensure
the connection with AP in GC+STA mode. However, in environments
with interference, the Qos null data might fail to transmit
successfully. Therefore, when receive the beacon from AP will
reset the QoS null data failure counter to avoid unnecessary
disconnection.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-13-pkshih@realtek.com
|
|
When initializing mac port, needs to set TBTT AGG number to trigger TBTT
related interrupts. Otherwise, after sending join info H2C command with
disconnection mode, firmware will clear TBTT AGG number. Without the
setting from mac port initialization after that, this port will not be
able to transmit beacons.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-12-pkshih@realtek.com
|
|
XTAL SI is an indirect serial interface to access registers in another
hardware domain. When BT driver initializes UART interface, firmware might
rarely control XTAL SI at the same time causing access racing.
Current is to adjust initialization flow to avoid the racing. To make
the racing visible if it still presents, add a message to address this.
USB adapters might be unplugged suddenly, causing flooding messages. Check
RTW89_FLAG_UNPLUGGED flag to avoid them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-11-pkshih@realtek.com
|
|
The each of C2H reg event have different polling timeout. Refine the
LPS C2H reg event polling timeout. Otherwise, during SER, the FW has
already crashed, the leave LPS check will wait until timeout expires,
causing the SER recovery to take too long.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-10-pkshih@realtek.com
|
|
Original methods of SER (system error recovery) L0/L1 simulations need
to leave PS mode before working. Introduce new methods to simulate SER
L0/L1 and they can work under PS. Since new methods require FW support,
so add a FW feature flag and configure the supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-9-pkshih@realtek.com
|
|
Dump counters of SER (system error recoery) L0/L1 related cases.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-8-pkshih@realtek.com
|
|
Originally, polling FW status was required during recovering from L1.
Now, because newer FW support event mode, the polling can be skipped.
Add a FW feature flag and configure the supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-7-pkshih@realtek.com
|
|
After recovering from L1, explicitly enable error IMR to ensure next
L1 SER (system error recovery) can work normally.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com
|
|
To run power on function properly, reset power states (off/on/PS) to
initial state. Otherwise, it might be unusable due to fail to power on.
Since a USB adapter might play as USB mass storage with driver and then
switch to WiFi adapter, causing it stays on power-on state when doing WiFi
USB probe. Exclude this case.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-5-pkshih@realtek.com
|
|
Deauth frames used wrong link address after switching from default link
to another, causing AP to reject subsequent auth frames. This affected
not only deauth but all management frames. Fixed by setting correct
mac_id to let header conversion references correct address CAM.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-4-pkshih@realtek.com
|
|
Fix missing null-data 1 when switching links. The FW should send a
null-data 1 to notify AP before disabling the old link. Adjust the
position of the H2C rtw89_fw_h2c_mlo_link_cfg to ensure proper FW
behavior during link transition.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-3-pkshih@realtek.com
|
|
Intermittent beacon loss from a specific AP can lead to
disconnections. Increasing the beacon loss threshold
helps stabilize the connection.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-2-pkshih@realtek.com
|
|
Enabling compile testing should not enable every individual driver (we
have "allyesconfig" for that) but two new drivers got this wrong.
Default to n instead of ARCH_MICROCHIP as these drivers are not needed
in every Microchip build either.
Fixes: 38cf9d641314 ("pinctrl: add pic64gx "gpio2" pinmux driver")
Fixes: 46397274da22 ("pinctrl: add polarfire soc iomux0 pinmux driver")
Cc: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Replace deprecated at25 properties with the required properties (size,
address-width and pagesize), which duplicate the removed properties.
Fix below CHECK_DTB warning:
arch/arm/boot/dts/nxp/lpc/lpc3250-phy3250.dtb: at25@0 (atmel,at25): 'pagesize' is a required property
arch/arm/boot/dts/nxp/lpc/lpc3250-phy3250.dtb: at25@0 (atmel,at25): $nodename: 'anyOf' conditional failed, one must be fixed:
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[vzapolskiy: squashed two changes from the series and updated commit message]
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
|
|
Rename nodename at@0 to eeprom@0 to fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/lpc/lpc3250-phy3250.dtb: at25@0 (atmel,at25): $nodename: 'anyOf' conditional failed, one must be fixed:
'at25@0' does not match '^eeprom@[0-9a-f]{1,2}$'
'at25@0' does not match '^fram@[0-9a-f]{1,2}$'
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
|
|
Add key- prefix to fix below CHECK_DTB warning:
arch/arm/boot/dts/nxp/lpc/lpc3250-ea3250.dtb: gpio-keys (gpio-keys): 'joy0', ... do not match any of the regexes: '^(button|...)$', 'pinctrl-[0-9]+
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
|
|
Remove usb bus and elevate all children nodes because usb bus is not
existed and only group usb devices logically.
Update register address and related full node name.
Fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/lpc/lpc3250-ea3250.dtb: usb (simple-bus): $nodename:0: 'usb' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
|
|
__io_openat_prep() allocates a struct filename using getname(). However,
for the condition of the file being installed in the fixed file table as
well as having O_CLOEXEC flag set, the function returns early. At that
point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,
the memory for the newly allocated struct filename is not cleaned up,
causing a memory leak.
Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the
successful getname() call, so that when the request is torn down, the
filename will be cleaned up, along with other resources needing cleanup.
Reported-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f
Tested-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
Fixes: b9445598d8c6 ("io_uring: openat directly into fixed fd table")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
