summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-15pwm: mediatek: Initialize clks when the hardware is enabled at probe timeUwe Kleine-König
When a PWM is already configured by the bootloader (e.g. to power a backlight), the clk enable count must be increased to keep clock usage balanced. So check which PWMs are enabled during probe and enable the respective clocks. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250725154506.2610172-14-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: mediatek: Rework parameters for clk helper functionUwe Kleine-König
Convert pwm_mediatek_clk_enable() and pwm_mediatek_clk_disable() to take lower level parameters. This enables these functions to be used in the next commit when there is no valid pwm_chip and pwm_device yet. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250725154506.2610172-13-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: mediatek: Introduce and use a few more register definesUwe Kleine-König
Instead of using a magic constant for bound checking, derive the numbers from appropriate register defines. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250725154506.2610172-12-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: mediatek: Simplify representation of channel offsetsUwe Kleine-König
The general register layout contains some per-chip registers starting at offset 0 and then at a higher address there are n nearly identical and equidistant blocks for the registers of the n channels. This allows to represent the offsets of per-channel registers as $base + i * $width instead of listing all (or too many) offsets explicitly in an array. So for a small additional effort in pwm_mediatek_writel() the three arrays with the channel offsets can be dropped. The size changes according to bloat-o-meter are: add/remove: 0/3 grow/shrink: 1/0 up/down: 12/-96 (-84) Function old new delta pwm_mediatek_apply 696 708 +12 mtk_pwm_reg_offset_v3 32 - -32 mtk_pwm_reg_offset_v2 32 - -32 mtk_pwm_reg_offset_v1 32 - -32 Total: Before=5347, After=5263, chg -1.57% Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250725154506.2610172-11-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: tiecap: Document behaviour of hardware disableUwe Kleine-König
According to David Lechner[1] disabling a tiecap PWM makes the PWM pin an input. The reported problem is fixed in commit deaeeda2051f ("backlight: pwm_bl: Don't rely on a disabled PWM emiting inactive state"). Document the behaviour in the driver for future reference. [1] https://lore.kernel.org/linux-pwm/39a472c0-ba24-de7b-8783-a16a71b172cd@lechnology.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20250730080219.183181-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: Provide a gpio device for waveform driversUwe Kleine-König
A PWM is a more general concept than an output-only GPIO. When using duty_length = period_length the PWM looks like an active GPIO, with duty_length = 0 like an inactive GPIO. With the waveform abstraction there is enough control over the configuration to ensure that PWMs that cannot generate a constant signal at both levels error out. The pwm-pca9685 driver already provides a gpio chip. When this driver is converted to the waveform callbacks, the gpio part can just be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250717151117.1828585-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: Check actual period and duty_cycle for ignored polarity testUwe Kleine-König
When a lowlevel driver configures the wrong period that might (historically) be ok if the emitted signal has a 100% relative duty_cycle as that just corresponds to rounding down the duty_cycle to 0 which is an allowed thing to do for a lowlevel driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/bc511c0250ea2f6390e4209ab1ea9c08a3c18612.1751994988.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: Disable PWM_DEBUG check for disabled statesUwe Kleine-König
When a PWM is requested to be disabled, the result is unspecified, the only intention is to save some power. So skip all checks in this case. All but two checks already only triggered for states with .enabled = true. The first resulted in some false positive diagnostics, the other checked for a condition that depending on hardware might not be implementable. Similar if the lowlevel driver disabled the hardware this might be a valid reaction and with .enabled = false all other state parameters are unreliable, so skip further tests in this case, too. All later usages of .enabled can be assumed to yield true, and so several if conditions can be simplified. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/16d29212b09b66c286c1232b1ab0ec0f8d510aae.1751994988.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15dt-bindings: timer: renesas,rz-mtu3: Use #pwm-cells = <3>Uwe Kleine-König
With the goal to unify all PWM bindings to use #pwm-cells = <3> update the renesas,rz-mtu3 binding accordingly. Keep <2> documented as a deprecated value at least until the in-tree device trees are fixed accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250527205823.377785-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: tiehrpwm: Fix corner case in clock divisor calculationUwe Kleine-König
The function set_prescale_div() is responsible for calculating the clock divisor settings such that the input clock rate is divided down such that the required period length is at most 0x10000 clock ticks. If period_cycles is an integer multiple of 0x10000, the divisor period_cycles / 0x10000 is good enough. So round up in the calculation of the required divisor and compare it using >= instead of >. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/85488616d7bfcd9c32717651d0be7e330e761b9c.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculationUwe Kleine-König
In Up-Count Mode the timer is reset to zero one tick after it reaches TBPRD, so the period length is (TBPRD + 1) * T_TBCLK. This matches both the documentation and measurements. So the value written to the TBPRD has to be one less than the calculated period_cycles value. A complication here is that for a 100% relative duty-cycle the value written to the CMPx register has to be TBPRD + 1 which might overflow if TBPRD is 0xffff. To handle that the calculation of the AQCTLx register has to be moved to ehrpwm_pwm_config() and the edge at CTR = CMPx has to be skipped. Additionally the AQCTL_PRD register field has to be 0 because that defines the hardware's action when the maximal counter value is reached, which is (as above) one clock tick before the period's end. The period start edge has to happen when the counter is reset and so is defined in the AQCTL_ZRO field. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/dc818c69b7cf05109ecda9ee6b0043a22de757c1.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: tiehrpwm: Make code comment in .free() more usefulUwe Kleine-König
Instead of explaining trivia to everyone who can read C describe the higher-level effect of setting pc->period_cycles[pwm->hwpwm] to zero. Fixes: 01b2d4536f02 ("pwm: pwm-tiehrpwm: Fix conflicting channel period setting") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/4c38dd119a77d7017115318a3f2c50bde62a6f21.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: tiehrpwm: Don't drop runtime PM reference in .free()Uwe Kleine-König
The pwm driver calls pm_runtime_get_sync() when the hardware becomes enabled and pm_runtime_put_sync() when it becomes disabled. The PWM's state is kept when a consumer goes away, so the call to pm_runtime_put_sync() in the .free() callback is unbalanced resulting in a non-functional device and a reference underlow for the second consumer. The easiest fix for that issue is to just not drop the runtime PM reference in .free(), so do that. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/bbb089c4b5650cc1f7b25cf582d817543fd25384.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: Fix incorrect variable used in error messageColin Ian King
The dev_err message is reporting the incorrect return value ret_tohw, it should be reporting the value in ret_fromhw. Fix this by using ret_fromhw instead of ret_tohw. Fixes: 6c5126c6406d ("pwm: Provide new consumer API functions for waveforms") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250902130348.2630053-1-colin.i.king@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: berlin: Fix wrong register in suspend/resumeJisheng Zhang
The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume. Fixes: bbf0722c1c66 ("pwm: berlin: Add suspend/resume support") Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20250819114224.31825-1-jszhang@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15pwm: loongson: Fix LOONGSON_PWM_FREQ_DEFAULTXi Ruoyao
Per the 7A1000 and 7A2000 user manual, the clock frequency of their PWM controllers is 50 MHz, not 50 kHz. Fixes: 2b62c89448dd ("pwm: Add Loongson PWM controller support") Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Binbin Zhou <zhoubinbin@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/r/20250816104904.4779-2-xry111@xry111.site Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-09-15xfrm: fix offloading of cross-family tunnelsSabrina Dubroca
Xiumei reported a regression in IPsec offload tests over xfrmi, where the traffic for IPv6 over IPv4 tunnels is processed in SW instead of going through crypto offload, after commit cc18f482e8b6 ("xfrm: provide common xdo_dev_offload_ok callback implementation"). Commit cc18f482e8b6 added a generic version of existing checks attempting to prevent packets with IPv4 options or IPv6 extension headers from being sent to HW that doesn't support offloading such packets. The check mistakenly uses x->props.family (the outer family) to determine the inner packet's family and verify if options/extensions are present. In the case of IPv6 over IPv4, the check compares some of the traffic class bits to the expected no-options ihl value (5). The original check was introduced in commit 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data path"), and then duplicated in the other drivers. Before commit cc18f482e8b6, the loose check (ihl > 5) passed because those traffic class bits were not set to a value that triggered the no-offload codepath. Packets with options/extension headers that should have been handled in SW went through the offload path, and were likely dropped by the NIC or incorrectly processed. Since commit cc18f482e8b6, the check is now strict (ihl != 5), and in a basic setup (no traffic class configured), all packets go through the no-offload codepath. The commits that introduced the incorrect family checks in each driver are: 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data path") 8362ea16f69f ("crypto: chcr - ESN for Inline IPSec Tx") 859a497fe80c ("nfp: implement xfrm callbacks and expose ipsec offload feature to upper layer") 32188be805d0 ("cn10k-ipsec: Allow ipsec crypto offload for skb with SA") [ixgbe/ixgbevf commits are ignored, as that HW does not support tunnel mode, thus no cross-family setups are possible] Fixes: cc18f482e8b6 ("xfrm: provide common xdo_dev_offload_ok callback implementation") Reported-by: Xiumei Mu <xmu@redhat.com> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2025-09-15KVM: arm64: Fix debug checking for np-guests using huge mappingsBen Horgan
When running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then the debug checking in assert_host_shared_guest() fails on the launch of an np-guest. This WARN_ON() causes a panic and generates the stack below. In __pkvm_host_relax_perms_guest() the debug checking assumes the mapping is a single page but it may be a block map. Update the checking so that the size is not checked and just assumes the correct size. While we're here make the same fix in __pkvm_host_mkyoung_guest(). Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128 Info: Removed ghost socket file "/.lkvm//guest-128.sock". [ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088! [ 1406.521804] kvm [141]: nVHE call trace: [ 1406.521828] kvm [141]: [<ffff8000811676b4>] __kvm_nvhe_hyp_panic+0xb4/0xe8 [ 1406.521946] kvm [141]: [<ffff80008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c [ 1406.522049] kvm [141]: [<ffff80008116f068>] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104 [ 1406.522157] kvm [141]: [<ffff800081169df8>] __kvm_nvhe_handle___pkvm_host_relax_perms_guest+0x64/0x7c [ 1406.522250] kvm [141]: [<ffff800081169f0c>] __kvm_nvhe_handle_trap+0x8c/0x1a8 [ 1406.522333] kvm [141]: [<ffff8000811680fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 [ 1406.522454] kvm [141]: ---[ end nVHE call trace ]--- [ 1406.522477] kvm [141]: Hyp Offset: 0xfffece8013600000 [ 1406.522554] Kernel panic - not syncing: HYP panic: [ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.522554] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.522554] VCPU:0000000000000000 [ 1406.523337] CPU: 3 UID: 0 PID: 141 Comm: kvm-vcpu-0 Not tainted 6.16.0-rc7 #97 PREEMPT [ 1406.523485] Hardware name: FVP Base RevC (DT) [ 1406.523566] Call trace: [ 1406.523629] show_stack+0x18/0x24 (C) [ 1406.523753] dump_stack_lvl+0xd4/0x108 [ 1406.523899] dump_stack+0x18/0x24 [ 1406.524040] panic+0x3d8/0x448 [ 1406.524184] nvhe_hyp_panic_handler+0x10c/0x23c [ 1406.524325] kvm_handle_guest_abort+0x68c/0x109c [ 1406.524500] handle_exit+0x60/0x17c [ 1406.524630] kvm_arch_vcpu_ioctl_run+0x2e0/0x8c0 [ 1406.524794] kvm_vcpu_ioctl+0x1a8/0x9cc [ 1406.524919] __arm64_sys_ioctl+0xac/0x104 [ 1406.525067] invoke_syscall+0x48/0x10c [ 1406.525189] el0_svc_common.constprop.0+0x40/0xe0 [ 1406.525322] do_el0_svc+0x1c/0x28 [ 1406.525441] el0_svc+0x38/0x120 [ 1406.525588] el0t_64_sync_handler+0x10c/0x138 [ 1406.525750] el0t_64_sync+0x1ac/0x1b0 [ 1406.525876] SMP: stopping secondary CPUs [ 1406.525965] Kernel Offset: disabled [ 1406.526032] CPU features: 0x0000,00000080,8e134ca1,9446773f [ 1406.526130] Memory Limit: none [ 1406.959099] ---[ end Kernel panic - not syncing: HYP panic: [ 1406.959099] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.959099] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.959099] VCPU:0000000000000000 ] Signed-off-by: Ben Horgan <ben.horgan@arm.com> Fixes: f28f1d02f4eaa ("KVM: arm64: Add a range to __pkvm_host_unshare_guest()") Cc: Vincent Donnefort <vdonnefort@google.com> Cc: Quentin Perret <qperret@google.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: stable@vger.kernel.org Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-15Merge branch kvm-arm64/ffa-1.2 into kvmarm-master/nextMarc Zyngier
* kvm-arm64/ffa-1.2: : . : FFA 1.2 support for pKVM, courtesy of Per Larsen. : : From the cover letter at [1]: : : "The FF-A 1.2 specification introduces a new SEND_DIRECT2 ABI which : allows registers x4-x17 to be used for the message payload. This patch : set prevents the host from using a lower FF-A version than what has : already been negotiated with the hypervisor. This is necessary because : the hypervisor does not have the necessary compatibility paths to : translate from the hypervisor FF-A version to a previous version." : : [1] https://lore.kernel.org/r/20250820-virtio-msg-ffa-v11-0-497ef43550a3@google.com : . KVM: arm64: Bump the supported version of FF-A to 1.2 KVM: arm64: Mask response to FFA_FEATURE call KVM: arm64: Mark optional FF-A 1.2 interfaces as unsupported KVM: arm64: Mark FFA_NOTIFICATION_* calls as unsupported KVM: arm64: Use SMCCC 1.2 for FF-A initialization and in host handler KVM: arm64: Correct return value on host version downgrade attempt Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-15drm: gud: replace WARN_ON/WARN_ON_ONCE with drm versionsRuben Wauters
GUD is a drm driver, and therefore should use the drm versions of WARN_ON and WARN_ON_ONCE. This patch replaces all instances of WARN_ON and WARN_ON_ONCE with drm_WARN_ON and drm_WARN_ON_ONCE. Signed-off-by: Ruben Wauters <rubenru09@aol.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250914155308.2144-1-rubenru09@aol.com
2025-09-15Merge drm/drm-next into drm-misc-next-fixesThomas Zimmermann
Backmerging to drm-misc-next-fixes to get features and fixes from v6.17-rc6. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-09-15wifi: iwlwifi: pcie: fix byte count table for some devicesJohannes Berg
In my previous fix for this condition, I erroneously listed 9000 instead of 7000 family, when 7000/8000 were already using iwlmvm. Thus the condition ended up wrong, causing the issue I had fixed for older devices to suddenly appear on 7000/8000 family devices. Correct the condition accordingly. Reported-by: David Wang <00107082@163.com> Closes: https://lore.kernel.org/r/20250909165811.10729-1-00107082@163.com/ Fixes: 586e3cb33ba6 ("wifi: iwlwifi: fix byte count table for old devices") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250915102743.777aaafbcc6c.I84404edfdfbf400501f6fb06def5b86c501da198@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-09-15powerpc/603: Really copy kernel PGD entries into all PGDIRsChristophe Leroy
Commit 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables") was supposed to extend to powerpc 603 the copy of kernel PGD entries into all PGDIRs implemented in a previous patch on the 8xx. But 603 is book3s/32 and uses a duplicate of pgd_alloc() defined in another header. So really do the copy at the correct place for the 603. Fixes: 82ef440f9a38 ("powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/752ab7514cae089a2dd7cc0f3d5e35849f76adb9.1755757797.git.christophe.leroy@csgroup.eu
2025-09-15powerpc/8xx: Remove left-over instruction and comments in DataStoreTLBMiss ↵Christophe Leroy
handler Commit ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") removed the test that needed the valeur in SPRN_EPN but failed to remove the read. Remove it. And remove related comments, including the very same comment in InstructionTLBMiss that should have been removed by commit 33c527522f39 ("powerpc/8xx: Inconditionally use task PGDIR in ITLB misses"). Also update the comment about absence of a second level table which has been handled implicitely since commit 5ddb75cee5af ("powerpc/8xx: remove tests on PGDIR entry validity"). Fixes: ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/5811c8d1d6187f280ad140d6c0ad6010e41eeaeb.1755361995.git.christophe.leroy@csgroup.eu
2025-09-15RDMA/mana_ib: Extend modify QPShiraz Saleem
Extend modify QP to support further attributes: local_ack_timeout, UD qkey, rate_limit, qp_access_flags, flow_label, max_rd_atomic. Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/1757923172-4475-1-git-send-email-kotaranov@linux.microsoft.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-15powerpc/pseries: HVPIPE changes to support migrationHaren Myneni
The hypervisor assigns one pipe per partition for all sources and assigns new pipe after migration. Also the partition ID that is used by source as its target ID may be changed after the migration. So disable hvpipe during SUSPEND event with ‘hvpipe enable’ system parameter value = 0 and enable it after migration during RESUME event with hvpipe enable’ system parameter value = 1. The user space calls such as ioctl()/ read() / write() / poll() returns -ENXIO between SUSPEND and RESUME events. The user space process can close FD and reestablish connection with new FD after migration if needed (Example: source IDs are changed). Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-10-haren@linux.ibm.com
2025-09-15powerpc/pseries: Enable hvpipe with ibm,set-system-parameter RTASHaren Myneni
The partition uses “Hypervisor Pipe OS Enablement Notification” system parameter token (value = 64) to enable / disable hvpipe in the hypervisor. Once hvpipe is enabled, the hypervisor notifies OS if the payload is pending for that partition from any source. This system parameter token takes 1 byte length of data with 1 = Enable and 0 = Disable. Enable hvpipe in the hypervisor with ibm,set-system-parameter RTAS after registering hvpipe event source interrupt. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-9-haren@linux.ibm.com
2025-09-15powerpc/pseries: Enable HVPIPE event message interruptHaren Myneni
The hypervisor signals the OS via a Hypervisor Pipe Event external interrupt when data is available to be received from the pipe. Then the OS should call RTAS check-exception and provide the input Event Mask as defined for the ‘ibm,hvpipe-msg-events’. In response, check-exception will return an event log containing an Pipe Events message. This message contains the source ID for which this message is intended to and the pipe status such as whether the payload is pending in the hypervisor or pipe to source is closed. If there is any user space process waiting in the wait_queue for the payload from this source ID, wake up that process which can issue read() to obtain payload with ibm,receive-hvpipe-msg RTAS or close FD if the pipe to source is closed. The hypervisor has one pipe per partition for all sources and it will not deliver another hvpipe event message until the partition reads the payload for the previous hvpipe event. So if the source ID is not found in the source list, issue the dummy ibm,receive-hvpipe-msg RTAS so that pipe will not blocked. Register hvpipe event source interrupt based on entries from /proc/device-tree//event-sources/ibm,hvpipe-msg-events property. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-8-haren@linux.ibm.com
2025-09-15powerpc/pseries: Wakeup hvpipe FD when the payload is pendingHaren Myneni
The user space polls on the wait_queue for the payload from the specific source. The hypervisor interrupts the OS when the pipe status for the specific source is changed such as payload is available for the partition or pipe to the source is closed. The OS retrieves the HVPIPE event message with check-exception RTAS and event message contains the source ID and the pipe status. Then wakes up all FDs waiting on the wait_queue so that the user space can read the payload or close the FD if the pipe to source in the hypervisor is closed. The hypervisor assigns one pipe per partition for all sources. Hence issue ibm,receive-hvpipe-msg() to read the pending payload during release() before closing FD so that pipe to the partition will not be blocked. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-7-haren@linux.ibm.com
2025-09-15powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTASHaren Myneni
ibm,receive-hvpipe-msg RTAS call is used to receive data from the source (Ex: Hardware Management Console) over the hypervisor pipe. The hypervisor will signal the OS via a Hypervisor Pipe Event external interrupt when data is available to be received from the pipe and the event message has the source ID and the message type such as payload or closed pipe to the specific source. The hypervisor will not generate another interrupt for the next payload until the partition reads the previous payload. It means the hvpipe is blocked and will not deliver other events for any source. The maximum data length of 4048 bytes is supported with this RTAS call right now. The user space uses read() to receive data from HMC which issues ibm,receive-hvpipe-msg RTAS and the kernel returns the buffer length (including papr_hvpipe_hdr length) to the user space for success or RTAS failure error. If the message is regarding the pipe closed, kernel just returns the papr_hvpipe_hdr with flags = HVPIPE_LOST_CONNECTION and expects the user space to close FD for the corresponding source. ibm,receive-hvpipe-msg RTAS call passes the buffer and returns the source ID from where this payload is received and the payload length. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-6-haren@linux.ibm.com
2025-09-15powerpc/pseries: Send payload with ibm,send-hvpipe-msg RTASHaren Myneni
ibm,send-hvpipe-msg RTAS call is used to send data to the source (Ex: Hardware Management Console) over the hypervisor pipe. The maximum data length of 4048 bytes is supported with this RTAS call right now. The user space uses write() to send this payload which invokes this RTAS. Then the write returns the buffer length (including papr_hvpipe_hdr length) to the user space for success or RTAS failure error. ibm,send-hvpipe-msg call takes source ID as target and the buffer in the form of buffer list. The buffer list format consists of work area of size 4K to hold buffer list and number of 4K work areas depends on buffers is as follows: Length of Buffer List in bytes Address of 4K buffer 1 Length of 4K buffer 1 used ... Address of 4K buffer n Length of 4K buffer n used Only one buffer is used right now because of max payload size is 4048 bytes. writev() can be used in future when supported more than one buffer. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-5-haren@linux.ibm.com
2025-09-15powerpc/pseries: Add papr-hvpipe char driver for HVPIPE interfacesHaren Myneni
The hypervisor provides ibm,send-hvpipe-msg and ibm,receive-hvpipe-msg RTAS calls which can be used by the partition to communicate through an inband hypervisor channel with different external sources such as Hardware Management Console (HMC). The information exchanged, whether it be messages, raw or formatted data, etc., is only known to between applications in the OS and the source (HMC). This patch adds papr-hvpipe character driver and provides the standard interfaces such as open / ioctl/ read / write to user space for exchanging information with HMC using send/recevive HVPIPE RTAS functions. PAPR (7.3.32 Hypervisor Pipe Information Exchange) defines the HVPIPE usage: - The hypervisor has one HVPIPE per partition for all sources. - OS can determine this feature’s availability by detecting the “ibm,hypervisor-pipe-capable” property in the /rtas node of the device tree. - Each source is represented by the source ID which is used in send / recv HVPIPE RTAS. (Ex: source ID is the target for the payload in send RTAS). - Return status of ibm,send-hvpipe-msg can be considered as delivered the payload. - Return status of ibm,receive-hvpipe-msg can be considered as ACK to source. - The hypervisor generates hvpipe message event interrupt when the partition has the payload to receive. Provide the interfaces to the user space with /dev/papr-hvpipe character device using the following programming model: int devfd = open("/dev/papr-hvpipe") int fd = ioctl(devfd, PAPR_HVPIPE_IOC_CREATE_HANDLE, &srcID); - Restrict the user space to use the same source ID and do not expect more than one process access with the same source. char *buf = malloc(size); - SIZE should be 4K and the buffer contains header and the payload. length = write(fd, buf, size); - OS issues ibm,send-hvpipe-msg RTAS and returns the RTAS status to the user space. ret = poll(fd,...) - The HVPIPE event message IRQ wakes up for any waiting FDs. length = read(fd, buf, size); - OS issues ibm,receive-hvpipe-msg to receive payload from the hypervisor. release(fd); - OS issues ibm,receive-hvpipe-msg if any payload is pending so that pipe is not blocked. The actual implementation of these calls are added in the next patches. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-4-haren@linux.ibm.com
2025-09-15powerpc/pseries: Define HVPIPE specific macrosHaren Myneni
Define HVPIPE specific macros which are needed to support ibm,send-hvpipe-msg and ibm,receive-hvpipe-msg RTAS calls and used to handle HVPIPE message events. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-3-haren@linux.ibm.com
2025-09-15powerpc/pseries: Define papr-hvpipe ioctlHaren Myneni
PowerPC FW introduced HVPIPE RTAS calls such as ibm,send-hvpipe-msg and ibm,receive-hvpipe-msg for the user space to exchange information with different sources such as Hardware Management Consoles (HMC). HVPIPE_IOC_CREATE_HANDLE is defined to use /dev/papr-hvpipe interface for ibm,send-hvpipe-msg and ibm,receive-hvpipe-msg RTAS calls. Also defined papr_hvpipe_hdr which will added in the payload that is passed between the kernel and the user space. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Shashank MS <shashank.gowda@in.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250909084402.1488456-2-haren@linux.ibm.com
2025-09-15Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to drm-misc-next to get fixes from v6.17-rc6. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-09-15Merge tag 'v6.17-rc6' into drm-nextDave Airlie
This is a backmerge of Linux 6.17-rc6, needed for msm, also requested by misc. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-09-15wifi: mt76: mt7921u: Add VID/PID for Netgear A7500Nick Morrow
Add VID/PID 0846/9065 for Netgear A7500. Reported-by: Autumn Dececco <autumndececco@gmail.com> Tested-by: Autumn Dececco <autumndececco@gmail.com> Signed-off-by: Nick Morrow <morrownr@gmail.com> Cc: stable@vger.kernel.org Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/80bacfd6-6073-4ce5-be32-ae9580832337@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt76_eeprom_override to intRosen Penev
mt76_eeprom_override has of_get_mac_address, which can return -EPROBE_DEFER if the nvmem driver gets loaded after mt76 for some reason. Make sure this gets passed to probe so that nvmem mac overrides always work. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20250911221619.16035-1-rosenp@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: support writing MAC TXD for AddBA RequestHoward Hsu
Support writing MAC TXD for the AddBA Req. Without this commit, the start sequence number in AddBA Req will be unexpected value for MT7996 and MT7992. This can result in certain stations (e.g., AX200) dropping packets, leading to ping failures and degraded connectivity. Ensuring the correct MAC TXD and TXP helps maintain reliable packet transmission and prevents interoperability issues with affected stations. Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com> Link: https://patch.msgid.link/20250909-mt7996-addba-txd-fix-v1-1-feec16f0c6f0@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7925: refine the txpower initialization flowMing Yen Hsieh
Refactor the initialization and reset flow for tx power setting to eliminate redundant configurations Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250908071245.1833006-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7915: fix mt7981 pre-calibrationZhi-Jun You
In vendor driver, size of group cal and dpd cal for mt7981 includes 6G although the chip doesn't support it. mt76 doesn't take this into account which results in reading from the incorrect offset. For devices with precal, this would lead to lower bitrate. Fix this by aligning groupcal size with vendor driver and switch to freq_list_v2 in mt7915_dpd_freq_idx in order to get the correct offset. Below are iwinfo of the test device with two clients connected (iPhone 16, Intel AX210). Before : Mode: Master Channel: 36 (5.180 GHz) HT Mode: HE80 Center Channel 1: 42 2: unknown Tx-Power: 23 dBm Link Quality: 43/70 Signal: -67 dBm Noise: -92 dBm Bit Rate: 612.4 MBit/s Encryption: WPA3 SAE (CCMP) Type: nl80211 HW Mode(s): 802.11ac/ax/n Hardware: embedded [MediaTek MT7981] After: Mode: Master Channel: 36 (5.180 GHz) HT Mode: HE80 Center Channel 1: 42 2: unknown Tx-Power: 23 dBm Link Quality: 43/70 Signal: -67 dBm Noise: -92 dBm Bit Rate: 900.6 MBit/s Encryption: WPA3 SAE (CCMP) Type: nl80211 HW Mode(s): 802.11ac/ax/n Hardware: embedded [MediaTek MT7981] Tested-on: mt7981 20240823 Fixes: 19a954edec63 ("wifi: mt76: mt7915: add mt7986, mt7916 and mt7981 pre-calibration") Signed-off-by: Zhi-Jun You <hujy652@gmail.com> Link: https://patch.msgid.link/20250909064824.16847-1-hujy652@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: Convert mt76_wed_rro_ind to LELorenzo Bianconi
Do not use bitmask in mt76_wed_rro_ind DMA descriptor in order to not break endianness. This patch is based on the following series: https://lore.kernel.org/linux-wireless/20250909-mt7996-rro-rework-v5-0-7d66f6eb7795@kernel.org/T/#m8b488004d69036cd3672b9eeca8005a937ec0313 Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/301d5f2982ddb729c876fb65f9ac2443ce3f5ff1.1757414621.git.lorenzo@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Add SW path for HW-RRO v3.1Rex Lu
Introduce HW-RRO v3.1 support to be reused when Wireless Ethernet Dispatcher (WED) is not available. HW-RRO v3.1 is supported by MT7992 chipset. Signed-off-by: Rex Lu <rex.lu@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-16-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: Add mt76_dma_get_rxdmad_c_buf utility routioneLorenzo Bianconi
Introduce mt76_dma_get_rxdmad_c_buf routine to process packets received by HW-RRO v3.1 module. This is a preliminary patch to introduce SW path for HW-RRO v3.1 module available on MT7992 chipset. Co-developed-by: Rex Lu <rex.lu@mediatek.com> Signed-off-by: Rex Lu <rex.lu@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-15-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Decouple RRO logic from WED supportRex Lu
Decouple RRO logic from WED support in MT7996 driver in order to reuse it when WED module is not available. Signed-off-by: Rex Lu <rex.lu@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-14-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: Add rx_queue_init callbackLorenzo Bianconi
Introduce rx_queue_init DMA callback. This is a preliminary patch to configure RRO RX queues and decouple RRO logic from WED support. Co-developed-by: Rex Lu <rex.lu@mediatek.com> Signed-off-by: Rex Lu <rex.lu@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-13-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Introduce RRO MSDU callbacksRex Lu
Introduce rx_rro_ind_process and rx_rro_add_msdu_page callbacks and the related logic in the MT7996 driver. This is a preliminary patch to decouple RRO logic from WED support and reuse RRO when WED module is not available. Signed-off-by: Rex Lu <rex.lu@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-12-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LELorenzo Bianconi
Do not use bitmask in mt7996_wed_rro_addr DMA descriptor in order to not break endianness Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-11-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Enable WED for MT7992 chipsetRex Lu
Introduce WED offload support for MT7992 chipset in MT7996 driver. Co-developed-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Co-developed-by: Benjamin Lin <benjamin-jw.lin@mediatek.com> Signed-off-by: Benjamin Lin <benjamin-jw.lin@mediatek.com> Signed-off-by: Rex Lu <rex.lu@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-10-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-09-15wifi: mt76: mt7996: Fix RX packets configuration for primary WED deviceLorenzo Bianconi
In order to properly set the number of rx packets for primary WED device if hif device is available, move hif pointer initialization before running mt7996_mmio_wed_init routine. Fixes: 83eafc9251d6d ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250909-mt7996-rro-rework-v5-9-7d66f6eb7795@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
generated by cgit v1.3 (git 2.53.0) at 2026-11-14 11:10:03 +0000