summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-11-04arm64: dts: imx8-ss-audio: configure dsp node for rproc usageLaurentiu Mihalcea
The 'dsp' node is currently configured for running an audio firmware. Since the firmware requires that some audio-related IPs be disabled in Linux, this will clash with the configurations from the imx8 board DTs (i.e: imx8qm-mek, imx8qxp-mek, etc...), thus making the dsp unusable (since the firmware won't function properly). To avoid this issue, configure the 'dsp' node for rproc. This way, users will be able to use the dsp alongside the board-level audio configuration as long as the firmware doesn't need the audio IPs. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-11-04ARM: imx_v6_v7_defconfig: Enable drivers for Kobo Clara 2EAndreas Kemnade
Enable drivers used on Kobo Clara 2E Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-11-04ARM: dts: imx: Add devicetree for Kobo Clara 2EAndreas Kemnade
Adds a devicetree for the Kobo Clara 2E Ebook reader. It is based on boards marked with "37NB-E60K2M+4A2" or "37NB-E60K2M+4B0". It is equipped with an i.MX6SLL SoC. Expected to work: - Buttons - Wifi - Bluetooth (if Wifi is initialized first, driver does not handle regulators yet) - LED - uSD - USB - RTC - Touchscreen Add human-readable comments for devices without mainlined driver and binding. Such comments can e.g. be help to find testers if someone starts to work on the missing drivers. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-11-04powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clangNathan Chancellor
Under certain conditions, the 64-bit '-mstack-protector-guard' flags may end up in the 32-bit vDSO flags, resulting in build failures due to the structure of clang's argument parsing of the stack protector options, which validates the arguments of the stack protector guard flags unconditionally in the frontend, choking on the 64-bit values when targeting 32-bit: clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2 clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2 make[3]: *** [arch/powerpc/kernel/vdso/Makefile:85: arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1 make[3]: *** [arch/powerpc/kernel/vdso/Makefile:87: arch/powerpc/kernel/vdso/vgetrandom-32.o] Error 1 Remove these flags by adding them to the CC32FLAGSREMOVE variable, which already handles situations similar to this. Additionally, reformat and align a comment better for the expanding CONFIG_CC_IS_CLANG block. Cc: stable@vger.kernel.org # v6.1+ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20241030-powerpc-vdso-drop-stackp-flags-clang-v1-1-d95e7376d29c@kernel.org
2024-11-03Merge tag 'for-netdev' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2024-10-31 We've added 13 non-merge commits during the last 16 day(s) which contain a total of 16 files changed, 710 insertions(+), 668 deletions(-). The main changes are: 1) Optimize and homogenize bpf_csum_diff helper for all archs and also add a batch of new BPF selftests for it, from Puranjay Mohan. 2) Rewrite and migrate the test_tcp_check_syncookie.sh BPF selftest into test_progs so that it can be run in BPF CI, from Alexis Lothoré. 3) Two BPF sockmap selftest fixes, from Zijian Zhang. 4) Small XDP synproxy BPF selftest cleanup to remove IP_DF check, from Vincent Li. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: selftests/bpf: Add a selftest for bpf_csum_diff() selftests/bpf: Don't mask result of bpf_csum_diff() in test_verifier bpf: bpf_csum_diff: Optimize and homogenize for all archs net: checksum: Move from32to16() to generic header selftests/bpf: remove xdp_synproxy IP_DF check selftests/bpf: remove test_tcp_check_syncookie selftests/bpf: test MSS value returned with bpf_tcp_gen_syncookie selftests/bpf: add ipv4 and dual ipv4/ipv6 support in btf_skc_cls_ingress selftests/bpf: get rid of global vars in btf_skc_cls_ingress selftests/bpf: add missing ns cleanups in btf_skc_cls_ingress selftests/bpf: factorize conn and syncookies tests in a single runner selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap selftests/bpf: Fix msg_verify_data in test_sockmap ==================== Link: https://patch.msgid.link/20241031221543.108853-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03Merge tag 'x86-urgent-2024-11-03' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Thomas Gleixner: "A trivial compile test fix for x86: When CONFIG_AMD_NB is not set a COMPILE_TEST of an AMD specific driver fails due to a missing inline stub. Add the stub to cure it" * tag 'x86-urgent-2024-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB
2024-11-03arm64: defconfig: Enable VBATTB clock and Renesas RTCA-3Claudiu Beznea
Enable the Renesas VBATTB clock and RTCA-3 RTC drivers. These are available on the Renesas RZ/G3S SoC. VBATTB is the clock provider for the RTC counter. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-10-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: rzg3s-smarc-som: Enable RTCClaudiu Beznea
Enable RTC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-9-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: rzg3s-smarc-som: Enable VBATTBClaudiu Beznea
Enable the VBATTB controller. It provides the clock for RTC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-8-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: r9a08g045: Add RTC nodeClaudiu Beznea
Add the DT node for the RTC IP available on the Renesas RZ/G3S SoC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-7-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: r9a08g045: Add VBATTB nodeClaudiu Beznea
Add the DT node for the VBATTB IP along with DT bindings for the clock it provides. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-6-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: white-hawk-cpu-common: Add pin control for DSI-eDP IRQGeert Uytterhoeven
When the DSI to eDP bridge was added, pin control for the IRQ pin was left out, because the pin controller did not support INTC-EX pins yet. Commit 10544ec1b3436037 ("pinctrl: renesas: r8a779g0: Add INTC-EX pins, groups, and function") added support for these pins, so add the missing pin control description. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/89bab2008891be1f003a3c0dbcdf36af3b98da70.1729240573.git.geert+renesas@glider.be
2024-11-03ARM: dts: renesas: r7s72100: Add DMA support to MMCIFWolfram Sang
Add DMA properties to the device node for the MMC Host Interface. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20241015224801.2535-6-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03ARM: dts: renesas: r7s72100: Add DMAC nodeWolfram Sang
Add a device node for the Direct Memory Access Controller on the RZ/A1H SoC. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20241015224801.2535-5-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03arm64: dts: renesas: hihope: Drop #sound-dai-cellsLad Prabhakar
"#sound-dai-cells" is required if the board is using "simple-card". However, the HiHope board uses "audio-graph", thus remove the unneeded `#sound-dai-cells`. Commit 9e72606cd2db ("arm64: dts: renesas: #sound-dai-cells is used when simple-card") updated the comment regarding usage of "#sound-dai-cells" in the SoC DTSI but missed to remove "#sound-dai-cells" from board DTS files. Fixes: 9e72606cd2db ("arm64: dts: renesas: #sound-dai-cells is used when simple-card") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/20241010135332.710648-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-03convert spu_run(2)Al Viro
all failure exits prior to fdget() are returns, fdput() is immediately followed by return. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-11-03switch spufs_calls_{get,put}() to CLASS() useAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
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
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-10 04:42:16 +0000