- 10 May, 2024 9 commits
-
-
Andreas Kemnade authored
Convert subdevices with just an interrupt and compatbile to json-schema and wire up already converted subdevices. RTC is available in all variants, so allow it unconditionally. GPADC binding for TWL603X uses two different compatibles, so specify just the compatible and do not include it. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Acked-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240401081831.456828-1-andreas@kemnade.infoSigned-off-by:
Lee Jones <lee@kernel.org>
-
Andy Shevchenko authored
scnprintf() never returns negative value, drop the respective dead code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240223195113.880121-7-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Since platform_device_unregister() is NULL-aware, we don't need to duplicate this check. Remove it and fold the rest of the code. Signed-off-by:
-
Andy Shevchenko authored
Use the `PLATFORM_DEVID_NONE` constant instead of hard-coding -1 when creating a platform device. No functional changes are intended. Signed-off-by:
-
Andy Shevchenko authored
Use platform_device_register_full() instead of open coding this function. Signed-off-by:
-
Andy Shevchenko authored
Instead of creating driver-specific device attributes with sysfs_create_group() have device core do this by setting up dev_groups pointer in the driver structure. Signed-off-by:
-
Andy Shevchenko authored
There is no need to include and use entire ACPI stack in the driver. Replace respective pieces by agnostic code. No functional change indented. Signed-off-by:
-
Andy Shevchenko authored
Some devices support MSI interrupts. Let's at least try to use them in platforms that provide MSI capability. Signed-off-by:
-
Lee Jones authored
Merge branches 'ib-mfd-misc-pinctrl-regulator-6.10', 'ib-mfd-pinctrl-regulator-6.10' and 'ib-mfd-regulator-6.10' into ibs-for-mfd-merged
-
- 03 May, 2024 14 commits
-
-
Nirmala Devi Mal Nadar authored
Add support for TPS65224 pinctrl and GPIOs to TPS6594 driver as they have significant functional overlap. TPS65224 PMIC has 6 GPIOS which can be configured as GPIO or other dedicated device functions. Signed-off-by:
Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com> Signed-off-by:
Bhargav Raviprakash <bhargav.r@ltts.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/0109018f2fdce15d-c13bd809-a11b-4202-9b7f-c9380d51b070-000000@ap-south-1.amazonses.comSigned-off-by:
-
Nirmala Devi Mal Nadar authored
Add support for TPS65224 regulators (bucks and LDOs) to TPS6594 driver as they have significant functional overlap. TPS65224 PMIC has 4 buck regulators and 3 LDOs. BUCK12 can operate in dual phase. The output voltages are configurable and are meant to supply power to the main processor and other components. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/0109018f2fdcc305-3b817569-21b6-42a7-942c-8edbff3848f2-000000@ap-south-1.amazonses.comSigned-off-by:
-
Bhargav Raviprakash authored
Add support for TPS65224 PFSM in the TPS6594 PFSM driver as they share significant functionality. Signed-off-by:
Julien Panis <jpanis@baylibre.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/0109018f2fdc9dc4-db5a45c0-0148-48cc-8462-d1c5b577a4bd-000000@ap-south-1.amazonses.comSigned-off-by:
-
Bhargav Raviprakash authored
Add functionality of the TPS65224 PMIC to the TPS6594 core driver. This includes adding IRQ resource, MFD cells, and device initialization for TPS65224. Signed-off-by:
-
Bhargav Raviprakash authored
Add support for TPS65224 PMIC in TPS6594's SPI driver which has significant functional overlap. Signed-off-by:
-
Bhargav Raviprakash authored
Add support for TPS65224 PMIC in TPS6594's I2C driver which has significant functional overlap. Signed-off-by:
-
Bhargav Raviprakash authored
TPS65224 is a Power Management IC with 4 Buck regulators and 3 LDO regulators, it includes additional features like GPIOs, watchdog, ESMs (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine) managing the state of the device. In addition TPS65224 has support for 12-bit ADC and does not have RTC unlike TPS6594. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/0109018f2f26a14f-157bb3a2-2f9b-4653-a619-46e1feb8f229-000000@ap-south-1.amazonses.comSigned-off-by:
-
Bhargav Raviprakash authored
In regmap_config use volatile_table instead of volatile_reg. This change makes it easier to add support for TPS65224 PMIC. Signed-off-by:
-
Nirmala Devi Mal Nadar authored
Extend TPS6594 PMIC register and field definitions to support TPS65224 power management IC. TPS65224 is software compatible to TPS6594 and can re-use many of the same definitions, new definitions are added to support additional controls available on TPS65224. Signed-off-by:
-
Alex Bee authored
Add support for rk816 to the existing rk808 regulator driver. The infrastructure of the driver can be re-used as is. A peculiarity for this version is, that BUCK1/BUCK2 have a (common) bit which needs to toggled after a voltage change to confirm the change. Regulator regmap takes care of that by defining a apply_bit and apply_reg for those regulators. Signed-off-by:
Alex Bee <knaerzche@gmail.com> Reviewed-by:
-
Alex Bee authored
rk808_set_suspend_voltage_range currently does not account the existence of apply_bit/apply_reg. This adds support for those in same way it is done in regulator_set_voltage_sel_regmap and is required for the upcoming RK816 support Signed-off-by:
-
Alex Bee authored
This adds support for RK816 to the exising rk805 pinctrl driver It has a single pin which can be configured as input from a thermistor (for instance in an attached battery) or as a gpio. Signed-off-by:
-
Alex Bee authored
This integrates RK816 support in the this existing rk8xx mfd driver. This version has unaligned interrupt registers, which requires to define a separate get_irq_reg callback for the regmap. Apart from that the integration is straightforward and the existing structures can be used as is. The initialization sequence has been taken from vendor kernel. Signed-off-by:
-
Alex Bee authored
Add DT binding document for Rockchip's RK816 PMIC Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240416161237.2500037-2-knaerzche@gmail.comSigned-off-by:
-
- 28 Mar, 2024 4 commits
-
-
Andre Przywara authored
The X-Powers AXP717 is a typical PMIC from X-Powers, featuring four DC/DC converters and 15 LDOs, on the regulator side. Describe the chip's voltage settings and switch registers, how the voltages are encoded, and connect this to the MFD device via its regulator ID. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Ryan Walklin <ryan@testtoast.com> Link: https://lore.kernel.org/r/20240310010211.28653-5-andre.przywara@arm.comSigned-off-by:
-
Andre Przywara authored
The AXP717a is a PMIC chip produced by X-Powers, it can be connected to an I2C or RSB bus. It's a rather complete PMIC, with many regulators, interrupts, an ADC and battery charging functionality. It also offer USB type-C CC pin handling. Describe the regmap and the MFD bits, along with the registers exposed via I2C or RSB. This covers the regulator, interrupts and power key devices for now. Advertise the device using the new compatible string. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Tested-by:
-
Andre Przywara authored
The X-Powers AXP717 is a PMIC used on some newer Allwinner devices. Among quite some regulators it features the usual ADC/IRQ/power key parts, plus a battery charger circuit, and some newly introduced USB type-C circuitry. Like two other recent PMICs, it lacks the DC/DC converter PWM frequency control register, that rate is fixed here as well. Add the new compatible string, and add that to the list of PMICs without the PWM frequency property. Signed-off-by:
-
Andre Przywara authored
The registers to set the X-Powers AXP313 regulators are of course "CONTROL" registers, not "CONRTOL" ones. Fix the typo in the header file and in its users. No functional change. Signed-off-by:
-
- 24 Mar, 2024 13 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds authored
Pull EFI fixes from Ard Biesheuvel: - Fix logic that is supposed to prevent placement of the kernel image below LOAD_PHYSICAL_ADDR - Use the firmware stack in the EFI stub when running in mixed mode - Clear BSS only once when using mixed mode - Check efi.get_variable() function pointer for NULL before trying to call it * tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: fix panic in kdump kernel x86/efistub: Don't clear BSS twice in mixed mode x86/efistub: Call mixed mode boot services on the firmware's stack efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: - Ensure that the encryption mask at boot is properly propagated on 5-level page tables, otherwise the PGD entry is incorrectly set to non-encrypted, which causes system crashes during boot. - Undo the deferred 5-level page table setup as it cannot work with memory encryption enabled. - Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset to the default value but the cached variable is not, so subsequent comparisons might yield the wrong result and as a consequence the result prevents updating the MSR. - Register the local APIC address only once in the MPPARSE enumeration to prevent triggering the related WARN_ONs() in the APIC and topology code. - Handle the case where no APIC is found gracefully by registering a fake APIC in the topology code. That makes all related topology functions work correctly and does not affect the actual APIC driver code at all. - Don't evaluate logical IDs during early boot as the local APIC IDs are not yet enumerated and the invoked function returns an error code. Nothing requires the logical IDs before the final CPUID enumeration takes place, which happens after the enumeration. - Cure the fallout of the per CPU rework on UP which misplaced the copying of boot_cpu_data to per CPU data so that the final update to boot_cpu_data got lost which caused inconsistent state and boot crashes. - Use copy_from_kernel_nofault() in the kprobes setup as there is no guarantee that the address can be safely accessed. - Reorder struct members in struct saved_context to work around another kmemleak false positive - Remove the buggy code which tries to update the E820 kexec table for setup_data as that is never passed to the kexec kernel. - Update the resource control documentation to use the proper units. - Fix a Kconfig warning observed with tinyconfig * tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot/64: Move 5-level paging global variable assignments back x86/boot/64: Apply encryption mask to 5-level pagetable update x86/cpu: Add model number for another Intel Arrow Lake mobile processor x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Documentation/x86: Document that resctrl bandwidth control units are MiB x86/mpparse: Register APIC address only once x86/topology: Handle the !APIC case gracefully x86/topology: Don't evaluate logical IDs during early boot x86/cpu: Ensure that CPU info updates are propagated on UP kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address x86/pm: Work around false positive kmemleak report in msr_build_context() x86/kexec: Do not update E820 kexec table for setup_data x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler doc clarification from Thomas Gleixner: "A single update for the documentation of the base_slice_ns tunable to clarify that any value which is less than the tick slice has no effect because the scheduler tick is not guaranteed to happen within the set time slice" * tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation
-
git://git.infradead.org/users/hch/dma-mappingLinus Torvalds authored
Pull dma-mapping fixes from Christoph Hellwig: "This has a set of swiotlb alignment fixes for sometimes very long standing bugs from Will. We've been discussion them for a while and they should be solid now" * tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping: swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE iommu/dma: Force swiotlb_max_mapping_size on an untrusted device swiotlb: Fix alignment checks when both allocation and DMA masks are present swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc() swiotlb: Enforce page alignment in swiotlb_alloc() swiotlb: Fix double-allocation of slots due to broken alignment handling
-
Oleksandr Tymoshenko authored
Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. Fixes: bad267f9 ("efi: verify that variable services are supported") Signed-off-by:
Oleksandr Tymoshenko <ovt@google.com> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org>
-
Ard Biesheuvel authored
Clearing BSS should only be done once, at the very beginning. efi_pe_entry() is the entrypoint from the firmware, which may not clear BSS and so it is done explicitly. However, efi_pe_entry() is also used as an entrypoint by the mixed mode startup code, in which case BSS will already have been cleared, and doing it again at this point will corrupt global variables holding the firmware's GDT/IDT and segment selectors. So make the memset() conditional on whether the EFI stub is running in native mode. Fixes: b3810c5a ("x86/efistub: Clear decompressor BSS in native EFI entrypoint") Signed-off-by:
-
Ard Biesheuvel authored
Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Cc: <stable@kernel.org> # v6.1+ Signed-off-by: -
Tom Lendacky authored
Commit 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables") moved assignment of 5-level global variables to later in the boot in order to avoid having to use RIP relative addressing in order to set them. However, when running with 5-level paging and SME active (mem_encrypt=on), the variables are needed as part of the page table setup needed to encrypt the kernel (using pgd_none(), p4d_offset(), etc.). Since the variables haven't been set, the page table manipulation is done as if 4-level paging is active, causing the system to crash on boot. While only a subset of the assignments that were moved need to be set early, move all of the assignments back into check_la57_support() so that these assignments aren't spread between two locations. Instead of just reverting the fix, this uses the new RIP_REL_REF() macro when assigning the variables. Fixes: 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables") Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Reviewed-by:
-
Tom Lendacky authored
When running with 5-level page tables, the kernel mapping PGD entry is updated to point to the P4D table. The assignment uses _PAGE_TABLE_NOENC, which, when SME is active (mem_encrypt=on), results in a page table entry without the encryption mask set, causing the system to crash on boot. Change the assignment to use _PAGE_TABLE instead of _PAGE_TABLE_NOENC so that the encryption mask is set for the PGD entry. Fixes: 533568e0 ("x86/boot/64: Use RIP_REL_REF() to access early_top_pgt[]") Signed-off-by:
-
Tony Luck authored
This one is the regular laptop CPU. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Adamos Ttofari authored
Commit 67236547 ("x86/fpu: Update XFD state where required") and commit 8bf26758 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD. Fixes: 67236547 ("x86/fpu: Update XFD state where required") Signed-off-by:
Adamos Ttofari <attofari@amazon.de> Signed-off-by:
Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240322230439.456571-1-chang.seok.bae@intel.com Closes: https://lore.kernel.org/lkml/20230511152818.13839-1-attofari@amazon.de
-
Tony Luck authored
The memory bandwidth software controller uses 2^20 units rather than 10^6. See mbm_bw_count() which computes bandwidth using the "SZ_1M" Linux define for 0x00100000. Update the documentation to use MiB when describing this feature. It's too late to fix the mount option "mba_MBps" as that is now an established user interface. Signed-off-by:
-
