summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-11-03fdget(), trivial conversionsAl Viro
fdget() is the first thing done in scope, all matching fdput() are immediately followed by leaving the scope. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-11-03introduce "fd_pos" class, convert fdget_pos() users to it.Al Viro
fdget_pos() for constructor, fdput_pos() for cleanup, all users of fd..._pos() converted trivially. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-11-03fdget_raw() users: switch to CLASS(fd_raw)Al Viro
Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-11-03arm64: dts: ti: k3-am62p5-sk: add 1.4ghz opp entryBryan Brattlof
The AM62Px reference board is capable of supplying 0v85 to the VDD_CORE which allows the Cortex-A53s to operate at 1.4GHz according to chapter 6.6 of the SoC's data sheet[0] . Append the 1.4Ghz entry to the OPP table to enable this frequency [0] https://www.ti.com/lit/ds/symlink/am62p-q1.pdf Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241008132052.407994-5-d-gole@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-03arm64: dts: ti: k3-am62p: add opp frequenciesBryan Brattlof
One power management technique available to the Cortex-A53s is their ability to dynamically scale their frequency across the device's Operating Performance Points (OPP) The OPPs available for the Cortex-A53s on the AM62Px can vary based on the silicon variant used. The SoC variant is encoded into the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit the OPP entries the SoC supports. A table of all these variants can be found in its data sheet[0] for the AM62Px processor family. Add the OPP table into the SoC's fdti file along with the syscon node to describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect the SoC variant. [0] https://www.ti.com/lit/ds/symlink/am62p-q1.pdf Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241008132052.407994-4-d-gole@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-03arm64: dts: ti: k3-am62a7-sk: add 1.4ghz opp entryBryan Brattlof
The AM62Ax reference board is capable of supplying 0v85 to the VDD_CORE which allows the Cortex-A53s to operate at 1.4GHz according to chapter 7.5 of the SoC's data sheet[0]. Append the 1.4Ghz entry to the OPP table to enable this OPP [0] https://www.ti.com/lit/ds/symlink/am62a3.pdf Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241008132052.407994-3-d-gole@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-03arm64: dts: ti: k3-am62a: add opp frequenciesBryan Brattlof
One power management technique available to the Cortex-A53s is their ability to dynamically scale their frequency across the device's Operating Performance Points (OPP) The OPPs available for the Cortex-A53s on the AM62Ax can vary based on the silicon variant used. The SoC variant is encoded into the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register which is used to limit to only OPP entries the variant supports. A table of all these variants can be found in it's data sheet[0] for the AM62Ax family. Add the OPP table into the SoC's fdti file along with the syscon node to describe the WKUP_MMR0_WKUP0_CTRL_MMR0_JTAG_USER_ID register to detect the SoC variant. [0] https://www.ti.com/lit/ds/symlink/am62a3.pdf Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241008132052.407994-2-d-gole@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-03arm64: dts: ti: k3-am62-verdin: Add Ivy carrier boardJoão Paulo Gonçalves
Add Toradex Verdin Ivy carrier board support. One notable feature of Ivy is the analog inputs. These inputs are multiplexed, allowing the same input to measure either voltage or current. For current measurements, a GPIO switch enables or disables the shunt resistor. This process is automatically managed by the Linux kernel using the IIO and MUX subsystems. Voltage measurement is always enabled, but the voltage measured by the ADC is scaled by a cascade voltage divider. In the device tree, the equivalent gain of the voltage divider is used, which can be calculated as follows: ------------ + | .-. R1=30K | | | | '-' |------------------- Analog Input (AIN) | | .-. .-. R2=10K | | R3=30K | | | | | | '-' '-' | | | |-------- | .-. + | R4=10K | | | | | ADC Input (Channels 0 and 1) | '-' - | | - -----------| |-------- === === GND GND Vin = Analog Input (AIN) Vout = ADC Input Rth = Thevenin Equiv. Resistance Vth = Thevenin Equiv. Voltage RL = Load Resistor R1 = 30K, R2 = 10K, R3 = 30K, R4 = 10K RL = R4 = 10K Rth = (R1 // R2) + R3 = 37500 Ohms Vth = (Vin * R2) / (R1 + R2) = Vin/4; Vout = (Vth * RL)/ (Rth + RL) = Vth/4.75 = Vin/19 Gain = Vout/Vin = 1/19 https://www.toradex.com/products/carrier-board/ivy-carrier-board Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240924120044.130913-4-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-03arm64: dts: ti: k3-am62-verdin: add label to som adc nodeJoão Paulo Gonçalves
Add a label to ti-ads1015 node to make it easier to reference it from other nodes. Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240924120044.130913-3-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-11-02x86/vdso: Add missing brackets in switch caseThomas Gleixner
0-day reported: arch/x86/entry/vdso/vma.c:199:3: warning: label followed by a declaration is a C23 extension [-Wc23-extensions] Add the missing brackets. Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Closes: https://lore.kernel.org/oe-kbuild-all/202411022359.fBPFTg2T-lkp@intel.com/
2024-11-02vdso: Rename struct arch_vdso_data to arch_vdso_time_dataNam Cao
The struct arch_vdso_data is only about vdso time data. So rename it to arch_vdso_time_data to make it obvious. Non time-related data will be migrated out of these structs soon. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390 Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-28-b64f0842d512@linutronix.de
2024-11-02powerpc: Split systemcfg struct definitions out from vdsoThomas Weißschuh
The systemcfg data has nothing to do anymore with the vdso. Split it into a dedicated header file. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-27-b64f0842d512@linutronix.de
2024-11-02powerpc: Split systemcfg data out of vdso data pageThomas Weißschuh
The systemcfg data only has minimal overlap with the vdso data. Splitting the two avoids mapping the implementation-defined vdso data into /proc/ppc64/systemcfg. It is also a preparation for the standardization of vdso data storage. The only field actually used by both systemcfg and vdso is tb_ticks_per_sec and it is only changed once during time_init(). Initialize it in both structures there. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-26-b64f0842d512@linutronix.de
2024-11-02powerpc: Add kconfig option for the systemcfg pageThomas Weißschuh
The systemcfg page through procfs is only a backwards-compatible interface for very old applications. Make it possible to be disabled. This also creates a convenient config #define to guard any accesses to the systemcfg page. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-25-b64f0842d512@linutronix.de
2024-11-02powerpc/pseries/lparcfg: Use num_possible_cpus() for potential processorsThomas Weißschuh
The systemcfg processorCount variable tracks currently online variables, not possible ones, so the stored value is wrong. The code preferably tries to use the ibm,lrdr-capacity field 4 which "represents the maximum number of processors that the guest can have." Switch from processorCount to the better matching num_possible_cpus(). Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-24-b64f0842d512@linutronix.de
2024-11-02powerpc/pseries/lparcfg: Fix printing of system_active_processorsThomas Weißschuh
When printing the information "system_active_processors", the variable partition_potential_processors is used instead of partition_active_processors. The wrong value is displayed. Use partition_active_processors instead. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-23-b64f0842d512@linutronix.de
2024-11-02powerpc/procfs: Propagate error of remap_pfn_range()Thomas Weißschuh
If the operation fails and userspace is unaware it will access unmapped memory, crashing the process. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-22-b64f0842d512@linutronix.de
2024-11-02powerpc/vdso: Remove offset comment from 32bit vdso_arch_dataThomas Weißschuh
This offset was copy-pasted from the systemcfg structure. It has no meaning for the 32bit VDSO. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-21-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Split virtual clock pages into dedicated mappingThomas Weißschuh
The generic vdso data storage cannot handle the special pvclock and hvclock pages. Split them into their own mapping, so the other vdso storage can be migrated to the generic code. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-20-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Delete vvar.hThomas Weißschuh
All users have been removed. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-19-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Access vdso data without vvar.hThomas Weißschuh
The vdso_data is at the start of the vvar page. Make use of this invariant to remove the usage of vvar.h. This also matches the logic for the timens data. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-18-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Move the rng offset to vsyscall.hThomas Weißschuh
vvar.h will go away, so move the last useful bit into vsyscall.h. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-17-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Access rng vdso data without vvar.hThomas Weißschuh
The vdso_rng_data is at a well-known offset in the vvar page. Make use of this invariant to remove the usage of vvar.h. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-16-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Access timens vdso data without vvar.hThomas Weißschuh
The vdso_data is at the start of the timens page. Make use of this invariant to remove the usage of vvar.h. This also matches the logic for the pvclock and hvclock pages. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-15-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Allocate vvar page from C codeThomas Weißschuh
Allocate the vvar page through the standard union vdso_data_store and remove the custom linker script logic. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-14-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Access rng data from kernel without vvarThomas Weißschuh
Remove the usage of the vvar _vdso_rng_data from the kernel-space code, as the x86 vvar machinery is about to be removed. The definition of the structure is unnecessary, as the data lives in a page pre-allocated by the linker anyways. The vdso user-space access to the rng data will be switched soon. DEFINE_VVAR_SINGLE() is now unused. It will be removed later togehter with the rest of vvar.h. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-13-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Place vdso_data at beginning of vvar pageThomas Weißschuh
The offset of the vdso_data only has historic reasons, as back then other vvars also existed and offset 0 was already used. (See commit 8c49d9a74bac ("x86-64: Clean up vdso/kernel shared variables")) Over time most other vvars got removed and offset 0 is free again. Moving vdso_data to the beginning of the vvar page aligns x86 with other architectures and opens up the way for the removal of the custom x86 vvar machinery. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-12-b64f0842d512@linutronix.de
2024-11-02x86/vdso: Use __arch_get_vdso_data() to access vdso dataThomas Weißschuh
The implementation details of the vdso_data access will change. Prepare for that by using the existing helper function. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-11-b64f0842d512@linutronix.de
2024-11-02x86/mm/mmap: Remove arch_vma_name()Thomas Weißschuh
This function does not contain any logic, delete it so the equivalent weak definition from kernel/signal.c is used instead. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-10-b64f0842d512@linutronix.de
2024-11-02MIPS: vdso: Avoid name conflict around "vdso_data"Thomas Weißschuh
The generic vdso/datapage.h declares a symbol named "vdso_data". Avoid a conflict by renaming the identically named variable in genvdso.c. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-9-b64f0842d512@linutronix.de
2024-11-02LoongArch: vDSO: Use vdso/datapage.h to access vDSO dataThomas Weißschuh
vdso/datapage.h provides symbols and functions to ease the access to shared vDSO data from both the kernel and the vDSO. Make use of it to simplify the current code and also prepare for further changes unifying the vDSO data storage between architectures. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-8-b64f0842d512@linutronix.de
2024-11-02ARM: vdso: Remove assembly for datapage accessThomas Weißschuh
vdso/datapage.h provides a hidden declaration for _vdso_data. When using it the compiler will automatically generate PC-relative accesses which avoids the need for a custom assembly-based accessor. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-7-b64f0842d512@linutronix.de
2024-11-02riscv: vdso: Use only one single vvar mappingThomas Weißschuh
The vvar mapping is the same for all processes. Use a single mapping to simplify the logic and align it with the other architectures. In addition this will enable the move of the vvar handling into generic code. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-6-b64f0842d512@linutronix.de
2024-11-02arm64: vdso: Use only one single vvar mappingThomas Weißschuh
The vvar mapping is the same for all processes. Use a single mapping to simplify the logic and align it with the other architectures. In addition this will enable the move of the vvar handling into generic code. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Will Deacon <will@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-5-b64f0842d512@linutronix.de
2024-11-02arm64: vdso: Drop LBASE_VDSOThomas Weißschuh
This constant is always "0", providing no value and making the logic harder to understand. Also prepare for a consolidation of the vdso linkerscript logic by aligning it with other architectures. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-4-b64f0842d512@linutronix.de
2024-11-02s390/vdso: Drop LBASE_VDSOThomas Weißschuh
This constant is always "0", providing no value and making the logic harder to understand. Also prepare for a consolidation of the vdso linkerscript logic by aligning it with other architectures. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-3-b64f0842d512@linutronix.de
2024-11-02csky/vdso: Remove arch_vma_name()Thomas Weißschuh
All callers of arch_vma_name() also get the name via vm_ops, which for these VMAs will use the name from 'struct vma_special_mapping'. Therefore the custom implementation is unnecessary and can be removed in favor of the default implementation from kernel/signal.c. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-2-b64f0842d512@linutronix.de
2024-11-02csky/vdso: Remove gettimeofday() and friends from VDSOThomas Weißschuh
The time-related VDSO functionality was introduced in 2021 in commit 87f3248cdb9a ("csky: Reconstruct VDSO framework") and commit 0d3b051adbb7 ("csky: Add VDSO with GENERIC_GETTIMEOFDAY, GENERIC_TIME_VSYSCALL, HAVE_GENERIC_VDSO"). However the corresponding aux-vector entry AT_SYSINFO_EHDR was never wired up, making these functions impossible to test or use. The VDSO itself is kept as it also provides rt_sigreturn which is exposed differently to userspace. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241010-vdso-generic-base-v1-1-b64f0842d512@linutronix.de
2024-11-02arm64: allwinner: a100: Add MMC related nodesYangtao Li
The A100 has 3 MMC controllers, one of them being especially targeted to eMMC. Let's add nodes on dts. Signed-off-by: Yangtao Li <frank@allwinnertech.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Link: https://patch.msgid.link/20241031070232.1793078-10-masterr3c0rd@epochal.quest Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-02arm64: dts: allwinner: a100: add usb related nodesYangtao Li
The Allwinner A100 has two HCI USB controllers, a OTG controller and a USB PHY. The PHY is compatible with that used by the D1, while the OTG controller is compatible with the A33. Add nodes for these to the base DTSI. Signed-off-by: Yangtao Li <frank@allwinnertech.com> [masterr3c0rd@epochal.quest: fallback to a33-musb and d1-usb-phy, edited message] Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Parthiban Nallathambi <parthiban@linumiz.com> Link: https://patch.msgid.link/20241031070232.1793078-7-masterr3c0rd@epochal.quest Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-02arm64: dts: allwinner: a100: add watchdog nodeYangtao Li
Declare A100's watchdog in the device-tree. Signed-off-by: Yangtao Li <frank@allwinnertech.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Tested-by: Parthiban Nallathambi <parthiban@linumiz.com> Link: https://patch.msgid.link/20241031070232.1793078-3-masterr3c0rd@epochal.quest Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-02arm64: dts: allwinner: A100: Add PMU modeYangtao Li
Add the Performance Monitoring Unit (PMU) device tree node to the A100 .dtsi, which tells DT users which interrupts are triggered by PMU overflow events on each core. Signed-off-by: Yangtao Li <frank@allwinnertech.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Link: https://patch.msgid.link/20241031070232.1793078-2-masterr3c0rd@epochal.quest Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-02riscv: dts: sophgo: Add emmc support for Huashan PiInochi Amaoto
Add emmc node configuration for Huashan Pi. Link: https://lore.kernel.org/r/20241025112902.1200716-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-11-02riscv: dts: sophgo: Add sdio configuration for Huashan PiInochi Amaoto
Add configuration for sdio for Huashan Pi to support sdio wifi. Link: https://lore.kernel.org/r/20241025112902.1200716-2-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-11-02riscv: dts: sophgo: fix pinctrl base-addressThomas Bonnefille
Fix the base-address of the pinctrl controller to match its register address. Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Fixes: 93b61555f509 ("riscv: dts: sophgo: Add initial SG2002 SoC device tree") Link: https://lore.kernel.org/r/20241028-fix-address-v1-1-dcbe21e59ccf@bootlin.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-11-02timekeeping: Always check for negative motionThomas Gleixner
clocksource_delta() has two variants. One with a check for negative motion, which is only selected by x86. This is a historic leftover as this function was previously used in the time getter hot paths. Since 135225a363ae timekeeping_cycles_to_ns() has unconditional protection against this as a by-product of the protection against 64bit math overflow. clocksource_delta() is only used in the clocksource watchdog and in timekeeping_advance(). The extra conditional there is not hurting anyone. Remove the config option and unconditionally prevent negative motion of the readout. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: John Stultz <jstultz@google.com> Link: https://lore.kernel.org/all/20241031120328.599430157@linutronix.de
2024-11-02timekeeping: Remove CONFIG_DEBUG_TIMEKEEPINGThomas Gleixner
Since 135225a363ae timekeeping_cycles_to_ns() handles large offsets which would lead to 64bit multiplication overflows correctly. It's also protected against negative motion of the clocksource unconditionally, which was exclusive to x86 before. timekeeping_advance() handles large offsets already correctly. That means the value of CONFIG_DEBUG_TIMEKEEPING which analyzed these cases is very close to zero. Remove all of it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: John Stultz <jstultz@google.com> Link: https://lore.kernel.org/all/20241031120328.536010148@linutronix.de
2024-11-02ARM: dts: imx6sll: Improve gpc descriptionFabio Estevam
According to fsl,imx-gpc.yaml, 'clocks', 'clock-names', and 'pgc' are required properties. Describe them to fix the following dt-schema warnings: interrupt-controller@20dc000: 'clocks' is a required property interrupt-controller@20dc000: 'clock-names' is a required property interrupt-controller@20dc000: 'pgc' is a required property Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-11-02ARM: dts: imx6sl: Pass tempmon #thermal-sensor-cellsFabio Estevam
According to fsl,imx-anatop.yaml, #thermal-sensor-cells is a required property. Add it to fix the following dt-schema warning: tempmon: '#thermal-sensor-cells' is a required property Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-11-02ARM: dts: imx6sx: Fix tempmon descriptionFabio Estevam
According to imx-thermal.yaml, the valid compatible string for i.MX6SX is just: compatible = "fsl,imx6sx-tempmon". Also pass #thermal-sensor-cells = <0> as it is a required property. Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-23 20:02:57 +0000