summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-03-05dm-raid: really frozen sync_thread during suspendYu Kuai
1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend. Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won't hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. However, there is still a deadlock related to dm-raid456 that will be fixed in following patches. Reported-by: Mikulas Patocka <mpatocka@redhat.com> Closes: https://lore.kernel.org/all/e5e8afe2-e9a8-49a2-5ab0-958d4065c55e@redhat.com/ Fixes: 1af2048a3e87 ("dm raid: fix deadlock caused by premature md_stop_writes()") Fixes: 9dbd1aa3a81c ("dm raid: add reshaping support to the target") Fixes: f52f5c71f3d4 ("md: fix stopping sync thread") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Acked-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240305072306.2562024-6-yukuai1@huaweicloud.com
2024-03-05md: add a new helper reshape_interrupted()Yu Kuai
The helper will be used for dm-raid456 later to detect the case that reshape can't make progress. Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Acked-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240305072306.2562024-5-yukuai1@huaweicloud.com
2024-03-05md: export helper md_is_rdwr()Yu Kuai
There are no functional changes for now, prepare to fix a deadlock for dm-raid456. Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Acked-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240305072306.2562024-4-yukuai1@huaweicloud.com
2024-03-05md: export helpers to stop sync_threadYu Kuai
Add new helpers: void md_idle_sync_thread(struct mddev *mddev); void md_frozen_sync_thread(struct mddev *mddev); void md_unfrozen_sync_thread(struct mddev *mddev); The helpers will be used in dm-raid in later patches to fix regressions and prevent calling md_reap_sync_thread() directly. Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Acked-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240305072306.2562024-3-yukuai1@huaweicloud.com
2024-03-05md: don't clear MD_RECOVERY_FROZEN for new dm-raid until resumeYu Kuai
After commit 9dbd1aa3a81c ("dm raid: add reshaping support to the target") raid_ctr() will set MD_RECOVERY_FROZEN before md_run() and expect to keep array frozen until resume. However, md_run() will clear the flag by setting mddev->recovery to 0. Before commit 1baae052cccd ("md: Don't ignore suspended array in md_check_recovery()"), dm-raid actually relied on suspending to prevent starting new sync_thread. Fix this problem by keeping 'MD_RECOVERY_FROZEN' for dm-raid in md_run(). Fixes: 1baae052cccd ("md: Don't ignore suspended array in md_check_recovery()") Fixes: 9dbd1aa3a81c ("dm raid: add reshaping support to the target") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Acked-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20240305072306.2562024-2-yukuai1@huaweicloud.com
2024-03-05Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d""Song Liu
This reverts commit bed9e27baf52a09b7ba2a3714f1e24e17ced386d. The original set [1][2] was expected to undo a suboptimal fix in [2], and replace it with a better fix [1]. However, as reported by Dan Moulding [2] causes an issue with raid5 with journal device. Revert [2] for now to close the issue. We will follow up on another issue reported by Juxiao Bi, as [2] is expected to fix it. We believe this is a good trade-off, because the latter issue happens less freqently. In the meanwhile, we will NOT revert [1], as it contains the right logic. [1] commit d6e035aad6c0 ("md: bypass block throttle for superblock update") [2] commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") Reported-by: Dan Moulding <dan@danm.net> Closes: https://lore.kernel.org/linux-raid/20240123005700.9302-1-dan@danm.net/ Fixes: bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") Cc: stable@vger.kernel.org # v5.19+ Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20240125082131.788600-1-song@kernel.org
2024-03-05Merge tag 'platform-drivers-x86-v6.8-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: - Fix P2SB regression causing ACPI errors and high CPU load - Fix error return path in amd_pmf_init_smart_pc() * tag 'platform-drivers-x86-v6.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86/amd/pmf: Fix missing error code in amd_pmf_init_smart_pc() platform/x86: p2sb: On Goldmont only cache P2SB and SPI devfn BAR
2024-03-05spi: s3c64xx: switch exynos850 to new port config dataTudor Ambarus
Exynos850 has the same version of USI SPI (v2.1) as GS101. Drop the fifo_lvl_mask and rx_lvl_offset and switch to the new port config data. Backward compatibility with DT is not broken because when alises are set: - the SPI core will set the bus number according to the alias ID - the FIFO depth is always the same size for exynos850 (64 bytes) no matter the alias ID number. Advantages of the change: - drop dependency on the OF alias ID. - FIFO depth is inferred from the compatible. Exynos850 integrates 3 SPI IPs, all with 64 bytes FIFO depths. - use full mask for SPI_STATUS.{RX, TX}_FIFO_LVL fields. Using partial masks is misleading and can hide problems of the driver logic. Just compiled tested. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-13-tudor.ambarus@linaro.org Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: switch gs101 to new port config dataTudor Ambarus
Drop the fifo_lvl_mask and rx_lvl_offset and switch to the new port config data. Advantages of the change: - drop dependency on the OF alias ID. - FIFO depth is inferred from the compatible. GS101 integrates 16 SPI IPs, all with 64 bytes FIFO depths. - use full mask for SPI_STATUS.{RX, TX}_FIFO_LVL fields. Using partial masks is misleading and can hide problems of the driver logic. S3C64XX_SPI_ST_TX_FIFO_RDY_V2 was defined based on the USI's SPI_VERSION.USI_IP_VERSION register field, which has value 2 at reset. MAX_SPI_PORTS is updated to reflect the maximum number of ports for the rest of the compatibles. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-12-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: deprecate fifo_lvl_mask, rx_lvl_offset and port_idTudor Ambarus
Deprecate fifo_lvl_mask, rx_lvl_offset and port_id. One shall use {rx, tx}_fifomask instead. Add messages to each port configuration. Suggested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-11-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: get rid of the OF alias ID dependencyTudor Ambarus
Compatibles that set ``port_conf->{rx, tx}_fifomask`` are now safe to get rid of the OF alias ID dependency. Let the driver probe even without the alias for these. With this we also protect the FIFO_LVL_MASK calls from s3c64xx_spi_set_fifomask(). Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-10-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: introduce s3c64xx_spi_set_port_id()Tudor Ambarus
Prepare driver to get rid of the of alias ID dependency. Split the port_id logic into a dedicated method. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-9-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: let the SPI core determine the bus numberTudor Ambarus
Let the core determine the bus number, either by getting the alias ID (as the driver forces now), or by allocating a dynamic bus number when the alias is absent. Prepare the driver to allow dt aliases to be absent. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-8-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: allow FIFO depth to be determined from the compatibleTudor Ambarus
There are SoCs that use the same FIFO depth for all the instances of the SPI IP. See the fifo_lvl_mask defined for gs101 for example: .fifo_lvl_mask = { 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f}, Instead of specifying the FIFO depth with the same value for all 16 nodes in this case, allow such SoCs to infer the FIFO depth from the compatible. There are other SoCs than can benefit of this, see: {gs101, fsd, exynos850, s3c641, s3c2443}_spi_port_config. The FIFO depth inferred from the compatible has a higher precedence than the one that might be specified via device tree, the driver shall know better. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-7-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: retrieve the FIFO depth from the device treeTudor Ambarus
There are SoCs that configure different FIFO depths for their instances of the SPI IP. See the fifo_lvl_mask defined for exynos4_spi_port_config for example: .fifo_lvl_mask = { 0x1ff, 0x7F, 0x7F }, The first instance of the IP is configured with 256 bytes FIFOs, whereas the last two are configured with 64 bytes FIFOs. Instead of mangling with the .fifo_lvl_mask and its dependency of the DT alias ID, allow such SoCs to determine the FIFO depth via the ``fifo-depth`` DT property. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-6-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: determine the fifo depth only onceTudor Ambarus
Determine the FIFO depth only once, at probe time. ``sdd->fifo_depth`` can be set later on with the FIFO depth specified in the device tree. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-5-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: allow full FIFO masksTudor Ambarus
The driver is wrong because is using partial register field masks for the SPI_STATUS.{RX, TX}_FIFO_LVL register fields. We see s3c64xx_spi_port_config.fifo_lvl_mask with different values for different instances of the same IP. Take s5pv210_spi_port_config for example, it defines: .fifo_lvl_mask = { 0x1ff, 0x7F }, fifo_lvl_mask is used to determine the FIFO depth of the instance of the IP. In this case, the integrator uses a 256 bytes FIFO for the first SPI instance of the IP, and a 64 bytes FIFO for the second instance. While the first mask reflects the SPI_STATUS.{RX, TX}_FIFO_LVL register fields, the second one is two bits short. Using partial field masks is misleading and can hide problems of the driver's logic. Allow platforms to specify the full FIFO mask, regardless of the FIFO depth. Introduce {rx, tx}_fifomask to represent the SPI_STATUS.{RX, TX}_FIFO_LVL register fields. It's a shifted mask defining the field's length and position. We'll be able to deprecate the use of @rx_lvl_offset, as the shift value can be determined from the mask. The existing compatibles shall start using {rx, tx}_fifomask so that they use the full field mask and to avoid shifting the mask to position, and then shifting it back to zero in the {TX, RX}_FIFO_LVL macros. @rx_lvl_offset will be deprecated in a further patch, after we have the infrastructure to deprecate @fifo_lvl_mask as well. No functional change intended. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-4-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05spi: s3c64xx: define a magic valueTudor Ambarus
Define a magic value, it will be used in the next patch as well. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216070555.2483977-3-tudor.ambarus@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05Merge tag 'hyperv-fixes-signed-20240303' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - Multiple fixes, cleanups and documentations for Hyper-V core code and drivers * tag 'hyperv-fixes-signed-20240303' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: Drivers: hv: vmbus: make hv_bus const x86/hyperv: Allow 15-bit APIC IDs for VTL platforms x86/hyperv: Make encrypted/decrypted changes safe for load_unaligned_zeropad() x86/mm: Regularize set_memory_p() parameters and make non-static x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback Documentation: hyperv: Add overview of PCI pass-thru device support Drivers: hv: vmbus: Update indentation in create_gpadl_header() Drivers: hv: vmbus: Remove duplication and cleanup code in create_gpadl_header() fbdev/hyperv_fb: Fix logic error for Gen2 VMs in hvfb_getmem() Drivers: hv: vmbus: Calculate ring buffer size for more efficient use of memory hv_utils: Allow implicit ICTIMESYNCFLAG_SYNC
2024-03-05thermal: intel: int340x_thermal: Use thermal zone accessor functionsRafael J. Wysocki
Make int340x_thermal use the dedicated accessor functions for the thermal zone device object address and the thermal zone type string. This is requisite for future thermal core improvements. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2024-03-05Merge thermal core changes for 6.9 to satisfy a dependency.Rafael J. Wysocki
2024-03-05ACPI: resource: Use IRQ override on Maibenben X565Sergey Kalinichev
Use ACPI IRQ override on Maibenben X565 laptop to make the internal keyboard work. Add a new entry to the irq1_edge_low_force_override structure, similar to the existing ones. Signed-off-by: Sergey Kalinichev <kalinichev.so.0@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-05ACPI: CPPC: Use access_width over bit_width for system memory accessesJarred White
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ [ rjw: Subject and changelog edits, comment adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-05cpuidle: ACPI/intel: fix MWAIT hint target C-state computationHe Rongguang
According to x86 spec ([1] and [2]), MWAIT hint_address[7:4] plus 1 is the corresponding C-state, and 0xF means C0. ACPI C-state table usually only contains C1+, but nothing prevents ACPI firmware from presenting a C-state (maybe C1+) but using MWAIT address C0 (i.e., 0xF in ACPI FFH MWAIT hint address). And if this is the case, Linux erroneously treat this cstate as C16, while actually this should be valid C0 instead of C16, as per the specifications. Since ACPI firmware is out of Linux kernel scope, fix the kernel handling of 0xF ->(to) C0 in this situation. This is found when a tweaked ACPI C-state table is presented by Qemu to VM. Also modify the intel_idle case for code consistency. [1]. Intel SDM Vol 2, Table 4-11. MWAIT Hints Register (EAX): "Value of 0 means C1; 1 means C2 and so on Value of 01111B means C0". [2]. AMD manual Vol 3, MWAIT: "The processor C-state is EAX[7:4]+1, so to request C0 is to place the value F in EAX[7:4] and to request C1 is to place the value 0 in EAX[7:4].". Signed-off-by: He Rongguang <herongguang@linux.alibaba.com> [ rjw: Subject and changelog edits, whitespace fixups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-05drm/i915/dp: Fix connector DSC HW state readoutImre Deak
The DSC HW state of DP connectors is read out during driver loading and system resume in intel_modeset_update_connector_atomic_state(). This function is called for all connectors though and so the state of DSI connectors will also get updated incorrectly, triggering a WARN there wrt. the DSC decompression AUX device. Fix the above by moving the DSC state readout to a new DP connector specific sync_state() hook. This is anyway the logical place to update the connector object's state vs. the connector's atomic state. Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by: Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205132631.1588577-1-imre.deak@intel.com
2024-03-05ptp: fc3: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240304091325.717546-2-u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: wwan: core: make wwan_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the wwan_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-5-8fa378595b93@marliere.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: wwan: hwsim: make wwan_hwsim_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the wwan_hwsim_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-4-8fa378595b93@marliere.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: ppp: make ppp_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the ppp_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-3-8fa378595b93@marliere.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: wan: framer: make framer_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the framer_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-2-8fa378595b93@marliere.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: hns: make hnae_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the hnae_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240302-class_cleanup-net-next-v1-1-8fa378595b93@marliere.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05regulator: core: make regulator_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the regulator_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://msgid.link/r/20240305-class_cleanup-regulator-v1-1-4950345d6d8f@marliere.net Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-05net: phy: micrel: lan8814 cable improvement errataHoratiu Vultur
When the length of the cable is more than 100m and the lan8814 is configured to run in 1000Base-T Slave then the register of the device needs to be optimized. Workaround this by setting the measure time to a value of 0xb. This value can be set regardless of the configuration. This issue is described in 'LAN8814 Silicon Errata and Data Sheet Clarification' and according to that, this will not be corrected in a future silicon revision. Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240304091548.1386022-3-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05net: phy: micrel: lan8814 led errataHoratiu Vultur
Lan8814 phy led behavior is not correct. It was noticed that the led still remains ON when the cable is unplugged while there was traffic passing at that time. The fix consists in clearing bit 10 of register 0x38, in this way the led behaviour is correct and gets OFF when there is no link. Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240304091548.1386022-2-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05Merge tag 'ath-next-20240305' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath ath.git patches for v6.9 Only some minor cleanup in ath11k and ath12k. Adding Jeff as the maintainer for ath10k, ath11k and ath12k DT bindings.
2024-03-05wifi: rtw89: wow: move release offload packet earlier for WoWLAN modeChin-Yen Lee
Now WoWLAN firmware will disable PCIE DMA after driver call cfg_wake function, and it will lead to release offload packet fail because driver can't receive completion notification from firmware. We move release offload packet earlier to avoid this error. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-8-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: set security engine options for 802.11ax chips onlyChin-Yen Lee
The security engine is set for management frames by default for 802.11be chips, so no need to set it in WoWLAN flow. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-7-pkshih@realtek.com
2024-03-05wifi: rtw89: update suspend/resume for different generationChin-Yen Lee
The setting during suspend or resume is different between different generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-6-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update config mac function with different generationChin-Yen Lee
The registers to configure mac function for WoWLAN mode that are different from different generation, so update them. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-5-pkshih@realtek.com
2024-03-05wifi: rtw89: update DMA function with different generationChin-Yen Lee
The register of control and polling function for TX/RX DMA is different from different generation, so update them. Also rename polling_dma function to polling_dma_idle to avoid misunderstanding. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-4-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update WoWLAN status register for different generationChin-Yen Lee
The statue register is for driver to check if WoWLAN mode works or stops successfully. It is changed for new generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-3-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update WoWLAN reason register for different chipsChin-Yen Lee
The WoWLAN reason register is used for driver to get the wakeup reason for reporting to cfg80211, and it is different from chips. So put it into chip information. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-2-pkshih@realtek.com
2024-03-05wifi: brcm80211: handle pmk_op allocation failureDuoming Zhou
The kzalloc() in brcmf_pmksa_v3_op() will return null if the physical memory has run out. As a result, if we dereference the null value, the null pointer dereference bug will happen. Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails for pmk_op. Fixes: a96202acaea4 ("wifi: brcmfmac: cfg80211: Add support for PMKID_V3 operations") Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229103153.18533-1-duoming@zju.edu.cn
2024-03-05wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERRChing-Te Ku
The 2 Bluetooth profiles (Hands free profile & Human interface device) have high duty transmission, it will affect the traffic of WiFi packet frequently. And once the WiFi traffic down to B/G mode, it will need a better success rate to recover the transmission rate. Add new policy option to solve the above situation. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-9-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: When Bluetooth not available don't set power/gainChing-Te Ku
If Bluetooth is working, it will update their info regularly. And the code will increase the counters while the info updating. Use this counter to judge is Bluetooth working or not. Don't need to set Bluetooth power or gain when it is not working. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-8-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add return value to ensure H2C command is success or notChing-Te Ku
Add return value to H2C function, and only record down the value while H2C command success, this can help us to check the real time status. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-7-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: Reorder H2C command index to align with firmwareChing-Te Ku
Wi-Fi firmware need some driver information to do decision or do some real-time control. Driver will update these information by H2C command. The chip 8922a H2C command index is different from before chips/branch, so need to assign the correct index to let firmware parsing. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-6-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add BTC ctrl_info version 7 and related logicChing-Te Ku
Change structure member from bit field to normal variable to reduce unnecessary translation. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-5-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add init_info H2C command format version 7Ching-Te Ku
To avoid using bit fields for H2C command, rearrange the structure. And also patch the corresponding code for the using of this structure. No logic changes for existing chips. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-4-pkshih@realtek.com
2024-03-05wifi: rtw89: 8922a: add coexistence helpers of SW grantPing-Ke Shih
Under some circumstances, coexistence mechanism want to keep grant BT or WiFi, such as inquiry and WiFi is connecting, to ensure BT or WiFi can transmit or receive data in that period. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-3-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-09-19 03:50:28 +0000