summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-05wifi: rtw89: 8852bx: move BTC common code from 8852b to 8852b_commonPing-Ke Shih
The BT coexistence part of 8852B and 8852BT are similar, so move shared code into common module. Don't change logic for existing RTL8852BE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-1-pkshih@realtek.com
2024-07-05wifi: rtw88: usb: schedule rx work after everything is set upMarcin Ślusarz
Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. Link: https://lore.kernel.org/linux-wireless/CA+shoWQ7P49jhQasofDcTdQhiuarPTjYEDa--NiVVx494WcuQw@mail.gmail.com/ Signed-off-by: Marcin Ślusarz <mslusarz@renau.com> Cc: Tim K <tpkuester@gmail.com> Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Kalle Valo <kvalo@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240528110246.477321-1-marcin.slusarz@gmail.com
2024-07-04hwmon: (ltc2991) re-order conditions to fix off by one bugDan Carpenter
LTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL (4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we have read one element beyond the end of the array. Flip the conditions around so that we check if "channel" is valid before using it as an array index. Fixes: 2b9ea4262ae9 ("hwmon: Add driver for ltc2991") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/Zoa9Y_UMY4_ROfhF@stanley.mountain Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-07-05tpm: Address !chip->auth in tpm_buf_append_hmac_session*()Jarkko Sakkinen
Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can cause a null derefence in tpm_buf_hmac_session*(). Thus, address !chip->auth in tpm_buf_hmac_session*() and remove the fallback implementation for !TCG_TPM2_HMAC. Cc: stable@vger.kernel.org # v6.9+ Reported-by: Stefan Berger <stefanb@linux.ibm.com> Closes: https://lore.kernel.org/linux-integrity/20240617193408.1234365-1-stefanb@linux.ibm.com/ Fixes: 1085b8276bb4 ("tpm: Add the rest of the session HMAC API") Tested-by: Michael Ellerman <mpe@ellerman.id.au> # ppc Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-07-05tpm: Address !chip->auth in tpm_buf_append_name()Jarkko Sakkinen
Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can cause a null derefence in tpm_buf_append_name(). Thus, address !chip->auth in tpm_buf_append_name() and remove the fallback implementation for !TCG_TPM2_HMAC. Cc: stable@vger.kernel.org # v6.10+ Reported-by: Stefan Berger <stefanb@linux.ibm.com> Closes: https://lore.kernel.org/linux-integrity/20240617193408.1234365-1-stefanb@linux.ibm.com/ Fixes: d0a25bb961e6 ("tpm: Add HMAC session name/handle append") Tested-by: Michael Ellerman <mpe@ellerman.id.au> # ppc Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-07-05tpm: Address !chip->auth in tpm2_*_auth_session()Jarkko Sakkinen
Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can cause a null derefence in tpm2_*_auth_session(). Thus, address !chip->auth in tpm2_*_auth_session(). Cc: stable@vger.kernel.org # v6.9+ Reported-by: Stefan Berger <stefanb@linux.ibm.com> Closes: https://lore.kernel.org/linux-integrity/20240617193408.1234365-1-stefanb@linux.ibm.com/ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Tested-by: Michael Ellerman <mpe@ellerman.id.au> # ppc Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-07-04ethtool: move firmware flashing flag to struct ethtool_netdev_stateEdward Cree
Commit 31e0aa99dc02 ("ethtool: Veto some operations during firmware flashing process") added a flag module_fw_flash_in_progress to struct net_device. As this is ethtool related state, move it to the recently created struct ethtool_netdev_state, accessed via the 'ethtool' member of struct net_device. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20240703121849.652893-1-edward.cree@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/phy/aquantia/aquantia.h 219343755eae ("net: phy: aquantia: add missing include guards") 61578f679378 ("net: phy: aquantia: add support for PHY LEDs") drivers/net/ethernet/wangxun/libwx/wx_hw.c bd07a9817846 ("net: txgbe: remove separate irq request for MSI and INTx") b501d261a5b3 ("net: txgbe: add FDIR ATR support") https://lore.kernel.org/all/20240703112936.483c1975@canb.auug.org.au/ include/linux/mlx5/mlx5_ifc.h 048a403648fc ("net/mlx5: IFC updates for changing max EQs") 99be56171fa9 ("net/mlx5e: SHAMPO, Re-enable HW-GRO") https://lore.kernel.org/all/20240701133951.6926b2e3@canb.auug.org.au/ Adjacent changes: drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 4130c67cd123 ("wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereference") 3f3126515fbe ("wifi: iwlwifi: mvm: add mvm-specific guard") include/net/mac80211.h 816c6bec09ed ("wifi: mac80211: fix BSS_CHANGED_UNSOL_BCAST_PROBE_RESP") 5a009b42e041 ("wifi: mac80211: track changes in AP's TPE") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04Merge branches 'doc.2024.06.06a', 'fixes.2024.07.04a', 'mb.2024.06.28a', ↵Paul E. McKenney
'nocb.2024.06.03a', 'rcu-tasks.2024.06.06a', 'rcutorture.2024.06.06a' and 'srcu.2024.06.18a' into HEAD doc.2024.06.06a: Documentation updates. fixes.2024.07.04a: Miscellaneous fixes. mb.2024.06.28a: Grace-period memory-barrier redundancy removal. nocb.2024.06.03a: No-CB CPU updates. rcu-tasks.2024.06.06a: RCU-Tasks updates. rcutorture.2024.06.06a: Torture-test updates. srcu.2024.06.18a: SRCU polled-grace-period updates.
2024-07-04rcu: Fix rcu_barrier() VS post CPUHP_TEARDOWN_CPU invocationFrederic Weisbecker
When rcu_barrier() calls rcu_rdp_cpu_online() and observes a CPU off rnp->qsmaskinitnext, it means that all accesses from the offline CPU preceding the CPUHP_TEARDOWN_CPU are visible to RCU barrier, including callbacks expiration and counter updates. However interrupts can still fire after stop_machine() re-enables interrupts and before rcutree_report_cpu_dead(). The related accesses happening between CPUHP_TEARDOWN_CPU and rnp->qsmaskinitnext clearing are _NOT_ guaranteed to be seen by rcu_barrier() without proper ordering, especially when callbacks are invoked there to the end, making rcutree_migrate_callback() bypass barrier_lock. The following theoretical race example can make rcu_barrier() hang: CPU 0 CPU 1 ----- ----- //cpu_down() smpboot_park_threads() //ksoftirqd is parked now <IRQ> rcu_sched_clock_irq() invoke_rcu_core() do_softirq() rcu_core() rcu_do_batch() // callback storm // rcu_do_batch() returns // before completing all // of them // do_softirq also returns early because of // timeout. It defers to ksoftirqd but // it's parked </IRQ> stop_machine() take_cpu_down() rcu_barrier() spin_lock(barrier_lock) // observes rcu_segcblist_n_cbs(&rdp->cblist) != 0 <IRQ> do_softirq() rcu_core() rcu_do_batch() //completes all pending callbacks //smp_mb() implied _after_ callback number dec </IRQ> rcutree_report_cpu_dead() rnp->qsmaskinitnext &= ~rdp->grpmask; rcutree_migrate_callback() // no callback, early return without locking // barrier_lock //observes !rcu_rdp_cpu_online(rdp) rcu_barrier_entrain() rcu_segcblist_entrain() // Observe rcu_segcblist_n_cbs(rsclp) == 0 // because no barrier between reading // rnp->qsmaskinitnext and rsclp->len rcu_segcblist_add_len() smp_mb__before_atomic() // will now observe the 0 count and empty // list, but too late, we enqueue regardless WRITE_ONCE(rsclp->len, rsclp->len + v); // ignored barrier callback // rcu barrier stall... This could be solved with a read memory barrier, enforcing the message passing between rnp->qsmaskinitnext and rsclp->len, matching the full memory barrier after rsclp->len addition in rcu_segcblist_add_len() performed at the end of rcu_do_batch(). However the rcu_barrier() is complicated enough and probably doesn't need too many more subtleties. CPU down is a slowpath and the barrier_lock seldom contended. Solve the issue with unconditionally locking the barrier_lock on rcutree_migrate_callbacks(). This makes sure that either rcu_barrier() sees the empty queue or its entrained callback will be migrated. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-07-04rcu: Eliminate lockless accesses to rcu_sync->gp_countOleg Nesterov
The rcu_sync structure's ->gp_count field is always accessed under the protection of that same structure's ->rss_lock field, with the exception of a pair of WARN_ON_ONCE() calls just prior to acquiring that lock in functions rcu_sync_exit() and rcu_sync_dtor(). These lockless accesses are unnecessary and impair KCSAN's ability to catch bugs that might be inserted via other lockless accesses. This commit therefore moves those WARN_ON_ONCE() calls under the lock. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-07-04MAINTAINERS: Add Uladzislau Rezki as RCU maintainerPaul E. McKenney
Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Uladzislau Rezki <urezki@gmail.com>
2024-07-04rcu: Add rcutree.nohz_full_patience_delay to reduce nohz_full OS jitterPaul E. McKenney
If a CPU is running either a userspace application or a guest OS in nohz_full mode, it is possible for a system call to occur just as an RCU grace period is starting. If that CPU also has the scheduling-clock tick enabled for any reason (such as a second runnable task), and if the system was booted with rcutree.use_softirq=0, then RCU can add insult to injury by awakening that CPU's rcuc kthread, resulting in yet another task and yet more OS jitter due to switching to that task, running it, and switching back. In addition, in the common case where that system call is not of excessively long duration, awakening the rcuc task is pointless. This pointlessness is due to the fact that the CPU will enter an extended quiescent state upon returning to the userspace application or guest OS. In this case, the rcuc kthread cannot do anything that the main RCU grace-period kthread cannot do on its behalf, at least if it is given a few additional milliseconds (for example, given the time duration specified by rcutree.jiffies_till_first_fqs, give or take scheduling delays). This commit therefore adds a rcutree.nohz_full_patience_delay kernel boot parameter that specifies the grace period age (in milliseconds, rounded to jiffies) before which RCU will refrain from awakening the rcuc kthread. Preliminary experimentation suggests a value of 1000, that is, one second. Increasing rcutree.nohz_full_patience_delay will increase grace-period latency and in turn increase memory footprint, so systems with constrained memory might choose a smaller value. Systems with less-aggressive OS-jitter requirements might choose the default value of zero, which keeps the traditional immediate-wakeup behavior, thus avoiding increases in grace-period latency. [ paulmck: Apply Leonardo Bras feedback. ] Link: https://lore.kernel.org/all/20240328171949.743211-1-leobras@redhat.com/ Reported-by: Leonardo Bras <leobras@redhat.com> Suggested-by: Leonardo Bras <leobras@redhat.com> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Leonardo Bras <leobras@redhat.com>
2024-07-04ARM: Emulate one-byte cmpxchgPaul E. McKenney
Use the new cmpxchg_emu_u8() to emulate one-byte cmpxchg() on ARM systems with ARCH == ARMv6K. [ paulmck: Apply Arnd Bergmann and Nathan Chancellor feedback. ] [ paulmck: Apply Linus Walleij feedback. ] Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/54798f68-48f7-4c65-9cba-47c0bf175143@sirena.org.uk/ Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYuZ+pf6p8AXMZWtdFtX-gbG8HMaBKp=XbxcdzA_QeLkxQ@mail.gmail.com/ Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Andrew Davis <afd@ti.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Eric DeVolder <eric.devolder@oracle.com> Cc: Rob Herring <robh@kernel.org> Cc: <linux-arm-kernel@lists.infradead.org>
2024-07-04arm64: dts: rockchip: fixes PHY reset for Lunzn Fastrhino R68SChukun Pan
Fixed the PHY address and reset GPIOs (does not match the corresponding pinctrl) for gmac0 and gmac1. Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-7-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: disable display subsystem for Lunzn Fastrhino R6xSChukun Pan
The R66S and R68S boards do not have HDMI output, so disable the display subsystem. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240701143028.1203997-3-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: remove unused usb2 nodes for Lunzn Fastrhino R6xSChukun Pan
Fix the following error when booting: [ 15.851853] platform fd800000.usb: deferred probe pending [ 15.852384] platform fd840000.usb: deferred probe pending [ 15.852881] platform fd880000.usb: deferred probe pending This is due to usb2phy1 is not enabled. There is no USB 2.0 port on the board, just remove it. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-5-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix pmu_io supply for Lunzn Fastrhino R6xSChukun Pan
Fixes pmu_io_domains supply according to the schematic. Among them, the vccio3 is responsible for the io voltage of sdcard. There is no sdcard slot on the R68S, and it's connected to vcc_3v3, so describe the supply of vccio3 separately. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-4-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix usb regulator for Lunzn Fastrhino R6xSChukun Pan
Remove the non-existent usb_host regulator and fix the supply according to the schematic. Also remove the unnecessary always-on and boot-on for the usb_otg regulator. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240701143028.1203997-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: fix regulator name for Lunzn Fastrhino R6xSChukun Pan
Make the regulator name the same as those marked by schematics. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20240630150010.55729-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04regulator: max77857: Constify struct regmap_configJavier Carrasco
`max77857_remgap_config` is not modified and can be declared as const to move its data to a read-only section. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20240704-regulator-const-regmap-v1-2-bce0ddef63ea@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-04regulator: da9121: Constify struct regmap_configJavier Carrasco
`da9121_1ch_regmap_config` and `da9121_2ch_regmap_config` are not modified and can be declared as const to move their data to a read-only section. The pointer that references those structs has been converted to const accordingly. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20240704-regulator-const-regmap-v1-1-bce0ddef63ea@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-04arm64: dts: rockchip: Add dma-names to uart1 on quartz64-bDiederik de Haas
There have been several attempts to set the dma-names property on the SoC level (in rk356x.dtsi), but that appears to cause problems when set on channels without flow control. Quoting part of a previous attempt for clarification: > Nah, enabling it for bluetooth is fine because you have flow control. > My issues have been on channels without flow control. Without DMA it > simply drops messages or the channel hangs until you close and reopen > it. With DMA, when an overflow locks up the channel it is usually > unavailable until the board is rebooted. Setting it on the board level for the bluetooth connection was deemed safe, so do so for the Quartz64 Model B. This fixes the following error/warning: of_dma_request_slave_channel: dma-names property of node '/serial@fe650000' missing or empty dw-apb-uart fe650000.serial: failed to request DMA Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://libera.irclog.whitequark.org/armlinux/2024-02-29 Link: https://lore.kernel.org/linux-rockchip/18284546.sWSEgdgrri@diego/ Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240628120130.24076-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsiDragan Simic
Update the values for the exact Rockchip RK356x GPU OPP voltages and the lower limits for the GPU OPP voltage ranges, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source (cf. downstream commit f8b9431ee38e ("arm64: dts: rockchip: rk3568: support adjust opp-table by otp")). [1][2] Using the most conservative per-OPP voltages ensures reliable GPU operation regardless of the actual GPU binning, with the downside of possibly using a bit more power than absolutely needed. [1] https://github.com/rockchip-linux/kernel/commit/f8b9431ee38ed561650be7092ab93f564598daa9 [2] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Suggested-by: Diederik de Haas <didi.debian@cknow.org> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/80301764e8983c8410c806ed2256403823709897.1719763100.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsiDragan Simic
Add support for voltage ranges to the GPU OPPs defined in the SoC dtsi for Rockchip RK356x. This is, for example, useful for RK356x-based boards that are designed to use the same power supply for the GPU and NPU portions of the SoC, which is described further in the following documents: - Rockchip RK3566 Hardware Design Guide, version 1.1.0, page 37 - Rockchip RK3568 Hardware Design Guide, version 1.2, page 78 The values for the exact GPU OPP voltages and the lower limits for the GPU OPP voltage ranges differ from the values found in the vendor kernel source (cf. downstream commit f8b9431ee38e ("arm64: dts: rockchip: rk3568: support adjust opp-table by otp")), [1][2] and present the exact GPU OPP voltage values that have served us well so far. [1] https://github.com/rockchip-linux/kernel/commit/f8b9431ee38ed561650be7092ab93f564598daa9 [2] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Suggested-by: Diederik de Haas <didi.debian@cknow.org> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/7e9ba70fd54a21d6f1f267df11e0acabff8d24e0.1719763100.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Drop ethernet-phy-ieee802.3-c22 from PHY compatible ↵Marek Vasut
string on all RK3588 boards The rtl82xx DT bindings do not require ethernet-phy-ieee802.3-c22 as the fallback compatible string. There are fewer users of the Realtek PHY compatible string with fallback compatible string than there are users without fallback compatible string, so drop the fallback compatible string from the few remaining users: $ git grep -ho ethernet-phy-id001c....... | sort | uniq -c 1 ethernet-phy-id001c.c816", 2 ethernet-phy-id001c.c915", 2 ethernet-phy-id001c.c915"; 5 ethernet-phy-id001c.c916", 13 ethernet-phy-id001c.c916"; Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406290316.YvZdvLxu-lkp@intel.com/ Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240630034910.173552-2-marex@denx.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04arm64: dts: rockchip: Add missing power-domains for rk356x vop_mmuCristian Ciocaltea
The iommu@fe043e00 on RK356x SoC shares the VOP power domain, but the power-domains property was not provided when the node has been added. The consequence is that an attempt to reload the rockchipdrm module will freeze the entire system. That is because on probe time, pm_runtime_get_suppliers() gets called for vop@fe040000, which blocks when pm_runtime_get_sync() is being invoked for iommu@fe043e00. Fix the issue by adding the missing property. Fixes: 9d6c6d978f97 ("arm64: dts: rockchip: rk356x: Add VOP2 nodes") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240702-rk356x-fix-vop-mmu-v1-1-a66d1a0c45ea@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04ARM: dts: rockchip: Drop ethernet-phy-ieee802.3-c22 from PHY compatible ↵Marek Vasut
string on edgeble-neu2 The rtl82xx DT bindings do not require ethernet-phy-ieee802.3-c22 as the fallback compatible string. There are fewer users of the Realtek PHY compatible string with fallback compatible string than there are users without fallback compatible string, so drop the fallback compatible string from the few remaining users: $ git grep -ho ethernet-phy-id001c....... | sort | uniq -c 1 ethernet-phy-id001c.c816", 2 ethernet-phy-id001c.c915", 2 ethernet-phy-id001c.c915"; 5 ethernet-phy-id001c.c916", 13 ethernet-phy-id001c.c916"; Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406290316.YvZdvLxu-lkp@intel.com/ Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240630034910.173552-1-marex@denx.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-07-04Merge tag 'for-6.10-rc6-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - fix folio refcounting when releasing them (encoded write, dummy extent buffer) - fix out of bounds read when checking qgroup inherit data - fix how configurable chunk size is handled in zoned mode - in the ref-verify tool, fix uninitialized return value when checking extent owner ref and simple quota are not enabled * tag 'for-6.10-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix folio refcount in __alloc_dummy_extent_buffer() btrfs: fix folio refcount in btrfs_do_encoded_write() btrfs: fix uninitialized return value in the ref-verify tool btrfs: always do the basic checks for btrfs_qgroup_inherit structure btrfs: zoned: fix calc_available_free_space() for zoned mode
2024-07-04Merge branch 'crypto-caam-unembed-net_dev'Jakub Kicinski
Breno Leitao says: ==================== crypto: caam: Unembed net_dev This will un-embed the net_device struct from inside other struct, so we can add flexible array into net_device. This also enable COMPILE test for FSL_CAAM, as any config option that depends on ARCH_LAYERSCAPE. ==================== Link: https://patch.msgid.link/20240702185557.3699991-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04crypto: caam: Unembed net_dev structure in dpaa2Breno Leitao
Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_devices from struct dpaa2_caam_priv_per_cpu by converting them into pointers, and allocating them dynamically. Use the leverage alloc_netdev_dummy() to allocate the net_device object at dpaa2_dpseci_setup(). The free of the device occurs at dpaa2_dpseci_disable(). Link: https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-5-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04crypto: caam: Unembed net_dev structure from qiBreno Leitao
Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_devices from struct caam_qi_pcpu_priv by converting them into pointers, and allocating them dynamically. Use the leverage alloc_netdev_dummy() to allocate the net_device object at caam_qi_init(). The free of the device occurs at caam_qi_shutdown(). Link: https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-4-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04crypto: caam: Make CRYPTO_DEV_FSL_CAAM dependent of COMPILE_TESTBreno Leitao
As most of the drivers that depend on ARCH_LAYERSCAPE, make CRYPTO_DEV_FSL_CAAM depend on COMPILE_TEST for compilation and testing. # grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l 29 Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-3-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04crypto: caam: Avoid unused imx8m_machine_match variableBreno Leitao
If caam module is built without OF support, the compiler returns the following warning: drivers/crypto/caam/ctrl.c:83:34: warning: 'imx8m_machine_match' defined but not used [-Wunused-const-variable=] imx8m_machine_match is only referenced by of_match_node(), which is set to NULL if CONFIG_OF is not set, as of commit 5762c20593b6b ("dt: Add empty of_match_node() macro"): #define of_match_node(_matches, _node) NULL Do not create imx8m_machine_match if CONFIG_OF is not set. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407011309.cpTuOGdg-lkp@intel.com/ Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-04Merge tag 'net-6.10-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from bluetooth, wireless and netfilter. There's one fix for power management with Intel's e1000e here, Thorsten tells us there's another problem that started in v6.9. We're trying to wrap that up but I don't think it's blocking. Current release - new code bugs: - wifi: mac80211: disable softirqs for queued frame handling - af_unix: fix uninit-value in __unix_walk_scc(), with the new garbage collection algo Previous releases - regressions: - Bluetooth: - qca: fix BT enable failure for QCA6390 after warm reboot - add quirk to ignore reserved PHY bits in LE Extended Adv Report, abused by some Broadcom controllers found on Apple machines - wifi: wilc1000: fix ies_len type in connect path Previous releases - always broken: - tcp: fix DSACK undo in fast recovery to call tcp_try_to_open(), avoid premature timeouts - net: make sure skb_datagram_iter maps fragments page by page, in case we somehow get compound highmem mixed in - eth: bnx2x: fix multiple UBSAN array-index-out-of-bounds when more queues are used Misc: - MAINTAINERS: Remembering Larry Finger" * tag 'net-6.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (62 commits) bnxt_en: Fix the resource check condition for RSS contexts mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file inet_diag: Initialize pad field in struct inet_diag_req_v2 tcp: Don't flag tcp_sk(sk)->rx_opt.saw_unknown for TCP AO. selftests: make order checking verbose in msg_zerocopy selftest selftests: fix OOM in msg_zerocopy selftest ice: use proper macro for testing bit ice: Reject pin requests with unsupported flags ice: Don't process extts if PTP is disabled ice: Fix improper extts handling selftest: af_unix: Add test case for backtrack after finalising SCC. af_unix: Fix uninit-value in __unix_walk_scc() bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() net: rswitch: Avoid use-after-free in rswitch_poll() netfilter: nf_tables: unconditionally flush pending work before notifier wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereference wifi: iwlwifi: mvm: avoid link lookup in statistics wifi: iwlwifi: mvm: don't wake up rx_sync_waitq upon RFKILL wifi: iwlwifi: properly set WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK wifi: wilc1000: fix ies_len type in connect path ...
2024-07-04thermal: core: Call monitor_thermal_zone() if zone temperature is invalidRafael J. Wysocki
Commit 202aa0d4bb53 ("thermal: core: Do not call handle_thermal_trip() if zone temperature is invalid") caused __thermal_zone_device_update() to return early if the current thermal zone temperature was invalid. This was done to avoid running handle_thermal_trip() and governor callbacks in that case which led to confusion. However, it went too far because monitor_thermal_zone() still needs to be called even when the zone temperature is invalid to ensure that it will be updated eventually in case thermal polling is enabled and the driver has no other means to notify the core of zone temperature changes (for example, it does not register an interrupt handler or ACPI notifier). Also if the .set_trips() zone callback is expected to set up monitoring interrupts for a thermal zone, it has to be provided with valid boundaries and that can only happen if the zone temperature is known. Accordingly, to ensure that __thermal_zone_device_update() will run again after a failing zone temperature check, make it call monitor_thermal_zone() regardless of whether or not the zone temperature is valid and make the latter schedule a thermal zone temperature update if the zone temperature is invalid even if polling is not enabled for the thermal zone. Fixes: 202aa0d4bb53 ("thermal: core: Do not call handle_thermal_trip() if zone temperature is invalid") Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2764814.mvXUDI8C0e@rjwysocki.net [ rjw: Changed THERMAL_RECHECK_DELAY_MS to 250 ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-07-04Merge tag 's390-6.10-8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Fix and add physical to virtual address translations in dasd and virtio_ccw drivers. For virtio_ccw this is just a minimal fix. More code cleanup will follow. - Small defconfig updates * tag 's390-6.10-8' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/dasd: Fix invalid dereferencing of indirect CCW data pointer s390/vfio_ccw: Fix target addresses of TIC CCWs s390: Update defconfigs
2024-07-04dt-bindings: mfd: syscon: Add APM poweroff mailboxKrzysztof Kozlowski
Add compatible for an already used syscon poweroff/mailbox block in APM. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240627-dt-bindings-mfd-syscon-split-v4-7-dc6699a9f3e4@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: syscon: Split and enforce documenting MFD childrenKrzysztof Kozlowski
Simple syscon nodes can be documented in common syscon.yaml, however devices with simple-mfd compatible, thus with some children, should have their own schema listing these children. Such listing makes the binding specific, allows better validation (so the incorrect child would not appear in the simple-mfd node) and actually enforces repeated rule for simple-mfd devices: "simple-mfd" is only for simple devices, where the children do not depend on the parent. Currently the syscon+simple-mfd binding is quite broad and allows any child or property, thus above rule cannot be enforced. Split the syscon.yaml binding into: 1. Common syscon properties, used potentially by many bindings. 2. Simple syscon devices (NO simple-mfd!). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240627-dt-bindings-mfd-syscon-split-v4-6-dc6699a9f3e4@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: rk817: Merge support for RK809Cristian Ciocaltea
The Rockchip RK809 PMIC is compatible with RK817 and provides the same capabilities, except for the battery charger manager. There are also minor regulator related differences: BOOST and OTG_SWITCH are specific to RK817, while DCDC_REG5, SWITCH_REG1 and SWITCH_REG2 are provided RK809. The current binding for RK809 doesn't document the audio codec properties, although it has been already in use by several boards: rk3566-quartz64-b, k3566-roc-pc, rk3568-evb1-v10, rk3568-lubancat-2, rk3568-odroid-m1, rk3568-rock-3a. Therefore dtbs_check fails for all of them: DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb rk3568-rock-3a.dtb: pmic@20: '#sound-dai-cells', 'assigned-clock-parents', 'assigned-clocks', 'clock-names', 'clocks', 'codec' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# Additionally, the example in rockchip,rk809 binding is not able to actually test the schema since it uses a wrong compatible 'rockchip,rk808' instead of the expected 'rockchip,rk809'. Instead of duplicating even more content, merge the RK809 support into the more inclusive RK817 schema and drop the now obsolete rockchip,rk809 related file. Fixes: 6c38ca03406e ("dt-bindings: mfd: rk808: Convert bindings to yaml") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-2-c0db420d3639@collabora.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: rk817: Fixup clocks and reference dai-commonCristian Ciocaltea
Ensure 'clocks' property does not allow more than one item and add the missing reference to dai-common schema. While at it, move 'clocks*' and '#sound-dai-cells' properties to keep the list ordered alphabetically. Additionally, drop all useless/redundant descriptions. Fixes: 6c38ca03406e ("dt-bindings: mfd: rk808: Convert bindings to yaml") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-1-c0db420d3639@collabora.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: syscon: Add TI's opp table compatibleBryan Brattlof
The JTAG_USER_ID_USERCODE efuse address, which is located inside the WKUP_CTRL_MMR0 range holds information to identify the speed grades of various components on TI's K3 SoCs. Add a compatible to allow the cpufreq driver to obtain the data to limit the maximum frequency for the CPUs under Linux control. Signed-off-by: Bryan Brattlof <bb@ti.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240621-ti-opp-updates-v3-3-d857be6dac8b@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: omap-usb-tll: Use struct_size to allocate tllJavier Carrasco
Commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") changed the memory allocation of 'tll' to consolidate it into a single allocation, introducing an incorrect size calculation. In particular, the allocation for the array of pointers was converted into a single-pointer allocation. The memory allocation used to occur in two steps: tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL); tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk *) * tll->nch, GFP_KERNEL); And it turned that into the following allocation: tll = devm_kzalloc(dev, sizeof(*tll) + sizeof(tll->ch_clk[nch]), GFP_KERNEL); sizeof(tll->ch_clk[nch]) returns the size of a single pointer instead of the expected nch pointers. This bug went unnoticed because the allocation size was small enough to fit within the minimum size of a memory allocation for this particular case [1]. The complete allocation can still be done at once with the struct_size macro, which comes in handy for structures with a trailing flexible array. Fix the memory allocation to obtain the original size again. Link: https://lore.kernel.org/all/202406261121.2FFD65647@keescook/ [1] Fixes: 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Fixes: commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Link: https://lore.kernel.org/r/20240626-omap-usb-tll-counted_by-v2-1-4bedf20d1b51@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: Explain lack of child dependency in simple-mfdKrzysztof Kozlowski
Common mistake of usage of 'simple-mfd' compatible is a dependency of children on resources acquired and managed by the parent, e.g. clocks. Extend the simple-mfd documentation to cover this case. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240623134600.115098-1-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04dt-bindings: mfd: Dual licensing for st,stpmic1 bindingsEtienne Carriere
Change include/dt-bindings/mfd/st,stpmic1.h license model from GPLv2.0 only to dual GPLv2.0 or BSD-2-Clause. I have every legitimacy to request this change on behalf of STMicroelectronics. This change clarifies that this DT binding header file can be shared with software components as bootloaders and OSes that are not published under GPLv2 terms. In CC are all the contributors to this header file. Cc: Pascal Paillet <p.paillet@st.com> Cc: Lee Jones <lee@kernel.org> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240617092016.2958046-1-etienne.carriere@foss.st.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: omap-usb-tll: Annotate struct usbtll_omap with __counted_byJavier Carrasco
Use the __counted_by compiler attribute for the "struct clk *ch_clk[]" flexible array member to improve the results of array bound sanitizers. The comments for the variables are no longer needed as it is now clear what is what. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240620-omap-usb-tll-counted_by-v1-1-77797834bb9a@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: tps6594-core: Remove unneeded semicolon in tps6594_check_crc_mode()Yang Li
Abaci Robot reports: drivers/mfd/tps6594-core.c:516:2-3: Unneeded semicolon Let's remove it. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9346 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20240618011854.109426-1-yang.lee@linux.alibaba.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: lm3533: Move to new GPIO descriptor-based APIsAndy Shevchenko
Legacy GPIO APIs are subject to remove. Convert the driver to new APIs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240605191458.2536819-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: tps65912: Use devm helper functions to simplify probeAndrew Davis
This simplifies probe and also allows us to remove the remove callbacks from the core and interface drivers. Do that here. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240613175430.57698-1-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04mfd: madera: Simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240606142457.130553-2-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-23 23:24:14 +0000