summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-07-05ARM: dts: stm32: omit unused pinctrl groups from stm32mp13 dtb filesAlexandre Torgue
stm32mp13-pinctrl.dtsi contains nearly all pinctrl groups collected from all boards. Most of them end up unused by a board and only waste binary space. Add /omit-if-no-ref/ to the groups to scrub the unused groups from the dtbs. Use the following regex to update the file and drop two useless newlines too: s@^\t[^:]\+: [^ ]\+ {$@\t/omit-if-no-ref/\r&@ Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05arm64: dts: st: enable Ethernet2 on stm32mp257f-ev1 boardChristophe Roullier
ETHERNET2 instance is connected to Realtek PHY in RGMII mode Ethernet is SNSP IP with GMAC5 version. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05arm64: dts: st: add eth2 pinctrl entries in stm32mp25-pinctrl.dtsiChristophe Roullier
Add pinctrl entry related to ETH2 in stm32mp25-pinctrl.dtsi ethernet2: RGMII with crystal. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05arm64: dts: st: add ethernet1 and ethernet2 support on stm32mp25Christophe Roullier
Both instances ethernet based on GMAC SNPS IP on stm32mp25. GMAC IP version is SNPS 5.3 Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05arm64: dts: st: add HPDMA nodes on stm32mp251Amelie Delaunay
The High Performance Direct Memory Access (HPDMA) controller is used to perform programmable data transfers between memory-mapped peripherals and memories (or between memories) via linked-lists. There are 3 instances of HPDMA on stm32mp251, using stm32-dma3 driver, with 16 channels per instance and with one interrupt per channel. Channels 0 to 7 are implemented with a FIFO of 8 bytes. Channels 8 to 11 are implemented with a FIFO of 32 bytes. Channels 12 to 15 are implemented with a FIFO of 128 bytes. Thanks to stm32-dma3 bindings, the user can ask for a channel with specific FIFO size. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: Add ethernet support for DH STM32MP13xx DHCOR DHSBC boardMarek Vasut
Add ethernet support for the DH STM32MP13xx DHCOR DHSBC carrier board. This carrier board is populated with two gigabit ethernet ports and two Realtek RTL8211F PHYs, both are described in this DT patch. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: order stm32mp13-pinctrl nodesAlexandre Torgue
Keep alphabetic order for pins definition nodes for a better read. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: add ethernet1 for STM32MP135F-DK boardChristophe Roullier
Ethernet1: RMII with crystal Ethernet2: RMII with no cristal, need "phy-supply" property to work, today this property was managed by Ethernet glue, but should be present and managed in PHY node. So I will push second Ethernet in next step. PHYs used are SMSC (LAN8742A) Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: add ethernet1/2 RMII pins for STM32MP13F-DK boardChristophe Roullier
Those pins are used for Ethernet 1 and 2 on STM32MP13F-DK board. ethernet1: RMII with crystal. ethernet2: RMII without crystal. Add analog gpio pin configuration ("sleep") to manage power mode on stm32mp13. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: add ethernet1 and ethernet2 support on stm32mp13Christophe Roullier
Both instances ethernet based on GMAC SNPS IP on stm32mp13. GMAC IP version is SNPS 4.20. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: Document output pins for PWMs on stm32mp135f-dkUwe Kleine-König
To simplify identifying the pins where the PWM output is routed to, add a comment to each PWM device about the respective pin on the expansion connector. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: OP-TEE async notif interrupt for ST STM32MP15x boardsEtienne Carriere
Define the GIC interrupt (PPI 15) to be used on ST STM32MP15x boards for OP-TEE async notif. Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: marvell: orion: align LED node name with bindingsKrzysztof Kozlowski
Bindings expect the LED node names to follow certain pattern, see dtbs_check warnings: orion5x-lswsgl.dtb: gpio-leds: led-alarm: Unevaluated properties are not allowed ('gpio' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: orion5x-lswsgl: use 'gpios' property for LEDsKrzysztof Kozlowski
The 'gpio' property in GPIO LEDs is deprecated, as reported by dtbs_check: orion5x-lswsgl.dtb: gpio-leds: led-alarm: Unevaluated properties are not allowed ('gpio' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: orion: drop incorrect address/size-cells in GPIO keysKrzysztof Kozlowski
Bindings do not allow address/size-cells in GPIO keys and the GPIO keys is not a bus, see dtbs_check warnings: orion5x-lacie-ethernet-disk-mini-v2.dtb: gpio-keys: '#address-cells', '#size-cells' do not match any of the regexes: '^(button|event|key|switch|... Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: orion: align GPIO keys node name with bindingsKrzysztof Kozlowski
Bindings expect the GPIO key node names to follow certain pattern, see dtbs_check warnings: orion5x-lacie-d2-network.dtb: gpio-keys: 'front_button', 'power_rocker_sw_off', 'power_rocker_sw_on' do not match any of the regexes: '^(button|event|key|switch| ... Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: kirkwood: align LED node name with bindingsKrzysztof Kozlowski
Bindings expect the LED node names to follow certain pattern, see dtbs_check warnings: kirkwood-ds409slim.dtb: gpio-leds-alarm-12: 'hdd1-green' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: kirkwood: drop incorrect address/size-cells in GPIO keysKrzysztof Kozlowski
Bindings do not allow address/size-cells in GPIO keys and the GPIO keys is not a bus, see dtbs_check warnings: kirkwood-openblocks_a7.dtb: gpio_keys: '#address-cells', '#size-cells' do not match any of the regexes: '^(button|event|key|switch|(button|event|key|switch)... Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: kirkwood: align GPIO keys node name with bindingsKrzysztof Kozlowski
Bindings expect the GPIO key node names to follow certain pattern, see dtbs_check warnings: kirkwood-laplug.dtb: gpio_keys: 'power' does not match any of the regexes: '^(button|event|key|switch|(button|event|key|switch)... Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: armada-{370-xp,375,38x,39x}: Drop #size-cells from mpic nodeMarek Behún
The marvell,mpic interrupt controller has no children nodes. Drop the Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: marvell: Add 7-segment LED display on x530Chris Packham
The Allied Telesis x530 products have a 7-segment LED display which is used for node identification when the devices are stacked. Represent this as a gpio-7-segment device. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2024-07-05ARM: dts: stm32: Missing clocks for stm32f429's syscfg.Yanjun Yang
Without clock definition, SYSCFG will not work, EXTI interrupt for port other than GPIOA will fail to operate. Signed-off-by: Yanjun Yang <yangyj.ee@gmail.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC boardMarek Vasut
This stm32mp135f-dhcor-dhsbc board is a stack of DHCOR SoM based on STM32MP135F SoC (900MHz / crypto capabilities) populated on DHSBC carrier board. The SoM contains the following peripherals: - STPMIC (power delivery) - 512MB DDR3L memory - eMMC and SDIO WiFi module The DHSBC carrier board contains the following peripherals: - Two RGMII Ethernet ports - USB-A Host port, USB-C peripheral port, USB-C power supply plug - Expansion connector Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05ARM: dts: stm32: Add pinmux nodes for DH electronics STM32MP13xx DHCOR SoM ↵Marek Vasut
and DHSBC board Add new pinmux nodes for DH electronics STM32MP13xx DHCOR SoM and DHSBC board. The following pinmux nodes are added: - ADC pins - ADC CC pins - ETH1 pins - ETH2 pins - I2C5 pins - MCAN1 pins - MCAN2 pins - PWM13 pins - PWM5 pins - QSPI pins - SAI1 pins - SDMMC2 D4..D7 pins - SPI2 pins - SPI3 pins - UART4 pins - UART7 pins - USART1 pins - USART2 pins Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-07-05Merge v6.10-rc6 into drm-nextDaniel Vetter
The exynos-next pull is based on a newer -rc than drm-next. hence backmerge first to make sure the unrelated conflicts we accumulated don't end up randomly in the exynos merge pull, but are separated out. Conflicts are all benign: Adjacent changes in amdgpu and fbdev-dma code, and cherry-pick conflict in xe. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2024-07-05Merge tag 'kvm-s390-master-6.10-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: Fix z16 support The z16 support might fail with the lpswey instruction. Provide a handler.
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-04parisc: Use max() to calculate parisc_tlb_flush_thresholdThorsten Blum
Use max() to reduce 4 lines of code to a single line and improve its readability. Fixes the following Coccinelle/coccicheck warning reported by minmax.cocci: WARNING opportunity for max() Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Signed-off-by: Helge Deller <deller@gmx.de>
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-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 '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-04ACPI: Add acpi=nospcr to disable ACPI SPCR as default console on ARM64Liu Wei
For varying privacy and security reasons, sometimes we would like to completely silence the _serial_ console, and only enable it when needed. But there are many existing systems that depend on this _serial_ console, so add acpi=nospcr to disable console in ACPI SPCR table as default _serial_ console. Signed-off-by: Liu Wei <liuwei09@cestc.cn> Suggested-by: Prarit Bhargava <prarit@redhat.com> Suggested-by: Will Deacon <will@kernel.org> Suggested-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Prarit Bhargava <prarit@redhat.com> Link: https://lore.kernel.org/r/20240625030504.58025-1-liuwei09@cestc.cn Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-07-04perf/x86/amd/uncore: Fix DF and UMC domain identificationSandipan Das
For uncore PMUs, a single context is shared across all CPUs in a domain. The domain can be a CCX, like in the case of the L3 PMU, or a socket, like in the case of DF and UMC PMUs. This information is available via the PMU's cpumask. For contexts shared across a socket, the domain is currently determined from topology_die_id() which is incorrect after the introduction of commit 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf") as it now returns a CCX identifier on Zen 4 and later systems which support CPUID leaf 0x80000026. Use topology_logical_package_id() instead as it always returns a socket identifier irrespective of the availability of CPUID leaf 0x80000026. Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf") Signed-off-by: Sandipan Das <sandipan.das@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20240626074942.1044818-1-sandipan.das@amd.com
2024-07-04perf/x86/amd/uncore: Avoid PMU registration if counters are unavailableSandipan Das
X86_FEATURE_PERFCTR_NB and X86_FEATURE_PERFCTR_LLC are derived from CPUID leaf 0x80000001 ECX bits 24 and 28 respectively and denote the availability of DF and L3 counters. When these bits are not set, the corresponding PMUs have no counters and hence, should not be registered. Fixes: 07888daa056e ("perf/x86/amd/uncore: Move discovery and registration") Signed-off-by: Sandipan Das <sandipan.das@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20240626074404.1044230-1-sandipan.das@amd.com
2024-07-04perf/x86/intel: Support Perfmon MSRs aliasingKan Liang
The architectural performance monitoring V6 supports a new range of counters' MSRs in the 19xxH address range. They include all the GP counter MSRs, the GP control MSRs, and the fixed counter MSRs. The step between each sibling counter is 4. Add intel_pmu_addr_offset() to calculate the correct offset. Add fixedctr in struct x86_pmu to store the address of the fixed counter 0. It can be used to calculate the rest of the fixed counters. The MSR address of the fixed counter control is not changed. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lkml.kernel.org/r/20240626143545.480761-9-kan.liang@linux.intel.com
2024-07-04perf/x86/intel: Support PERFEVTSEL extensionKan Liang
Two new fields (the unit mask2, and the equal flag) are added in the IA32_PERFEVTSELx MSRs. They can be enumerated by the CPUID.23H.0.EBX. Update the config_mask in x86_pmu and x86_hybrid_pmu for the true layout of the PERFEVTSEL. Expose the new formats into sysfs if they are available. The umask extension reuses the same format attr name "umask" as the previous umask. Add umask2_show to determine/display the correct format for the current machine. Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lkml.kernel.org/r/20240626143545.480761-8-kan.liang@linux.intel.com
2024-07-04perf/x86: Add config_mask to represent EVENTSEL bitmaskKan Liang
Different vendors may support different fields in EVENTSEL MSR, such as Intel would introduce new fields umask2 and eq bits in EVENTSEL MSR since Perfmon version 6. However, a fixed mask X86_RAW_EVENT_MASK is used to filter the attr.config. Introduce a new config_mask to record the real supported EVENTSEL bitmask. Only apply it to the existing code now. No functional change. Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lkml.kernel.org/r/20240626143545.480761-7-kan.liang@linux.intel.com
2024-07-04perf/x86/intel: Support new data source for Lunar LakeKan Liang
A new PEBS data source format is introduced for the p-core of Lunar Lake. The data source field is extended to 8 bits with new encodings. A new layout is introduced into the union intel_x86_pebs_dse. Introduce the lnl_latency_data() to parse the new format. Enlarge the pebs_data_source[] accordingly to include new encodings. Only the mem load and the mem store events can generate the data source. Introduce INTEL_HYBRID_LDLAT_CONSTRAINT and INTEL_HYBRID_STLAT_CONSTRAINT to mark them. Add two new bits for the new cache-related data src, L2_MHB and MSC. The L2_MHB is short for L2 Miss Handling Buffer, which is similar to LFB (Line Fill Buffer), but to track the L2 Cache misses. The MSC stands for the memory-side cache. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lkml.kernel.org/r/20240626143545.480761-6-kan.liang@linux.intel.com
2024-07-04perf/x86/intel: Rename model-specific pebs_latency_data functionsKan Liang
The model-specific pebs_latency_data functions of ADL and MTL use the "small" as a postfix to indicate the e-core. The postfix is too generic for a model-specific function. It cannot provide useful information that can directly map it to a specific uarch, which can facilitate the development and maintenance. Use the abbr of the uarch to rename the model-specific functions. Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lkml.kernel.org/r/20240626143545.480761-5-kan.liang@linux.intel.com
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-10 20:44:52 +0000