summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-10-29media: nvidia: tegra: Use iommu_paging_domain_alloc()Lu Baolu
An iommu domain is allocated in tegra_vde_iommu_init() and is attached to vde->dev. Use iommu_paging_domain_alloc() to make it explicit. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20241009041147.28391-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29remoteproc: Use iommu_paging_domain_alloc()Lu Baolu
An iommu domain is allocated in rproc_enable_iommu() and is attached to rproc->dev.parent in the same function. Use iommu_paging_domain_alloc() to make it explicit. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20241009041147.28391-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/amd: Fix corruption when mapping large pages from 0Jason Gunthorpe
If a page is mapped starting at 0 that is equal to or larger than can fit in the current mode (number of table levels) it results in corrupting the mapping as the following logic assumes the mode is correct for the page size being requested. There are two issues here, the check if the address fits within the table uses the start address, it should use the last address to ensure that last byte of the mapping fits within the current table mode. The second is if the mapping is exactly the size of the full page table it has to add another level to instead hold a single IOPTE for the large size. Since both corner cases require a 0 IOVA to be hit and doesn't start until a page size of 2^48 it is unlikely to ever hit in a real system. Reported-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v1-27ab08d646a1+29-amd_0map_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu: Remove useless flush from iommu_create_device_direct_mappings()Jason Gunthorpe
These days iommu_map() does not require external flushing, it always internally handles any required flushes. Since iommu_create_device_direct_mappings() only calls iommu_map(), remove the extra call. Since this is the last call site for iommu_flush_iotlb_all() remove it too. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/0-v1-bb6c694e1b07+a29e1-iommu_no_flush_all_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/sysfs: constify the class structBartosz Golaszewski
All functions that take the class address as argument expect a const pointer so we can make the iommu class constant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20241018121725.61128-1-brgl@bgdev.pl Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/mediatek: Add PGTABLE_PA_35_EN to mt8186 platform dataKonrad Adamczyk
The MT8186 chip supports 35-bit physical addresses in page table [1]. Set this platform flag. [1] MT8186G_Application Processor Functional Specification_v1.0 Signed-off-by: Konrad Adamczyk <konrada@google.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20241017112036.368772-1-konrada@google.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/amd: Do not try copy old DTE resume pathVasant Hegde
In suspend/resume path, no need to copy old DTE (early_enable_iommus()). Just need to reload IOMMU hardware. This is the side effect of commit 3ac3e5ee5ed5 ("iommu/amd: Copy old trans table from old kernel") which changed early_enable_iommus() but missed to fix enable_iommus(). Resume path continue to work as 'amd_iommu_pre_enabled' is set to false and copy_device_table() will fail. It will just re-loaded IOMMU. Hence I think we don't need to backport this to stable tree. Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/20241016084958.99727-1-vasant.hegde@amd.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Paging domain supportTomasz Jeznach
Introduce first-stage address translation support. Page table configured by the IOMMU driver will use the highest mode implemented by the hardware, unless not known at the domain allocation time falling back to the CPU’s MMU page mode. This change introduces IOTINVAL.VMA command, required to invalidate any cached IOATC entries after mapping is updated and/or removed from the paging domain. Invalidations for the non-leaf page entries use IOTINVAL for all addresses assigned to the protection domain for hardware not supporting more granular non-leaf page table cache invalidations. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/1109202d389f51c7121cb1460eb2f21429b9bd5d.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Command and fault queue supportTomasz Jeznach
Introduce device command submission and fault reporting queues, as described in Chapter 3.1 and 3.2 of the RISC-V IOMMU Architecture Specification. Command and fault queues are instantiated in contiguous system memory local to IOMMU device domain, or mapped from fixed I/O space provided by the hardware implementation. Detection of the location and maximum allowed size of the queue utilize WARL properties of queue base control register. Driver implementation will try to allocate up to 128KB of system memory, while respecting hardware supported maximum queue size. Interrupts allocation is based on interrupt vectors availability and distributed to all queues in simple round-robin fashion. For hardware Implementation with fixed event type to interrupt vector assignment IVEC WARL property is used to discover such mappings. Address translation, command and queue fault handling in this change is limited to simple fault reporting without taking any action. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/c4735fb6829053eff37ce1bcca4906192afd743c.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Device directory management.Tomasz Jeznach
Introduce device context allocation and device directory tree management including capabilities discovery sequence, as described in Chapter 2.1 of the RISC-V IOMMU Architecture Specification. Device directory mode will be auto detected using DDTP WARL property, using highest mode supported by the driver and hardware. If none supported can be configured, driver will fall back to global pass-through. First level DDTP page can be located in I/O (detected using DDTP WARL) and system memory. Only simple identity and blocking protection domains are supported by this implementation. Co-developed-by: Nick Kossifidis <mick@ics.forth.gr> Signed-off-by: Nick Kossifidis <mick@ics.forth.gr> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/e1c763aeccd2c05fd4ad3a32f6f2ff3b3148d907.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Enable IOMMU registration and device probe.Tomasz Jeznach
Advertise IOMMU device and its core API. Only minimal implementation for single identity domain type, without per-group domain protection. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/ba79c8eb9c7f1cd9a8961a1b048e3991ee9a2b05.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Add RISC-V IOMMU PCIe device driverTomasz Jeznach
Introduce device driver for PCIe implementation of RISC-V IOMMU architected hardware. IOMMU hardware and system support for MSI or MSI-X is required by this implementation. Vendor and device identifiers used in this patch matches QEMU implementation of the RISC-V IOMMU PCIe device, from Rivos VID (0x1efd) range allocated by the PCI-SIG. MAINTAINERS | added iommu-pci.c already covered by matching pattern. Link: https://lore.kernel.org/qemu-devel/20240307160319.675044-1-dbarboza@ventanamicro.com/ Co-developed-by: Nick Kossifidis <mick@ics.forth.gr> Signed-off-by: Nick Kossifidis <mick@ics.forth.gr> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/12f3bdbe519ebb7ca482191e7334d38b25b8ae8f.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29iommu/riscv: Add RISC-V IOMMU platform device driverTomasz Jeznach
Introduce platform device driver for implementation of RISC-V IOMMU architected hardware. Hardware interface definition located in file iommu-bits.h is based on ratified RISC-V IOMMU Architecture Specification version 1.0.0. This patch implements platform device initialization, early check and configuration of the IOMMU interfaces and enables global pass-through address translation mode (iommu_mode == BARE), without registering hardware instance in the IOMMU subsystem. Link: https://github.com/riscv-non-isa/riscv-iommu Co-developed-by: Nick Kossifidis <mick@ics.forth.gr> Signed-off-by: Nick Kossifidis <mick@ics.forth.gr> Co-developed-by: Sebastien Boeuf <seb@rivosinc.com> Signed-off-by: Sebastien Boeuf <seb@rivosinc.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/2f2e4530c0ee4a81385efa90f1da932f5179f3fb.1729059707.git.tjeznach@rivosinc.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-10-29Merge tag 'amd-drm-next-6.13-2024-10-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.13-2024-10-25: amdgpu: - SDMA queue reset support - SMU 13.0.6 updates - Add debugfs interface to help limit jpeg queue scheduling for testing - JPEG 4.0.3 updates - Initial runtime repartitioning support - GFX9 fixes - Misc code cleanups - Rework IP structures to better handle multiple instances of an IP - DML updates - DSC fixes - HDR fixes - Brightness control updates - Runtime pm cleanup - DMCUB fixes - DCN 3.5 updates - Struct drm_edid cleanup - Fetch EDID from _DDC if available - Ring noop optimizations - MES logging fixes - 3DLUT fixes - DCN 4.x fixes - SMU 13.x fixes - Fixes for set_soft_freq_range() - ACPI fixes - SMU 14.x updates - PSR-SU fixes - fdinfo cleanup - DCN documentation updates amdkfd: - Misc code cleanups - Increase event FIFO size - Copy wave state fixes for SDMA radeon: - Fix possible overflow in packet3 check - Late init connector fix - Always set GEM function pointer Documentation: - Update drm-memory documentation From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025132336.2416913-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-10-29mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OPTakahiro Kuwano
In octal DTR mode, RD_ANY_REG_OP needs to use 4-byte address regardless of flash's internal address mode. Use nor->addr_nbytes which is set to 4 during setup. Fixes: eff9604390d6 ("mtd: spi-nor: spansion: add octal DTR support in RD_ANY_REG_OP") Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Link: https://lore.kernel.org/r/20241016000837.17951-1-Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-29cpufreq: add virtual-cpufreq driverDavid Dai
Introduce a virtualized cpufreq driver for guest kernels to improve performance and power of workloads within VMs. This driver does two main things: 1. Sends the frequency of vCPUs as a hint to the host. The host uses the hint to schedule the vCPU threads and decide physical CPU frequency. 2. If a VM does not support a virtualized FIE(like AMUs), it queries the host CPU frequency by reading a MMIO region of a virtual cpufreq device to update the guest's frequency scaling factor periodically. This enables accurate Per-Entity Load Tracking for tasks running in the guest. Co-developed-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: David Dai <davidai@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2024-10-29thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGININGMika Westerberg
Normally there is no need to enumerate retimers on the other side of the cable. This is only needed in special cases where user wants to run receiver lane margining against the downstream facing port of a retimer. Furthermore this might confuse the userspace tools such as fwupd because it cannot read the information it expects from these retimers. Fix this by changing the retimer enumeration code to add only on-board retimers when CONFIG_USB4_DEBUGFS_MARGINING is not enabled. Reported-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219420 Cc: stable@vger.kernel.org Fixes: ff6ab055e070 ("thunderbolt: Add receiver lane margining support for retimers") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-10-29drm/i914/xe3lpd: Increase bigjoiner limitationsSuraj Kandpal
With 6k resolution support for a single crtc being added bigjoiner will only come into picture when hdisplay > 6144 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-4-suraj.kandpal@intel.com
2024-10-29drm/i915/psr: Change psr size limits checkSuraj Kandpal
Change the check to only check for psr size limits till Pre-Xe2 since after that the psr size is equal to maximum pipe size anyways. --v2 -Check only size limit until pre-Xe2 [Matt] --v3 -Make sure psr_max_{h,v} and max_bpp are equal to crtc_{h,v}_display and pipe_bpp [Ankit] Bspec: 69885, 68858 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028130012.199090-1-suraj.kandpal@intel.com
2024-10-29drm/i915/xe3lpd: Increase resolution for plane to support 6kSuraj Kandpal
DISPLAY_VER >= 30 onwards CRTC can now support 6k resolution. Increase pipe and plane max width and height to reflect this increase in resolution. --v2 -Take care of the subsampling scenario sooner rather than later [Matt] --v3 -Take care of the joined pipe limits too [Ankit/Matt] --v4 -Leave the joiner limits check here as is and handle them later [Ville] Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-2-suraj.kandpal@intel.com
2024-10-29wifi: rtw88: 8812a: Mitigate beacon lossBitterblue Smith
The RTL8812AU has a reception problem, maybe only in the 5 GHz band. Sometimes, in some positions, it stops receiving anything even though the distance to the AP is only ~3 meters and there are no obstacles. Moving it a few centimeters fixes it. Switch the initial gain to maximum coverage when there is beacon loss. This only helps sometimes. This is similar to what the official driver does. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com
2024-10-29wifi: rtw88: 8821a: Regularly ask for BT info updatesBitterblue Smith
The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth headphones are connected, but not when they are disconnected. This leads to the coexistence code still using the A2DP algorithm long after the headphones are disconnected, which means the wifi speeds are much lower than they should be. Work around this by asking for updates every two seconds if the chip is RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com
2024-10-29wifi: rtw88: coex: Support chips without a scoreboardBitterblue Smith
All the chips currently supported have a "scoreboard": the chip keeps track of certain things related to bluetooth, for example, whether bluetooth is active. The information can be read from register 0xaa. RTL8821AU doesn't have this. Implement bluetooth activity detection in rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters. This is mostly important for RTL8811AU, the version of RTL8821AU without bluetooth. Without this change, the driver thinks bluetooth is active and the wifi speeds are low. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com
2024-10-29wifi: rtw88: Detect beacon loss with chips other than 8822cBitterblue Smith
The driver is supposed to avoid entering LPS (power saving) when there is beacon loss, but only RTL8822C detects the beacon loss (because it has beacon filtering in the firmware). Detect beacon loss with the other chips by checking if we received less than half the expected number of beacons in the last 2-second interval. This gets rid of the occasional "failed to get tx report from firmware" warnings with RTL8821AU. It may also avoid some disconnections. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com
2024-10-29wifi: rtw88: usb: Set pkt_info.ls for the reserved pageBitterblue Smith
"ls" meaning "last segment". Without this RTL8812AU can't upload the reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.) Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com
2024-10-29wifi: rtw88: Move pwr_track_tbl to struct rtw_rfe_defBitterblue Smith
RTL8812AU uses one set of TX power tracking tables for RFE 3, and another set for everything else. Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in order to load the right set of tables for each RFE (RF front end) type. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
2024-10-29wifi: rtw88: Support TX page sizes bigger than 128Bitterblue Smith
All the chips supported so far have a TX page size of 128 bytes. Change the type of the page_size member of struct rtw_chip_info from u8 to u16 in order to support RTL8821AU (page size of 256 bytes) and RTL8812AU (page size of 512 bytes). Also change the types of several related variables and function parameters from u8 to u16. The TX page size is used, among other things, to construct the beacon, null data, QOS null data, and PS poll templates which are uploaded to the chip's reserved page. Each template needs to be aligned on a multiple of the TX page size. Power saving can't work if the TX page size is wrong. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com
2024-10-29wifi: rtw88: Make txagc_remnant_ofdm an arrayBitterblue Smith
txagc_remnant_ofdm member of struct rtw_dm_info should be different for each RF path, so make it an array of size RTW_RF_PATH_MAX (4). Until now all the chips using this had only one RF path, but RTL8812AU has two, and RTL8814AU has four. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com
2024-10-29wifi: rtw88: Enable data rate fallback for older chipsBitterblue Smith
RTL8811AU fails to perform the 4-way handshake when the AP is too far because it transmits the EAPOL frames at MCS9 and when that doesn't work it retries 48 times with the same rate, to no avail. Retrying 48 times with the same rate seems pointless. Set the appropriate field in the TX descriptor to allow it to use lower rates when retrying. Set it for RTL8723D and RTL8703B because they interpret this field the same way as RTL8811A. The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in the TX descriptor differently, so leave it alone for those chips. Tested with RTL8811AU and RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
2024-10-29wifi: rtw88: Let each driver control the power on/off processBitterblue Smith
RTL8821AU and RTL8812AU have to do some things differently, so let them have full control. The other chips use the same functions as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
2024-10-29wifi: rtw88: Allow rtw_chip_info.ltecoex_addr to be NULLBitterblue Smith
RTL8821A doesn't have this. Trying to use it results in error messages, so don't try if ltecoex_addr is NULL. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
2024-10-29wifi: rtw88: Extend the init table parsing for RTL8812AUBitterblue Smith
The chips supported so far only use the first condition, and so the parsing code ignores the second condition. RTL8812AU's init tables use the second condition also. Make the parsing code check it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
2024-10-29wifi: rtw88: Allow different C2H RA report sizesBitterblue Smith
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes. Avoid the "invalid ra report c2h length" error. Also, use a struct and u8_get_bits() to access the RA report C2H. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
2024-10-29wifi: rtw88: Dump the HW features only for some chipsBitterblue Smith
RTL8821AU and RTL8812AU don't support this. They hit the "failed to read hw feature report" error. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com
2024-10-29wifi: rtw88: Add some definitions for RTL8821AU/RTL8812AUBitterblue Smith
Add 8821A and 8812A chip type enums. Add cck_high_power member to struct rtw_hal. This will be used to calculate the RX signal strength of RTL8812AU. Add various register definitions which will be used by the new drivers. Move some existing register definitions from rtw8821c.h and rtw8822b.h. They were duplicated in those headers and will also be used by the new drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
2024-10-29usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non ↵Amit Sunil Dhamne
self-powered devices PD3.1 spec ("8.3.3.3.3 PE_SNK_Wait_for_Capabilities State") mandates that the policy engine perform a hard reset when SinkWaitCapTimer expires. Instead the code explicitly does a GET_SOURCE_CAP when the timer expires as part of SNK_WAIT_CAPABILITIES_TIMEOUT. Due to this the following compliance test failures are reported by the compliance tester (added excerpts from the PD Test Spec): * COMMON.PROC.PD.2#1: The Tester receives a Get_Source_Cap Message from the UUT. This message is valid except the following conditions: [COMMON.PROC.PD.2#1] a. The check fails if the UUT sends this message before the Tester has established an Explicit Contract ... * TEST.PD.PROT.SNK.4: ... 4. The check fails if the UUT does not send a Hard Reset between tTypeCSinkWaitCap min and max. [TEST.PD.PROT.SNK.4#1] The delay is between the VBUS present vSafe5V min and the time of the first bit of Preamble of the Hard Reset sent by the UUT. For the purpose of interoperability, restrict the quirk introduced in https://lore.kernel.org/all/20240523171806.223727-1-sebastian.reichel@collabora.com/ to only non self-powered devices as battery powered devices will not have the issue mentioned in that commit. Cc: stable@vger.kernel.org Fixes: 122968f8dda8 ("usb: typec: tcpm: avoid resets for missing source capability messages") Reported-by: Badhri Jagan Sridharan <badhri@google.com> Closes: https://lore.kernel.org/all/CAPTae5LAwsVugb0dxuKLHFqncjeZeJ785nkY4Jfd+M-tCjHSnQ@mail.gmail.com/ Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20241024022233.3276995-1-amitsd@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29wifi: rtw88: Report the signal strength only if it's knownBitterblue Smith
RTL8811CU doesn't report the signal strength for many (any?) data frames. When the signal strength is not known, set RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal strength of 0. 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/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.com
2024-10-29usb: phy: Fix API devm_usb_put_phy() can not release the phyZijun Hu
For devm_usb_put_phy(), its comment says it needs to invoke usb_put_phy() to release the phy, but it does not do that actually, so it can not fully undo what the API devm_usb_get_phy() does, that is wrong, fixed by using devres_release() instead of devres_destroy() within the API. Fixes: cedf8602373a ("usb: phy: move bulk of otg/otg.c to phy/phy.c") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20241020-usb_phy_fix-v1-1-7f79243b8e1e@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29usb: typec: use cleanup facility for 'altmodes_node'Javier Carrasco
Use the __free() macro for 'altmodes_node' to automatically release the node when it goes out of scope, removing the need for explicit calls to fwnode_handle_put(). Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20241021-typec-class-fwnode_handle_put-v2-2-3281225d3d27@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()Javier Carrasco
The 'altmodes_node' fwnode_handle is never released after it is no longer required, which leaks the resource. Add the required call to fwnode_handle_put() when 'altmodes_node' is no longer required. Cc: stable@vger.kernel.org Fixes: 7b458a4c5d73 ("usb: typec: Add typec_port_register_altmodes()") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20241021-typec-class-fwnode_handle_put-v2-1-3281225d3d27@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29usb: typec: qcom-pmic-typec: fix missing fwnode removal in error pathJavier Carrasco
If drm_dp_hpd_bridge_register() fails, the probe function returns without removing the fwnode via fwnode_handle_put(), leaking the resource. Jump to fwnode_remove if drm_dp_hpd_bridge_register() fails to remove the fwnode acquired with device_get_named_child_node(). Cc: stable@vger.kernel.org Fixes: 7d9f1b72b296 ("usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20241020-qcom_pmic_typec-fwnode_remove-v2-2-7054f3d2e215@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodesJavier Carrasco
The right function to release a fwnode acquired via device_get_named_child_node() is fwnode_handle_put(), and not fwnode_remove_software_node(), as no software node is being handled. Replace the calls to fwnode_remove_software_node() with fwnode_handle_put() in qcom_pmic_typec_probe() and qcom_pmic_typec_remove(). Cc: stable@vger.kernel.org Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241020-qcom_pmic_typec-fwnode_remove-v2-1-7054f3d2e215@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29wifi: rtw89: 8922a: extend RFK handling and consider MLOZong-Zhe Yang
Extend FW and driver handling on RFK to support it on both HW bands. Then, according to MLO cases, do the corresponding RF settings. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-6-pkshih@realtek.com
2024-10-29wifi: rtw89: tweak setting of channel and TX power for MLOZong-Zhe Yang
Setting of channel and TX power depend on channel contexts, but original code cannot handle combination of MCC (multi-channel concurrency) and MLO well. So according to active interfaces, we generate a table for current channel contexts. And then based on entity mode, we get the corresponding channel context to apply during channel or TX power setting. When MLO is supported, there will be dual-PHY and we will apply the channel context of the 2nd link to the 2nd PHY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-5-pkshih@realtek.com
2024-10-29usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device linksMathias Nyman
Fix a boot hang issue triggered when a USB3 device is incorrectly assumed to be tunneled over USB4, thus attempting to create a device link between the USB3 "consumer" device and the USB4 "supplier" Host Interface before the USB4 side is properly bound to a driver. This could happen if xhci isn't capable of detecting tunneled devices, but ACPI tables contain all info needed to assume device is tunneled. i.e. udev->tunnel_mode == USB_LINK_UNKNOWN. It turns out that even for actual tunneled USB3 devices it can't be assumed that the thunderbolt driver providing the tunnel is loaded before the tunneled USB3 device is created. The tunnel can be created by BIOS and remain in use by thunderbolt/USB4 host driver once it loads. Solve this by making the device link "stateless", which doesn't create a driver presence order dependency between the supplier and consumer drivers. It still guarantees correct suspend/resume and shutdown ordering. cc: Mario Limonciello <mario.limonciello@amd.com> Fixes: f1bfb4a6fed6 ("usb: acpi: add device link between tunneled USB3 device and USB4 Host Interface") Tested-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241024131355.3836538-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29wifi: rtw89: chan: manage active interfacesZong-Zhe Yang
To set channel well for combination of MCC (multi-channel concurrency) and impending MLO support, we need a method to manage relation between active interfaces and channel contexts. If an interface owns at least one active link, we call it an active interface. We add a list to manage active ones. Basically, the list follows the active order except for the below case. To be compatible with legacy behavior, the first interface that owns the first channel context will put at the first entry in the list when recalculating. Besides, MCC can also select and fill roles based on the above active list. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-4-pkshih@realtek.com
2024-10-29wifi: rtw89: Add encryption support for MLO connectionsPo-Hao Huang
In order to make encryption/decryption work properly with MLO connections, MLD address needs to be filled in so circuits can operate with the correct information. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com
2024-10-29Revert "usb: dwc2: Skip clock gating on Broadcom SoCs"Stefan Wahren
The commit d483f034f032 ("usb: dwc2: Skip clock gating on Broadcom SoCs") introduced a regression on Raspberry Pi 3 B Plus, which prevents enumeration of the onboard Microchip LAN7800 in case no external USB device is connected during boot. Fixes: d483f034f032 ("usb: dwc2: Skip clock gating on Broadcom SoCs") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20241025103621.4780-2-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29xhci: Fix Link TRB DMA in command ring stopped completion eventFaisal Hassan
During the aborting of a command, the software receives a command completion event for the command ring stopped, with the TRB pointing to the next TRB after the aborted command. If the command we abort is located just before the Link TRB in the command ring, then during the 'command ring stopped' completion event, the xHC gives the Link TRB in the event's cmd DMA, which causes a mismatch in handling command completion event. To address this situation, move the 'command ring stopped' completion event check slightly earlier, since the specific command it stopped on isn't of significant concern. Fixes: 7f84eef0dafb ("USB: xhci: No-op command queueing and irq handler.") Cc: stable@vger.kernel.org Signed-off-by: Faisal Hassan <quic_faisalh@quicinc.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20241022155631.1185-1-quic_faisalh@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29xhci: Use pm_runtime_get to prevent RPM on unsupported systemsBasavaraj Natikar
Use pm_runtime_put in the remove function and pm_runtime_get to disable RPM on platforms that don't support runtime D3, as re-enabling it through sysfs auto power control may cause the controller to malfunction. This can lead to issues such as hotplug devices not being detected due to failed interrupt generation. Fixes: a5d6264b638e ("xhci: Enable RPM on controllers that support low-power states") Cc: stable <stable@kernel.org> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241024133718.723846-1-Basavaraj.Natikar@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-24 13:31:34 +0000