summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-12-26arm64: dts: allwinner: a64: Add MIPI DSI pipelineJagan Teki
Add MIPI DSI pipeline for Allwinner A64. - dsi node, with A64 compatible since it doesn't support DSI_SCLK gating unlike A33 - dphy node, with A64 compatible with A33 fallback since DPHY on A64 and A33 is similar - finally, attach the dsi_in to tcon0 for complete MIPI DSI Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Merlijn Wajer <merlijn@wizzup.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-26arm64: dts: allwinner: a64: Add thermal sensors and thermal zonesVasily Khoruzhick
A64 has 3 thermal sensors: 1 for CPU, 2 for GPU. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-26arm64: dts: allwinner: h5: Add thermal sensor and thermal zonesOndrej Jirman
There are two sensors, one for CPU, one for GPU. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-26ARM: dts: sun8i-h3: Add thermal sensor and thermal zonesOndrej Jirman
There is just one sensor for the CPU. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-26ARM: dts: sun8i-a83t: Add thermal sensor and thermal zonesOndrej Jirman
There are three sensors, two for each CPU cluster, one for GPU. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-26ARM: dts: ux500: samsung-golden: Add BluetoothStephan Gerhold
samsung-golden uses a BCM4334 WiFi+BT combo chip. The BT part is connected via UART and supported by the hci_bcm driver in mainline. Add the necessary device tree changes to make it load correctly. It requires (seemingly) device-specific firmware that can be extracted from the stock Android system used on samsung-golden: - /system/bin/bcm4334.hcd -> /lib/firmware/brcm/BCM4334B0.hcd On my device, scanning for other Bluetooth devices works just fine, but for some reason it keeps disconnecting immediately when attempting to connect to an other device. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-9-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: samsung-golden: Add WiFiStephan Gerhold
samsung-golden uses a BCM4334 WiFi+BT combo chip, connected to SDIO. It is supported by the brcmfmac driver in mainline, so we only need to set up the device tree to make it work correctly. Note: brcmfmac requires (proprietary) firmware + a device-specific NVRAM file. Both can be extracted from the stock Android system used on samsung-golden: - /system/etc/wifi/bcmdhd_sta.bin_b2 -> /lib/firmware/brcm/brcmfmac4334-sdio.bin - /system/etc/wifi/nvram_net.txt_GPIO4 -> /lib/firmware/brcm/brcmfmac4334-sdio.samsung,golden.txt brcmfmac4334-sdio.bin from linux-firmware also seems to work, but results in occasional errors for some reason. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-8-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: samsung-golden: Add touch screenStephan Gerhold
samsung-golden has an Atmel mXT224S touch controller connected to I2C. It is supported by the existing driver for atmel,maxtouch, so all we need to do to make it work is to define the necessary device tree nodes. The atmel_mxt_ts driver does not support controlling regulators yet, so add regulator-always-on for now to turn on the necessary regulators. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-7-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: samsung-golden: Add IMU (accelerometer + gyroscope)Stephan Gerhold
samsung-golden has a InvenSense MPU-6051M IMU that provides an accelerometer and gyroscope. It seems to be functionally compatible with MPU-6050 so we can easily enable it by adding the necessary device tree nodes. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-6-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: Add device tree for Samsung Galaxy S III mini (GT-I8190)Stephan Gerhold
The Samsung Galaxy S III mini (GT-I8190) is a smartphone with Ux500 SoC released in 2012. Thanks to the great mainline support for Ux500, it can actually run mainline Linux quite well. Add a new device tree for it with support for: - Internal Storage (eMMC) - External Storage (Micro SD card) - UART - GPIO Buttons - Vibrator Note that the device tree cannot be booted directly with the original (Samsung) bootloader. It keeps the L2 cache turned on, which causes the kernel to hang shortly after decompression. As a workaround I have created a port of (mainline) U-Boot, which locks the L2 cache before booting Linux. At the moment it does not replace the Samsung bootloader, instead we let the original bootloader load U-Boot as an another (intermediate) bootloader. Another advantage of this is that U-Boot has proper device tree support, so we do not need to hardcode the kernel command line in the device tree. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-5-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: Add device tree include for AB8505Stephan Gerhold
AB8505 is a slightly newer version of AB8500. Overall it is quite similar, but there are some differences like the number of GPIOs and regulators. Therefore we need a separate device tree definition for devices making use of AB8505. The AB8500-specific nodes were moved out of ste-dbx5x0.dtsi in commit a46f7c6762d8 ("ARM: dts: ux500: Move ab8500 nodes to ste-ab8500.dtsi"). Add a new "ste-ab8505.dtsi" device tree include in a similar way. Keep the battery/charging related sub-devices disabled by default since they require additional configuration to work correctly. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-3-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-26ARM: dts: ux500: Remove unused ste-href-ab8505.dtsiStephan Gerhold
The pin configuration for HREF boards with AB8505 was added in commit 77ad9dfc2c7e ("ARM: ux500: move last AB8505 set-up to DT"). As the commit message notes, it was unused back then and it has remained so even today, especially considering AB8505 did not have proper device tree support until recently. We are now preparing to add support for some Samsung smartphones that are using AB8505. However, they use different pin configs because using ste-href-ab8505.dtsi is known to break UART. There were not many HREFs with AB8505, so at this point it seems unlikely that we will ever make use of this include. Remove it. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191219202052.19039-2-stephan@gerhold.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-25efi/libstub/x86: Avoid globals to store context during mixed mode callsArd Biesheuvel
Instead of storing the return address in a global variable when calling a 32-bit EFI service from the 64-bit stub, avoid the indirection via efi_exit32, and take the return address from the stack. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-26-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Rename efi_call_early/_runtime macros to be more intuitiveArd Biesheuvel
The macros efi_call_early and efi_call_runtime are used to call EFI boot services and runtime services, respectively. However, the naming is confusing, given that the early vs runtime distinction may suggest that these are used for calling the same set of services either early or late (== at runtime), while in reality, the sets of services they can be used with are completely disjoint, and efi_call_runtime is also only usable in 'early' code. So do a global sweep to replace all occurrences with efi_bs_call or efi_rt_call, respectively, where BS and RT match the idiom used by the UEFI spec to refer to boot time or runtime services. While at it, use 'func' as the macro parameter name for the function pointers, which is less likely to collide and cause weird build errors. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop 'table' argument from efi_table_attr() macroArd Biesheuvel
None of the definitions of the efi_table_attr() still refer to their 'table' argument so let's get rid of it entirely. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-23-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop protocol argument from efi_call_proto() macroArd Biesheuvel
After refactoring the mixed mode support code, efi_call_proto() no longer uses its protocol argument in any of its implementation, so let's remove it altogether. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-22-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub/x86: Work around page freeing issue in mixed modeArd Biesheuvel
Mixed mode translates calls from the 64-bit kernel into the 32-bit firmware by wrapping them in a call to a thunking routine that pushes a 32-bit word onto the stack for each argument passed to the function, regardless of the argument type. This works surprisingly well for most services and protocols, with the exception of ones that take explicit 64-bit arguments. efi_free() invokes the FreePages() EFI boot service, which takes a efi_physical_addr_t as its address argument, and this is one of those 64-bit types. This means that the 32-bit firmware will interpret the (addr, size) pair as a single 64-bit quantity, and since it is guaranteed to have the high word set (as size > 0), it will always fail due to the fact that EFI memory allocations are always < 4 GB on 32-bit firmware. So let's fix this by giving the thunking code a little hand, and pass two values for the address, and a third one for the size. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-21-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Remove 'sys_table_arg' from all function prototypesArd Biesheuvel
We have a helper efi_system_table() that gives us the address of the EFI system table in memory, so there is no longer point in passing it around from each function to the next. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop sys_table_arg from printk routinesArd Biesheuvel
As a first step towards getting rid of the need to pass around a function parameter 'sys_table_arg' pointing to the EFI system table, remove the references to it in the printing code, which is represents the majority of the use cases. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-19-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub/x86: Drop __efi_early() export and efi_config structArd Biesheuvel
The various pointers we stash in the efi_config struct which we retrieve using __efi_early() are simply copies of the ones in the EFI system table, which we have started accessing directly in the previous patch. So drop all the __efi_early() related plumbing, as well as all the assembly code dealing with efi_config, which allows us to move the PE/COFF entry point to C code as well. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-18-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Unify the efi_char16_printk implementationsArd Biesheuvel
Use a single implementation for efi_char16_printk() across all architectures. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-17-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Get rid of 'sys_table_arg' macro parameterArd Biesheuvel
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg' existing in the scope of the macro instantiation. Since this variable always points to the same data structure, let's create a global getter for it and use that instead. Note that the use of a global variable with external linkage is avoided, given the problems we had in the past with early processing of the GOT tables. While at it, drop the redundant casts in the efi_table_attr and efi_call_proto macros. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-16-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub/x86: Avoid thunking for native firmware callsArd Biesheuvel
We use special wrapper routines to invoke firmware services in the native case as well as the mixed mode case. For mixed mode, the need is obvious, but for the native cases, we can simply rely on the compiler to generate the indirect call, given that GCC now has support for the MS calling convention (and has had it for quite some time now). Note that on i386, the decompressor and the EFI stub are not built with -mregparm=3 like the rest of the i386 kernel, so we can safely allow the compiler to emit the indirect calls here as well. So drop all the wrappers and indirection, and switch to either native calls, or direct calls into the thunk routine for mixed mode. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-14-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Annotate firmware routines as __efiapiArd Biesheuvel
Annotate all the firmware routines (boot services, runtime services and protocol methods) called in the boot context as __efiapi, and make it expand to __attribute__((ms_abi)) on 64-bit x86. This allows us to use the compiler to generate the calls into firmware that use the MS calling convention instead of the SysV one. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-13-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Use stricter typing for firmware function pointersArd Biesheuvel
We will soon remove another level of pointer casting, so let's make sure all type handling involving firmware calls at boot time is correct. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-12-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Drop explicit 32/64-bit protocol definitionsArd Biesheuvel
Now that we have incorporated the mixed mode protocol definitions into the native ones using unions, we no longer need the separate 32/64 bit struct definitions, with the exception of the EFI system table definition and the boot services, runtime services and configuration table definitions. So drop the unused ones. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-11-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Distinguish between native/mixed not 32/64 bitArd Biesheuvel
Currently, we support mixed mode by casting all boot time firmware calls to 64-bit explicitly on native 64-bit systems, and to 32-bit on 32-bit systems or 64-bit systems running with 32-bit firmware. Due to this explicit awareness of the bitness in the code, we do a lot of casting even on generic code that is shared with other architectures, where mixed mode does not even exist. This casting leads to loss of coverage of type checking by the compiler, which we should try to avoid. So instead of distinguishing between 32-bit vs 64-bit, distinguish between native vs mixed, and limit all the nasty casting and pointer mangling to the code that actually deals with mixed mode. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-10-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Extend native protocol definitions with mixed_mode aliasesArd Biesheuvel
In preparation of moving to a native vs. mixed mode split rather than a 32 vs. 64 bit split when it comes to invoking EFI firmware services, update all the native protocol definitions and redefine them as unions containing an anonymous struct for the native view and a struct called 'mixed_mode' describing the 32-bit view of the protocol when called from 64-bit code. While at it, flesh out some PCI I/O member definitions that we will be needing shortly. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-9-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Use a helper to iterate over a EFI handle arrayArd Biesheuvel
Iterating over a EFI handle array is a bit finicky, since we have to take mixed mode into account, where handles are only 32-bit while the native efi_handle_t type is 64-bit. So introduce a helper, and replace the various occurrences of this pattern. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-8-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/x86: Rename efi_is_native() to efi_is_mixed()Ard Biesheuvel
The ARM architecture does not permit combining 32-bit and 64-bit code at the same privilege level, and so EFI mixed mode is strictly a x86 concept. In preparation of turning the 32/64 bit distinction in shared stub code to a native vs mixed one, refactor x86's current use of the helper function efi_is_native() into efi_is_mixed(). Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-7-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25efi/libstub: Remove unused __efi_call_early() macroArd Biesheuvel
The macro __efi_call_early() is defined by various architectures but never used. Let's get rid of it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-6-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25x86/efistub: Disable paging at mixed mode entryArd Biesheuvel
The EFI mixed mode entry code goes through the ordinary startup_32() routine before jumping into the kernel's EFI boot code in 64-bit mode. The 32-bit startup code must be entered with paging disabled, but this is not documented as a requirement for the EFI handover protocol, and so we should disable paging explicitly when entering the kernel from 32-bit EFI firmware. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: <stable@vger.kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224132909.102540-4-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25x86/alternatives: Implement a better poke_int3_handler() completion schemePeter Zijlstra
Commit: 285a54efe386 ("x86/alternatives: Sync bp_patching update for avoiding NULL pointer exception") added an additional text_poke_sync() IPI to text_poke_bp_batch() to handle the rare case where another CPU is still inside an INT3 handler while we clear the global state. Instead of spraying IPIs around, count the active INT3 handlers and wait for them to go away before proceeding to clear/reuse the data. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25Merge branch 'core/kprobes' into perf/core, to pick up a completed branchIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-25Merge tag 'v5.5-rc3' into sched/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-23Merge 5.5-rc3 into tty-nextGreg Kroah-Hartman
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-23x86/crash: Define arch_crash_save_vmcoreinfo() if CONFIG_CRASH_CORE=yOmar Sandoval
On x86 kernels configured with CONFIG_PROC_KCORE=y and CONFIG_KEXEC_CORE=n, the vmcoreinfo note in /proc/kcore is incomplete. Specifically, it is missing arch-specific information like the KASLR offset and whether 5-level page tables are enabled. This breaks applications like drgn [1] and crash [2], which need this information for live debugging via /proc/kcore. This happens because: 1. CONFIG_PROC_KCORE selects CONFIG_CRASH_CORE. 2. kernel/crash_core.c (compiled if CONFIG_CRASH_CORE=y) calls arch_crash_save_vmcoreinfo() to get the arch-specific parts of vmcoreinfo. If it is not defined, then it uses a no-op fallback. 3. x86 defines arch_crash_save_vmcoreinfo() in arch/x86/kernel/machine_kexec_*.c, which is only compiled if CONFIG_KEXEC_CORE=y. Therefore, an x86 kernel with CONFIG_CRASH_CORE=y and CONFIG_KEXEC_CORE=n uses the no-op fallback and gets incomplete vmcoreinfo data. This isn't relevant to kdump, which requires CONFIG_KEXEC_CORE. It only affects applications which read vmcoreinfo at runtime, like the ones mentioned above. Fix it by moving arch_crash_save_vmcoreinfo() into two new arch/x86/kernel/crash_core_*.c files, which are gated behind CONFIG_CRASH_CORE. 1: https://github.com/osandov/drgn/blob/73dd7def1217e24cc83d8ca95c995decbd9ba24c/libdrgn/program.c#L385 2: https://github.com/crash-utility/crash/commit/60a42d709280cdf38ab06327a5b4fa9d9208ef86 Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Kairui Song <kasong@redhat.com> Cc: Lianbo Jiang <lijiang@redhat.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/0589961254102cca23e3618b96541b89f2b249e2.1576858905.git.osandov@fb.com
2019-12-23powerpc/mm: Mark get_slice_psize() & slice_addr_is_low() as notraceMichael Ellerman
These slice routines are called from the SLB miss handler, which can lead to warnings from the IRQ code, because we have not reconciled the IRQ state properly: WARNING: CPU: 72 PID: 30150 at arch/powerpc/kernel/irq.c:258 arch_local_irq_restore.part.0+0xcc/0x100 Modules linked in: CPU: 72 PID: 30150 Comm: ftracetest Not tainted 5.5.0-rc2-gcc9x-g7e0165b2f1a9 #1 NIP: c00000000001d83c LR: c00000000029ab90 CTR: c00000000026cf90 REGS: c0000007eee3b960 TRAP: 0700 Not tainted (5.5.0-rc2-gcc9x-g7e0165b2f1a9) MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 22242844 XER: 20000000 CFAR: c00000000001d780 IRQMASK: 0 ... NIP arch_local_irq_restore.part.0+0xcc/0x100 LR trace_graph_entry+0x270/0x340 Call Trace: trace_graph_entry+0x254/0x340 (unreliable) function_graph_enter+0xe4/0x1a0 prepare_ftrace_return+0xa0/0x130 ftrace_graph_caller+0x44/0x94 # (get_slice_psize()) slb_allocate_user+0x7c/0x100 do_slb_fault+0xf8/0x300 instruction_access_slb_common+0x140/0x180 Fixes: 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191221121337.4894-1-mpe@ellerman.id.au
2019-12-23arm64: dts: imx8mq-librem5-devkit: use correct interrupt for the magnetometerAngus Ainslie (Purism)
The LSM9DS1 uses a high level interrupt. Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Fixes: eb4ea0857c83 ("arm64: dts: fsl: librem5: Add a device tree for the Librem5 devkit") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: dts: imx8mq-librem5-devkit: add accelerometer and gyro sensorMartin Kepplinger
Now that there is driver support, describe the accel and gyro sensor parts of the LSM9DS1 IMU. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23ARM: dts: imx6q-dhcom: Fix SGTL5000 VDDIO regulator connectionMarek Vasut
The SGTL5000 VDDIO is connected to the PMIC SW2 output, not to a fixed 3V3 rail. Describe this correctly in the DT. Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Ludwig Zenz <lzenz@dh-electronics.com> Cc: NXP Linux Team <linux-imx@nxp.com> To: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: defconfig: Enable CRYPTO_DEV_FSL_CAAMAdam Ford
Both the i.MX8MQ and i.MX8M Mini support the CAAM driver, but it is currently not enabled by default. This patch enables this as a module. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: dts: imx8mm: Add Crypto CAAM supportAdam Ford
The i.MX8M Mini supports the same crypto engine as what is in the i.MX8MQ, but it is not currently present in the device tree. This patch places it into the device tree. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23ARM: dts: imx7ulp: fix reg of cpu nodePeng Fan
According to arm cpus binding doc, " On 32-bit ARM v7 or later systems this property is required and matches the CPU MPIDR[23:0] register bits. Bits [23:0] in the reg cell must be set to bits [23:0] in MPIDR. All other bits in the reg cell must be set to 0. " In i.MX7ULP, the MPIDR[23:0] is 0xf00, not 0, so fix it. Otherwise there will be warning: "DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map" Fixes: 20434dc92c05 ("ARM: dts: imx: add common imx7ulp dtsi support") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: dts: freescale: add initial support for Google i.MX 8MQ PhanbellMarco Antonio Franchi
This patch adds the device tree to support Google Coral Edge TPU, historicaly named as fsl-imx8mq-phanbell, a computer on module which can be used for AI/ML propose. It introduces a minimal enablement support for this module and was totally based on the NXP i.MX 8MQ EVK board and i.MX 8MQ Phanbell Google Source Code for Coral Edge TPU Mendel release: https://coral.googlesource.com/linux-imx/ Tested components: - PMIC; - USB-C OTG; - USB-C PWR; - micro-USB; - USB. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: dts: imx8mm: Change SDMA1 ahb clock for imx8mmAdam Ford
Using SDMA1 with UART1 is causing a "Timeout waiting for CH0" error. This patch changes to ahb clock from SDMA1_ROOT to AHB which fixes the timeout error. Fixes: a05ea40eb384 ("arm64: dts: imx: Add i.mx8mm dtsi support") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23ARM: imx_v6_v7_defconfig: Select the TFP410 driverFabio Estevam
Some boards like imx51-babbage, imx53-cx9020 and imx6q-utilite-pro have a TFP410 DVI bridge chip. Select its driver by default. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23ARM: dts: imx51-babbage: Fix the DVI output descriptionFabio Estevam
imx51-babbage has a TFP410 chip that receives 24-bit RGB parallel input and convert it to DVI. Fix the device tree description to reflect the real hardware. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23ARM: dts: imx6qdl-apalis: mux HDMI CEC pinStefan Agner
Mux the HDMI CEC pin to make HDMI CEC working. With this change HDMI CEC seems to work fine on a Apalis iMX6 on Ixora using cec-ctl. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-23arm64: dts: ls1028a: fix endian setting for dcfgYinbo Zhu
DCFG block uses little endian. Fix it so that register access becomes correct. Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com> Acked-by: Yangbo Lu <yangbo.lu@nxp.com> Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-24 00:33:30 +0000