summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-02-14Revert "powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add"Michael Ellerman
This reverts commit ed8b94f6e0acd652ce69bd69d678a0c769172df8. Gaurav reported that there are still problems with the patch and it should be reverted pending a fuller fix. Link: https://lore.kernel.org/all/4f6fc1ac-7a76-4447-9d0e-f55c0be373f8@linux.ibm.com/ Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2024-02-13x86/insn-eval: Fix function param name in get_eff_addr_sib()Randy Dunlap
Change "regoff" to "base_offset" in 2 places in the kernel-doc comments to prevent warnings: insn-eval.c:1152: warning: Function parameter or member 'base_offset' not described in 'get_eff_addr_sib' insn-eval.c:1152: warning: Excess function parameter 'regoff' description in 'get_eff_addr_sib' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240211062452.16411-1-rdunlap@infradead.org
2024-02-13arm64: dts: rockchip: Correct Indiedroid Nova GPIO NamesChris Morgan
Correct the names given to a few of the GPIO pins. The original names were unknowingly based on the header from a pre-production board. The production board has a slightly different pin assignment for the 40-pin GPIO header. Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20240125201943.90476-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: Add USB3.0 to Indiedroid NovaChris Morgan
Add the proper nodes to activate the USB 3.0 ports on the Indiedroid Nova. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20240125201943.90476-3-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: adjust phy-handle name on rock-pi-eTrevor Woerner
The rock-pi-e currently comes in 4 board spins, the latest one (v1.21) swaps out the Realtek 8211e PHY for an 8211f PHY. Therefore modify the phy-handle name to be more generic. Signed-off-by: Trevor Woerner <twoerner@gmail.com> Link: https://lore.kernel.org/r/20240116204103.29318-1-twoerner@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: fix rk3399 hdmi ports nodeJohan Jonker
Fix rk3399 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/a6ab6f75-3b80-40b1-bd30-3113e14becdd@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: fix rk3328 hdmi ports nodeJohan Jonker
Fix rk3328 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/e5dea3b7-bf84-4474-9530-cc2da3c41104@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13ARM: dts: rockchip: fix rk322x hdmi ports nodeJohan Jonker
Fix rk322x hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/9b84adf0-9312-47fd-becc-cadd06941f70@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13ARM: dts: rockchip: fix rk3288 hdmi ports nodeJohan Jonker
Fix rk3288 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding with some reordering to align with the (new) documentation about property ordering. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/cc3a9b4f-076d-4660-b464-615003b6a066@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13KVM: arm64: Fix double-free following kvm_pgtable_stage2_free_unlinked()Will Deacon
kvm_pgtable_stage2_free_unlinked() does the final put_page() on the root page of the sub-tree before returning, so remove the additional put_page() invocations in the callers. Cc: Ricardo Koller <ricarkol@google.com> Fixes: f6a27d6dc51b2 ("KVM: arm64: Drop last page ref in kvm_pgtable_stage2_free_removed()") Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240212193052.27765-1-will@kernel.org
2024-02-13arm64: dts: rockchip: remove redundant cd-gpios from rk3588 sdmmc nodesKever Yang
The sdmmc node already have a "&sdmmc_det" for pinctrl which switch the GPIO0A4 to sdmmc detect function, no need to define a separate "cd-gpios". RK3588 has force_jtage feature which is enable JTAG function via sdmmc pins automatically when there is no SD card insert, this feature will need the GPIO0A4 works in sdmmc_det function like other mmc signal instead of GPIO function, or else the force_jtag can not auto be disabled when SD card insert. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Link: https://lore.kernel.org/r/20240201034621.1970279-1-kever.yang@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: Drop interrupts property from rk3328 pwm-rockchip nodeJohan Jonker
The binding doesn't define interrupts and adding such a definition was refused because it's unclear how they should ever be used and the relevant registers are outside the PWM range. So drop them fixing several dtbs_check warnings. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/5551846d-62cd-4b72-94f4-07541e726c37@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: set num-cs property for spi on px30Heiko Stuebner
The px30 has two spi controllers with two chip-selects each. The num-cs property is specified as the total number of chip selects a controllers has and is used since 2020 to find uses of chipselects outside that range in the Rockchip spi driver. Without the property set, the default is 1, so spi devices using the second chipselect will not be created. Fixes: eb1262e3cc8b ("spi: spi-rockchip: use num-cs property and ctlr->enable_gpiods") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20240119101656.965744-1-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: minor rk3588 whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space before '{' character. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240208105129.128561-1-krzysztof.kozlowski@linaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: add rs485 support on uart5 of px30-ringneck-haikouFarouk Bouabid
A hardware switch can set the rs485 transceiver into half or full duplex mode. Switching to the half-duplex mode requires the user to enable em485 on uart5 using ioctl, DE/RE are both connected to GPIO0_B5 which is the RTS signal for uart0. Implement GPIO0_B5 as rts-gpios with RTS_ON_SEND option enabled (default) so that driver mode gets enabled while sending (RTS high) and receiver mode gets enabled while not sending (RTS low). In full-duplex mode (em485 is disabled), DE is connected to GPIO0_B5 and RE is grounded (enabled). Since GPIO0_B5 is implemented as rts-gpios, the driver mode gets enabled whenever we want to send something and RE is not affected (always enabled) in this case by the state of RTS. Signed-off-by: Farouk Bouabid <farouk.bouabid@theobroma-systems.com> Link: https://lore.kernel.org/r/20240208-dev-rx-enable-v6-2-39e68e17a339@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: add rs485 support on uart2 of rk3399-puma-haikouFarouk Bouabid
A hardware switch can set the rs485 transceiver into half or full duplex mode. Switching to the half-duplex mode requires the user to enable em485 on uart5 using ioctl, DE/RE are both connected to GPIO2_C3 which is the RTS signal for uart0. Implement GPIO2_C3 as rts-gpios with RTS_ON_SEND option enabled (default) so that driver mode gets enabled while sending (RTS high) and receiver mode gets enabled while not sending (RTS low). In full-duplex mode (em485 is disabled), DE is connected to GPIO2_C3 and RE is grounded (enabled). Since GPIO2_C3 is implemented as rts-gpios, the driver mode gets enabled whenever we want to send something and RE is not affected (always enabled) in this case by the state of RTS. Signed-off-by: Farouk Bouabid <farouk.bouabid@theobroma-systems.com> Link: https://lore.kernel.org/r/20240208-dev-rx-enable-v6-1-39e68e17a339@theobroma-systems.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: Add Powkiddy RGB10MAX3Chris Morgan
Add support for the Powkiddy RGB10MAX3. The Powkiddy RGB10MAX3 is a handheld gaming device with a 720p 5.0 inch screen powered by the Rockchip RK3566 SoC. It includes a Realtek 8723ds WiFi/BT module, 2 ADC joysticks powered by a 4-way muxed ADC channel, and several GPIO face buttons. There are 2 SDMMC slots (sdmmc1 and sdmmc3), 3 pwm controlled LEDs, and the device includes 1GB of RAM. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20240212184950.52210-8-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3Chris Morgan
Move the vdd_cpu regulator to the device specific dts. This is in preparation of adding the Powkiddy RGB10MAX3 device, which uses a different vendor for the CPU regulator at a different i2c address. Also add a phandle to the bluetooth device so that we can change the compatible string for the RGB10MAX3. This device uses the same pinouts but a different bluetooth device. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20240212184950.52210-6-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-02-13riscv: dts: starfive: replace underscores in node namesKrzysztof Kozlowski
Underscores should not be used in node names (dtc with W=2 warns about them), so replace them with hyphens. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-02-13block: pass a queue_limits argument to blk_mq_alloc_diskChristoph Hellwig
Pass a queue_limits to blk_mq_alloc_disk and apply it if non-NULL. This will allow allocating queues with valid queue limits instead of setting the values one at a time later. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20240213073425.1621680-11-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-02-13arm64: dts: amlogic: t7: minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space before '{' character. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240208105252.128940-1-krzysztof.kozlowski@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-13arm64: dts: amlogic: axg: initialize default SoC capacitanceDmitry Rokosov
The capacitance value is required for the usage of the cpufreq cooling device and power_allocator thermal governor in the appropriate energy model. It helps to compute the power estimated by the SoC at the appropriate frequency. If it is the frequency of an existing OPP, or at the frequency of the first OPP above the requested value otherwise. The power is estimated as P = C * V^2 * f, with C being the SoC's capacitance and V and f respectively representing the voltage and frequency of the OPP. Since AXG SoC doesn't have SCMI protocol support, we need to initialize capacitance using the 'dynamic-power-coefficient' DT entry. Its value is retrieved from the vendor kernel, and it gives us the following freq2power mapping: +-----------+--------+ | frequency,| power, | | MHz | uW | +-----------+--------+ | 100 | 10354 | +-----------+--------+ | 250 | 27104 | +-----------+--------+ | 500 | 55447 | +-----------+--------+ | 667 | 77327 | +-----------+--------+ | 1000 | 129024 | +-----------+--------+ | 1200 | 164656 | +-----------+--------+ | 1296 | 192489 | +-----------+--------+ | 1416 | 239870 | +-----------+--------+ Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240209212816.11187-3-ddrokosov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-13arm64: dts: amlogic: axg: move cpu cooling-cells to common dtsiDmitry Rokosov
The CPU cooling-cells property should be located in the meson-axg common dtsi, as it is required for all AXG-based boards with DVFS. Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Viacheslav Bocharov <adeep@lexina.in> Link: https://lore.kernel.org/r/20240209212816.11187-2-ddrokosov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-13arch: arm64: dts: meson: a1: add assigned-clocks for usb nodeAlexey Romanov
To ensure proper functionality of USB, it is necessary to use the rate of 64000000 for CLKID_USB_BUS. For instance, adb may not function correctly without this setting. This information has been derived from the vendor SDK. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240124130623.3471236-1-avromanov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-13arm64: dts: amlogic: meson-g12-common: Set the rates of the clocks for the NPUTomeu Vizoso
Otherwise they are left at 24MHz and the NPU runs very slowly. Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Suggested-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240110153704.1364073-2-tomeu@tomeuvizoso.net Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-13arm64: dts: amlogic: add reset controller for Amlogic C3 SoCZelong Dong
Add the reset controller device of Amlogic C3 SoC family Signed-off-by: Zelong Dong <zelong.dong@amlogic.com> Reviewed-by: Dmitry Rokosov <ddrokosov@sberdevices.ru> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230914064018.18790-4-zelong.dong@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-02-12x86/mm/ident_map: Use gbpages only where full GB page should be mapped.Steve Wahl
When ident_pud_init() uses only gbpages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. On UV systems, this ends up including regions that will cause hardware to halt the system if accessed (these are marked "reserved" by BIOS). Even processor speculation into these regions is enough to trigger the system halt. Only use gbpages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full gbpage. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. [ dhansen: fix up comment formatting, simplifty changelog ] Signed-off-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com
2024-02-12MIPS: Clear Cause.BD in instruction_pointer_setJiaxun Yang
Clear Cause.BD after we use instruction_pointer_set to override EPC. This can prevent exception_epc check against instruction code at new return address. It won't be considered as "in delay slot" after epc being overridden anyway. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2024-02-12ptrace: Introduce exception_ip arch hookJiaxun Yang
On architectures with delay slot, architecture level instruction pointer (or program counter) in pt_regs may differ from where exception was triggered. Introduce exception_ip hook to invoke architecture code and determine actual instruction pointer to the exception. Link: https://lore.kernel.org/lkml/00d1b813-c55f-4365-8d81-d70258e10b16@app.fastmail.com/ Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2024-02-12MIPS: Add 'memory' clobber to csum_ipv6_magic() inline assemblerGuenter Roeck
After 'lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests' was applied, the test_csum_ipv6_magic unit test started failing for all mips platforms, both little and bit endian. Oddly enough, adding debug code into test_csum_ipv6_magic() made the problem disappear. The gcc manual says: "The "memory" clobber tells the compiler that the assembly code performs memory reads or writes to items other than those listed in the input and output operands (for example, accessing the memory pointed to by one of the input parameters) " This is definitely the case for csum_ipv6_magic(). Indeed, adding the 'memory' clobber fixes the problem. Cc: Charlie Jenkins <charlie@rivosinc.com> Cc: Palmer Dabbelt <palmer@rivosinc.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2024-02-12KVM: arm64: removed unused kern_hyp_va asm macroJoey Gouly
The last usage of this macro was removed in: commit 5dc33bd199ca ("KVM: arm64: nVHE: Pass pointers consistently to hyp-init") Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240208105422.3444159-3-joey.gouly@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-02-12KVM: arm64: add comments to __kern_hyp_vaJoey Gouly
Document this function a little, to make it easier to understand. The assembly comments were copied from the kern_hyp_va asm macro. Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240208105422.3444159-2-joey.gouly@arm.com [oliver: migrate a bit more detail from the asm variant] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-02-12KVM: arm64: print Hyp modeJoey Gouly
Print which of the hyp modes is being used (hVHE, nVHE). Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240209103719.3813599-1-joey.gouly@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-02-12x86/xen: Add some null pointer checking to smp.cKunwu Chan
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401161119.iof6BQsf-lkp@intel.com/ Suggested-by: Markus Elfring <Markus.Elfring@web.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20240119094948.275390-1-chentao@kylinos.cn Signed-off-by: Juergen Gross <jgross@suse.com>
2024-02-12arm64: cpufeatures: Only check for NV1 if NV is presentMarc Zyngier
We handle ID_AA64MMFR4_EL1.E2H0 being 0 as NV1 being present. However, this is only true if FEAT_NV is implemented. Add the required check to has_nv1(), avoiding spuriously advertising NV1 on HW that doesn't have NV at all. Fixes: da9af5071b25 ("arm64: cpufeature: Detect HCR_EL2.NV1 being RES0") Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240212144736.1933112-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-02-12arm64: cpufeatures: Add missing ID_AA64MMFR4_EL1 to __read_sysreg_by_encoding()Marc Zyngier
When triggering a CPU hotplug scenario, we reparse the CPU feature with SCOPE_LOCAL_CPU, for which we use __read_sysreg_by_encoding() to get the HW value for this CPU. As it turns out, we're missing the handling for ID_AA64MMFR4_EL1, and trigger a BUG(). Funnily enough, Marek isn't completely happy about that. Add the damn register to the list. Fixes: 805bb61f8279 ("arm64: cpufeature: Add ID_AA64MMFR4_EL1 handling") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240212144736.1933112-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-02-12s390/switch_to: use generic header fileHeiko Carstens
Move the switch_to() implementation to process.c and use the generic switch_to.h header file instead, like some other architectures. This addresses also the oddity that the old switch_to() implementation assigns the return value of __switch_to() to 'prev' instead of 'last', like it should. Remove also all includes of switch_to.h from C files, except process.c. Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-12s390/acrs: cleanup access register handlingHeiko Carstens
save_access_regs() and restore_access_regs() are only available by including switch_to.h. This is done by a couple of C files, which have nothing to do with switch_to(), but only need these functions. Move both functions to a new header file and improve the implementation: - Get rid of typedef - Add memory access instrumentation support - Use long displacement instructions lamy/stamy instead of lam/stam - all current users end up with better code because of this Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-12arm64: dts: fsd: Add fifosize for UART in Device TreeTamseel Shams
UART in FSD SoC has fifosize of 64 bytes. Set fifosize as 64 bytes for UART from Device Tree. Signed-off-by: Tamseel Shams <m.shams@samsung.com> Link: https://lore.kernel.org/r/20240205082625.39259-1-m.shams@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-12arm64: dts: exynos: gs101: minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space before '{' and around '=' characters. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20240208105243.128875-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-12arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodesRafał Miłecki
This fixes: arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240122132357.31264-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: reorder nodesRafał Miłecki
Use order described as preferred in DTS Coding Style: 1. Sort bus nodes by unit address 2. Use alpha-numerical order for the rest Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240212121620.15035-2-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: reorder propertiesRafał Miłecki
Use order described as preferred in DTS Coding Style. Mostly just move "compatible", "reg" and "ranges" properties. In two nodes also move vendor-prefixed props down. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240212121620.15035-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add Acelink EW-7886CAXRafał Miłecki
Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point. It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and on-SoC Wi-Fi. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231207080512.3688-3-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L boardAngeloGioacchino Del Regno
Add a device tree for the Radxa NIO 12L SBC, powered by the MediaTek MT8395 Genio 1200 SoC. This board features: * MT6359 + MT6360 PMICs at I2C-6 - Regulators, battery charger, TypeC Port Controller Interface - Audio through 3.5mm jack (2CH out, 1CH in) * Two MT6315 PMICs over SPMI - CPU-Big and GPU Core regulators * Network Connectivity - Realtek RTL8211FD MDIO PHY/Transceiver, 10/100/1000M Ethernet - MT7921E WiFi (PCIe1) / Bluetooth (USB 2.0) combo chip * Storage - On-board UFS storage - On-board eMMC on MMC0 controller - MicroSD card slot on MMC1 controller * Other connectivity - 1x USB Type-C Charging/Power only port - 1x USB 3.2 SuperSpeed Type-C OTG+DisplayPort mode - Muxed by ITE IT5205 Alternate Mode Passive MUX - 4x USB 3.0 Type-A ports on VL805 USB Hub (PCIe0) - 1x HDMI IN port - 1x HDMI OUT port - 1x MIPI DSI (Display) port - 2x MIPI CSI (Camera) ports * 40-pin Expansion Header - Two UART ports - I2C, SPI busses - I2S for external audio chips - ADC - GPIOs Link: https://lore.kernel.org/r/20240202114821.79227-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add video decoder device nodesYunfei Dong
Add mt8186 video decoder device nodes. Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Link: https://lore.kernel.org/r/20231220133302.39411-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8195: Add MTU3 nodes and correctly describe USBAngeloGioacchino Del Regno
The MT8195 SoC has four USB controllers: only one is a direct path to a XHCI controller, while the other three (0, 2 and 3) are behind the MTU3 DRD controller instead! Add the missing MTU3 nodes, default disabled, for controllers 0, 2 and 3 and move the related XHCI nodes to be children of their MTU3 DRD to correctly describe the SoC. In order to retain USB functionality on all of the MT8195 and MT8395 boards, also move the vusb33 supply and enable the relevant MTU3 nodes with special attention to the MT8195 Cherry Chromebook, where it was necessary to set the dr_mode of all MTU3 controllers to host to avoid interfering with the EC performing DRD on its own. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20240115084336.938426-1-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add MT8186 Magneton ChromebooksChen-Yu Tsai
Add entries for the MT8186 based Chromebooks, also collectively known as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on the "Steelix" design. Being a laptop instead of a convertible device, there is no stylus, which is similar to Rusty. However Magneton does not have ports on the right side of the device. Three variants are listed separately. These use different touchscreen controllers, or lack a touchscreen altogether. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-10-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add MT8186 Steelix platform based RustyChen-Yu Tsai
MT8186 Rusty, otherwise known as the Lenovo 100e Chromebook Gen 4, is an MT8186 based laptop. It is based on the "Steelix" design. Being a laptop instead of a convertible device, there is no touchscreen or stylus. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-9-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Introduce MT8186 SteelixChen-Yu Tsai
The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4, is a convertible device based on a common design of the same name. The device comes in different variants. Of them, whether a world facing camera is integrated is the only differentiating factor between the two device trees added. The different SKU IDs describe this alone. The other device difference is the trackpad component used. This is simply handled by having both possible components described in the device tree, and letting the implementation figure out which one is actually available. The system bootloader / firmware does not differentiate this in that they share the same SKU IDs. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-8-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>