aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-21objtool/x86: Ignore __x86_indirect_alt_* symbolsPeter Zijlstra1-0/+4
Because the __x86_indirect_alt* symbols are just that, objtool will try and validate them as regular symbols, instead of the alternative replacements that they are. This goes sideways for FRAME_POINTER=y builds; which generate a fair amount of warnings. Fixes: 9bc0bb50727c ("objtool/x86: Rewrite retpoline thunk calls") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-21x86/sev: Split up runtime #VC handler for correct state trackingJoerg Roedel3-90/+91
Split up the #VC handler code into a from-user and a from-kernel part. This allows clean and correct state tracking, as the #VC handler needs to enter NMI-state when raised from kernel mode and plain IRQ state when raised from user-mode. Fixes: 62441a1fb532 ("x86/sev-es: Correctly track IRQ states in runtime #VC handler") Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-06-21x86/sev: Make sure IRQs are disabled while GHCB is activeJoerg Roedel1-12/+22
The #VC handler only cares about IRQs being disabled while the GHCB is active, as it must not be interrupted by something which could cause another #VC while it holds the GHCB (NMI is the exception for which the backup GHCB exits). Make sure nothing interrupts the code path while the GHCB is active by making sure that callers of __sev_{get,put}_ghcb() have disabled interrupts upfront. [ bp: Massage commit message. ] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-06-21swiotlb: manipulate orig_addr when tlb_addr has offsetBumyong Lee1-8/+15
in case of driver wants to sync part of ranges with offset, swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with offset and ends up with data mismatch. It was removed from "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single", but said logic has to be added back in. From Linus's email: "That commit which the removed the offset calculation entirely, because the old (unsigned long)tlb_addr & (IO_TLB_SIZE - 1) was wrong, but instead of removing it, I think it should have just fixed it to be (tlb_addr - mem->start) & (IO_TLB_SIZE - 1); instead. That way the slot offset always matches the slot index calculation." (Unfortunatly that broke NVMe). The use-case that drivers are hitting is as follow: 1. Get dma_addr_t from dma_map_single() dma_addr_t tlb_addr = dma_map_single(dev, vaddr, vsize, DMA_TO_DEVICE); |<---------------vsize------------->| +-----------------------------------+ | | original buffer +-----------------------------------+ vaddr swiotlb_align_offset |<----->|<---------------vsize------------->| +-------+-----------------------------------+ | | | swiotlb buffer +-------+-----------------------------------+ tlb_addr 2. Do something 3. Sync dma_addr_t through dma_sync_single_for_device(..) dma_sync_single_for_device(dev, tlb_addr + offset, size, DMA_TO_DEVICE); Error case. Copy data to original buffer but it is from base addr (instead of base addr + offset) in original buffer: swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr |<- size ->| +-----------------------------------+ |##########| | original buffer +-----------------------------------+ vaddr The fix is to copy the data to the original buffer and take into account the offset, like so: swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr |<- offset ->|<- size ->| +-----------------------------------+ | |##########| | original buffer +-----------------------------------+ vaddr [One fix which was Linus's that made more sense to as it created a symmetry would break NVMe. The reason for that is the: unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1); would come up with the proper offset, but it would lose the alignment (which this patch contains).] Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") Signed-off-by: Bumyong Lee <[email protected]> Signed-off-by: Chanho Park <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reported-by: Dominique MARTINET <[email protected]> Reported-by: Horia Geantă <[email protected]> Tested-by: Horia Geantă <[email protected]> CC: [email protected] Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
2021-06-21MAINTAINERS: Add reviewer for regulator irq_helpersMatti Vaittinen1-0/+4
Add a reviewer entry for the regulator irq_helpers. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/2a4286ed98fd69b2539919e6a3e84d2e9804b4da.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: bd9576: Fix the driver name in id tableMatti Vaittinen1-2/+2
Driver name was changed in MFD cell: https://lore.kernel.org/lkml/560b9748094392493ebf7af11b6cc558776c4fd5.1613031055.git.matti.vaittinen@fi.rohmeurope.com/ Fix the ID table to match this. Fixes: b1b3ced38979 ("mfd: Support ROHM BD9576MUF and BD9573MUF") Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/e0483149333626b3bea298f305cf2809429d1822.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: bd9576: Support error reportingMatti Vaittinen1-124/+926
BD9573 and BD9576 support set of "protection" interrupts for "fatal" issues. Those lead to SOC reset as PMIC shuts the power outputs. Thus there is no relevant IRQ handling for them. Few "detection" interrupts were added to the BD9576 with the idea that SOC could take some recovery-action before error gets unrecoverable. Add support for over and under voltage detection for Vout1 ... Vout4 and VoutL1. Add over-current detection for VoutS1 and finally a thermal warning (common for all regulators) which alerts 30 C before temperature reaches the thermal shutdown point. This way consumer drivers can build error-recovery mechanisms. Unfortunately the BD9576 interrupt logic was not re-evaluated. IRQs are not designed to be properly acknowleged - and IRQ line is kept active for whole duration of error condition (in comparison to informing only about state change). Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/05c4f7a8e30ef1d4d5f3ceab07da4ebe68f5b4ed.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: bd9576 add FET ON-resistance for OCWMatti Vaittinen1-0/+6
BD9576MUF provides over-current protection and detection. Current is measured as voltage loss over external FET. Allow specifying FET's on resistance so current monitoring limits can be converted to voltages. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/e5feb160d7e09f33fff5b88f1928c66a15c6680f.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: add property parsing and callbacks to set protection limitsMatti Vaittinen7-9/+274
Add DT property parsing code and setting callback for regulator over/under voltage, over-current and temperature error limits. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/e7b8007ba9eae7076178bf3363fb942ccb1cc9a5.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: IRQ based event/error notification helpersMatti Vaittinen5-8/+607
Provide helper function for IC's implementing regulator notifications when an IRQ fires. The helper also works for IRQs which can not be acked. Helper can be set to disable the IRQ at handler and then re-enabling it on delayed work later. The helper also adds regulator_get_error_flags() errors in cache for the duration of IRQ disabling. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: move rdev_print helpers to internal.hMatti Vaittinen4-16/+22
The rdev print helpers are a nice way to print messages related to a specific regulator device. Move them from core.c to internal.h As the rdev print helpers use rdev_get_name() export it from core.c. Also move the declaration from coupler.h to driver.h because the rdev name is not just a coupled regulator property. I guess the main audience for rdev_get_name() will be the regulator core and drivers. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/dc7fd70dc31de4d0e820b7646bb78eeb04f80735.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: add warning flagsMatti Vaittinen1-0/+14
Add 'warning' level events and error flags to regulator core. Current regulator core notifications are used to inform consumers about errors where HW is misbehaving in such way it is assumed to be broken/unrecoverable. There are PMICs which are designed for system(s) that may have use for regulator indications sent before HW is damaged so that some board/consumer specific recovery-event can be performed while continuing most of the normal operations. Add new WARNING level events and notifications to be used for that purpose. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/9b54aa5589ae4b5945d53d114bac3fae55fa4818.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21thermal: Use generic HW-protection shutdown APIMatti Vaittinen2-74/+13
The hardware shutdown function was exported from kernel/reboot for other subsystems to use. Logic is copied from the thermal_core. The protection mutex is replaced by an atomic_t to allow calls also from an IRQ context. Also the WARN() was replaced by pr_emerg() based on discussions here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/[email protected]/ Use the exported API instead of implementing own just for the thermal_core. Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/5531e89d9e710f5d10e7cdce3ee58957335b9e03.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21reboot: Add hardware protection power-offMatti Vaittinen2-0/+80
There can be few cases when we need to shut-down the system in order to protect the hardware. Currently this is done at least by the thermal core when temperature raises over certain limit. Some PMICs can also generate interrupts for example for over-current or over-voltage, voltage drops, short-circuit, ... etc. On some systems these are a sign of hardware failure and only thing to do is try to protect the rest of the hardware by shutting down the system. Add shut-down logic which can be used by all subsystems instead of implementing the shutdown in each subsystem. The logic is stolen from thermal_core with difference of using atomic_t instead of a mutex in order to allow calls directly from IRQ context and changing the WARN() to pr_emerg() as discussed here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/[email protected]/ Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/e83ec1ca9408f90c857ea9dcdc57b14d9037b03f.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: Add protection limit propertiesMatti Vaittinen1-0/+82
Support specifying protection/error/warning limits for regulator over current, over temperature and over/under voltage. Most of the PMICs support only "protection" feature but few setups do also support error/warning level indications. On many ICs most of the protection limits can't actually be set. But for example the ampere limit for over-current protection on ROHM BD9576 can be configured - or feature can be completely disabled. Provide limit setting for all protections/errors for the sake of the completeness and do that using own properties for all so that not all users would need to set all levels when only one or few are supported. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/ae2c6056d5ed1334912d27e736d23c9151065433.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: hi6421v600: Fix setting idle modeAxel Lin1-3/+6
commit db27f8294cd7 changed eco_mode << (ffs(sreg->eco_mode_mask) - 1) to sreg->eco_mode_mask << (ffs(sreg->eco_mode_mask) - 1) which is wrong. Fix it by simply set val = sreg->eco_mode_mask. In additional, sreg->eco_mode_mask can be 0 (LDO3, LDO33, LDO34). Return -EINVAL if idle mode is not supported when sreg->eco_mode_mask is 0. While at it, also use unsigned int for reg_val/val which is the expected type for regmap_read and regmap_update_bits. Fixes: db27f8294cd7 ("staging: regulator: hi6421v600-regulator: use shorter names for OF properties") Signed-off-by: Axel Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: Add MAX8893 bindingsSergey Larin1-0/+88
Add Maxim MAX8893 PMIC device tree bindings. The example is also provided. Signed-off-by: Sergey Larin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: max8893: add regulator driverSergey Larin3-0/+191
MAX8893 is a simple regulator which can be found on some of Sasmsung phones. Signed-off-by: Sergey Larin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: hi6421: Use correct variable type for regmap api val argumentAxel Lin1-4/+4
Use unsigned int instead of u32 for regmap_read/regmap_update_bits val argument. Signed-off-by: Axel Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: qcom,rpmh-regulator: Add compatible for SA8155p-adp board pmicBhupesh Sharma1-0/+1
Add compatible string for pmm8155au pmic found on the SA8155p-adp board. Cc: Mark Brown <[email protected]> Cc: Bjorn Andersson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: qcom,rpmh-regulator: Arrange compatibles alphabeticallyBhupesh Sharma1-8/+8
Arrange the compatibles inside qcom-rpmh regulator device tree bindings alphabetically. Cc: Mark Brown <[email protected]> Cc: Bjorn Andersson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: qcom-rpmh: Add new regulator found on SA8155p adp boardBhupesh Sharma1-0/+36
SA8155p-adp board supports a new regulator - pmm8155au. The output power management circuits in this regulator include: - FTS510 smps, - HFS510 smps, and - LDO510 linear regulators Add support for the same. Cc: Mark Brown <[email protected]> Cc: Bjorn Andersson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: qcom-rpmh: Add terminator at the end of pm7325x_vreg_data[] arrayBhupesh Sharma1-0/+2
Add missing terminator(s) at the end of pm7325x_vreg_data[] array instances. Fixes: c4e5aa3dbee5 ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support") Cc: Mark Brown <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: qcom-rpmh: Cleanup terminator line commasBhupesh Sharma1-12/+12
Cleanup the qcom-rpmh regulator driver to remove comma(s) at the end of the terminator line(s). Cc: Mark Brown <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21regulator: hi655x: Fix pass wrong pointer to config.driver_dataAxel Lin1-11/+5
Current code sets config.driver_data to a zero initialized regulator which is obviously wrong. Fix it. Fixes: 4618119b9be5 ("regulator: hi655x: enable regulator for hi655x PMIC") Signed-off-by: Axel Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-06-21arm64: insn: avoid circular include dependencyMark Rutland3-5/+11
Nathan reports that when building with CONFIG_LTO_CLANG_THIN=y, the build fails due to BUILD_BUG_ON() not being defined before its uss in <asm/insn.h>. The problem is that with LTO, we patch READ_ONCE(), and <asm/rwonce.h> includes <asm/insn.h>, creating a circular include chain: <linux/build_bug.h> <linux/compiler.h> <asm/rwonce.h> <asm/alternative-macros.h> <asm/insn.h> <linux/build-bug.h> ... and so when <asm/insn.h> includes <linux/build_bug.h>, none of the BUILD_BUG* definitions have happened yet. To avoid this, let's move AARCH64_INSN_SIZE into a header without any dependencies, such that it can always be safely included. At the same time, avoid including <asm/alternative.h> in <asm/insn.h>, which should no longer be necessary (and doesn't make sense when insn.h is consumed by userspace). Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 3e00e39d9dad ("arm64: insn: move AARCH64_INSN_SIZE into <asm/insn.h>") Signed-off-by: Will Deacon <[email protected]>
2021-06-21s390/stack: fix possible register corruption with stack switch helperHeiko Carstens1-7/+11
The CALL_ON_STACK macro is used to call a C function from inline assembly, and therefore must consider the C ABI, which says that only registers 6-13, and 15 are non-volatile (restored by the called function). The inline assembly incorrectly marks all registers used to pass parameters to the called function as read-only input operands, instead of operands that are read and written to. This might result in register corruption depending on usage, compiler, and compile options. Fix this by marking all operands used to pass parameters as read/write operands. To keep the code simple even register 6, if used, is marked as read-write operand. Fixes: ff340d2472ec ("s390: add stack switch helper") Cc: <[email protected]> # 4.20 Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-06-21s390/topology: clear thread/group maps for offline cpusSven Schnelle1-3/+9
The current code doesn't clear the thread/group maps for offline CPUs. This may cause kernel crashes like the one bewlow in common code that assumes if a CPU has sibblings it is online. Unable to handle kernel pointer dereference in virtual kernel address space Call Trace: [<000000013a4b8c3c>] blk_mq_map_swqueue+0x10c/0x388 ([<000000013a4b8bcc>] blk_mq_map_swqueue+0x9c/0x388) [<000000013a4b9300>] blk_mq_init_allocated_queue+0x448/0x478 [<000000013a4b9416>] blk_mq_init_queue+0x4e/0x90 [<000003ff8019d3e6>] loop_add+0x106/0x278 [loop] [<000003ff801b8148>] loop_init+0x148/0x1000 [loop] [<0000000139de4924>] do_one_initcall+0x3c/0x1e0 [<0000000139ef449a>] do_init_module+0x6a/0x2a0 [<0000000139ef61bc>] __do_sys_finit_module+0xa4/0xc0 [<0000000139de9e6e>] do_syscall+0x7e/0xd0 [<000000013a8e0aec>] __do_syscall+0xbc/0x110 [<000000013a8ee2e8>] system_call+0x78/0xa0 Fixes: 52aeda7accb6 ("s390/topology: remove offline CPUs from CPU topology masks") Cc: <[email protected]> # 5.7+ Reported-by: Marius Hillenbrand <[email protected]> Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-06-21s390/vfio-ap: clean up mdev resources when remove callback invokedTony Krowiak1-10/+0
The mdev remove callback for the vfio_ap device driver bails out with -EBUSY if the mdev is in use by a KVM guest (i.e., the KVM pointer in the struct ap_matrix_mdev is not NULL). The intended purpose was to prevent the mdev from being removed while in use. There are two problems with this scenario: 1. Returning a non-zero return code from the remove callback does not prevent the removal of the mdev. 2. The KVM pointer in the struct ap_matrix_mdev will always be NULL because the remove callback will not get invoked until the mdev fd is closed. When the mdev fd is closed, the mdev release callback is invoked and clears the KVM pointer from the struct ap_matrix_mdev. Let's go ahead and remove the check for KVM in the remove callback and allow the cleanup of mdev resources to proceed. Signed-off-by: Tony Krowiak <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vasily Gorbik <[email protected]>
2021-06-21s390: clear pt_regs::flags on irq entrySven Schnelle1-0/+1
The current irq entry code doesn't initialize pt_regs::flags. On exit to user mode arch_do_signal_or_restart() tests whether PIF_SYSCALL is set, which might yield wrong results. Fix this by clearing pt_regs::flags in the entry.S irq handler code. Reported-by: Heiko Carstens <[email protected]> Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Fixes: 56e62a737028 ("s390: convert to generic entry") Cc: <[email protected]> # 5.12 Signed-off-by: Vasily Gorbik <[email protected]>
2021-06-21s390: fix system call restart with multiple signalsSven Schnelle1-1/+0
glibc complained with "The futex facility returned an unexpected error code.". It turned out that the futex syscall returned -ERESTARTSYS because a signal is pending. arch_do_signal_or_restart() restored the syscall parameters (nameley regs->gprs[2]) and set PIF_SYSCALL_RESTART. When another signal is made pending later in the exit loop arch_do_signal_or_restart() is called again. This function clears PIF_SYSCALL_RESTART and checks the return code which is set in regs->gprs[2]. However, regs->gprs[2] was restored in the previous run and no longer contains -ERESTARTSYS, so PIF_SYSCALL_RESTART isn't set again and the syscall is skipped. Fix this by not clearing PIF_SYSCALL_RESTART - it is already cleared in __do_syscall() when the syscall is restarted. Reported-by: Bjoern Walk <[email protected]> Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Fixes: 56e62a737028 ("s390: convert to generic entry") Cc: <[email protected]> # 5.12 Signed-off-by: Vasily Gorbik <[email protected]>
2021-06-20Linux 5.13-rc7Linus Torvalds1-2/+2
2021-06-20i2c: cp2615: check for allocation failure in cp2615_i2c_recv()Dan Carpenter1-4/+10
We need to add a check for if the kzalloc() fails. Fixes: 4a7695429ead ("i2c: cp2615: add i2c driver for Silicon Labs' CP2615 Digital Audio Bridge") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Bence Csókás <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-06-20i2c: i801: Ensure that SMBHSTSTS_INUSE_STS is cleared when leaving i801_accessHeiner Kallweit1-0/+3
As explained in [0] currently we may leave SMBHSTSTS_INUSE_STS set, thus potentially breaking ACPI/BIOS usage of the SMBUS device. Seems patch [0] needs a little bit more of review effort, therefore I'd suggest to apply a part of it as quick win. Just clearing SMBHSTSTS_INUSE_STS when leaving i801_access() should fix the referenced issue and leaves more time for discussing a more sophisticated locking handling. [0] https://www.spinics.net/lists/linux-i2c/msg51558.html Fixes: 01590f361e94 ("i2c: i801: Instantiate SPD EEPROMs automatically") Suggested-by: Hector Martin <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Hector Martin <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Tested-by: Jean Delvare <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-06-20Merge tag 'sched_urgent_for_v5.13_rc6' of ↵Linus Torvalds1-19/+25
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Borislav Petkov: "A single fix to restore fairness between control groups with equal priority" * tag 'sched_urgent_for_v5.13_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Correctly insert cfs_rq's to list on unthrottle
2021-06-20Merge tag 'irq_urgent_for_v5.13_rc6' of ↵Linus Torvalds1-1/+35
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Borislav Petkov: "A single fix for GICv3 to not take an interrupt in an NMI context" * tag 'irq_urgent_for_v5.13_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3: Workaround inconsistent PMR setting on NMI entry
2021-06-20Merge tag 'x86_urgent_for_v5.13_rc6' of ↵Linus Torvalds5-24/+56
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: "A first set of urgent fixes to the FPU/XSTATE handling mess^W code. (There's a lot more in the pipe): - Prevent corruption of the XSTATE buffer in signal handling by validating what is being copied from userspace first. - Invalidate other task's preserved FPU registers on XRSTOR failure (#PF) because latter can still modify some of them. - Restore the proper PKRU value in case userspace modified it - Reset FPU state when signal restoring fails Other: - Map EFI boot services data memory as encrypted in a SEV guest so that the guest can access it and actually boot properly - Two SGX correctness fixes: proper resources freeing and a NUMA fix" * tag 'x86_urgent_for_v5.13_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Avoid truncating memblocks for SGX memory x86/sgx: Add missing xa_destroy() when virtual EPC is destroyed x86/fpu: Reset state for all signal restore failures x86/pkru: Write hardware init value to PKRU when xstate is init x86/process: Check PF_KTHREAD and not current->mm for kernel threads x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer x86/fpu: Prevent state corruption in __fpu__restore_sig() x86/ioremap: Map EFI-reserved memory as encrypted for SEV
2021-06-19Merge tag 'powerpc-5.13-6' of ↵Linus Torvalds4-7/+7
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "Fix initrd corruption caused by our recent change to use relative jump labels. Fix a crash using perf record on systems without a hardware PMU backend. Rework our 64-bit signal handling slighty to make it more closely match the old behaviour, after the recent change to use unsafe user accessors. Thanks to Anastasia Kovaleva, Athira Rajeev, Christophe Leroy, Daniel Axtens, Greg Kurz, and Roman Bolshakov" * tag 'powerpc-5.13-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/perf: Fix crash in perf_instruction_pointer() when ppmu is not set powerpc: Fix initrd corruption with relative jump labels powerpc/signal64: Copy siginfo before changing regs->nip powerpc/mem: Add back missing header to fix 'no previous prototype' error
2021-06-19Merge tag 'perf-tools-fixes-for-v5.13-2021-06-19' of ↵Linus Torvalds6-13/+16
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix refcount usage when processing PERF_RECORD_KSYMBOL. - 'perf stat' metric group fixes. - Fix 'perf test' non-bash issue with stat bpf counters. - Update unistd, in.h and socket.h with the kernel sources, silencing perf build warnings. * tag 'perf-tools-fixes-for-v5.13-2021-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: tools headers UAPI: Sync linux/in.h copy with the kernel sources tools headers UAPI: Sync asm-generic/unistd.h with the kernel original perf beauty: Update copy of linux/socket.h with the kernel sources perf test: Fix non-bash issue with stat bpf counters perf machine: Fix refcount usage when processing PERF_RECORD_KSYMBOL perf metricgroup: Return error code from metricgroup__add_metric_sys_event_iter() perf metricgroup: Fix find_evsel_group() event selector
2021-06-19drm/atmel-hlcdc: Allow async page flipsDan Sneddon1-0/+1
The driver is capable of doing async page flips so we need to tell the core to allow them. Signed-off-by: Dan Sneddon <[email protected]> Tested-by: Ludovic Desroches <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-19drm/panel: ld9040: reference spi_device_id tableKrzysztof Kozlowski1-0/+1
Reference the spi_device_id table to silence W=1 warning: drivers/gpu/drm/panel/panel-samsung-ld9040.c:377:35: warning: ‘ld9040_ids’ defined but not used [-Wunused-const-variable=] This also would be needed for matching the driver if booted without CONFIG_OF (although it's not necessarily real case). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-19drm: atmel_hlcdc: Enable the crtc vblank prior to crtc usage.Dan Sneddon1-7/+10
'commit eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit")' removed the home-grown handling of atomic commits and exposed an issue in the crtc atomic commit handling where vblank is expected to be enabled but hasn't yet, causing kernel warnings during boot. This patch cleans up the crtc vblank handling thus removing the warning on boot. Fixes: eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit") Signed-off-by: Dan Sneddon <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-19Merge tag 'riscv-for-linus-5.13-rc7' of ↵Linus Torvalds6-12/+12
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A build fix to always build modules with the 'medany' code model, as the module loader doesn't support 'medlow'. - A Kconfig warning fix for the SiFive errata. - A pair of fixes that for regressions to the recent memory layout changes. - A fix for the FU740 device tree. * tag 'riscv-for-linus-5.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: dts: fu740: fix cache-controller interrupts riscv: Ensure BPF_JIT_REGION_START aligned with PMD size riscv: kasan: Fix MODULES_VADDR evaluation due to local variables' name riscv: sifive: fix Kconfig errata warning riscv32: Use medany C model for modules
2021-06-19Merge tag 's390-5.13-4' of ↵Linus Torvalds2-4/+11
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix zcrypt ioctl hang due to AP queue msg counter dropping below 0 when pending requests are purged. - Two fixes for the machine check handler in the entry code. * tag 's390-5.13-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/ap: Fix hanging ioctl caused by wrong msg counter s390/mcck: fix invalid KVM guest condition check s390/mcck: fix calculation of SIE critical section size
2021-06-19tools headers UAPI: Sync linux/in.h copy with the kernel sourcesArnaldo Carvalho de Melo1-0/+3
To pick the changes in: 321827477360934d ("icmp: don't send out ICMP messages with a source address of 0.0.0.0") That don't result in any change in tooling, as INADDR_ are not used to generate id->string tables used by 'perf trace'. This addresses this build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h' diff -u tools/include/uapi/linux/in.h include/uapi/linux/in.h Cc: David S. Miller <[email protected]> Cc: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2021-06-19tools headers UAPI: Sync asm-generic/unistd.h with the kernel originalArnaldo Carvalho de Melo1-2/+1
To pick the changes in: 8b1462b67f23da54 ("quota: finish disable quotactl_path syscall") Those headers are used in some arches to generate the syscall table used in 'perf trace' to translate syscall numbers into strings. This addresses this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/unistd.h' differs from latest version at 'include/uapi/asm-generic/unistd.h' diff -u tools/include/uapi/asm-generic/unistd.h include/uapi/asm-generic/unistd.h Cc: Jan Kara <[email protected]> Cc: Marcin Juszkiewicz <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2021-06-19perf beauty: Update copy of linux/socket.h with the kernel sourcesArnaldo Carvalho de Melo1-2/+0
To pick the changes in: ea6932d70e223e02 ("net: make get_net_ns return error if NET_NS is disabled") That don't result in any changes in the tables generated from that header. This silences this perf build warning: Warning: Kernel ABI header at 'tools/perf/trace/beauty/include/linux/socket.h' differs from latest version at 'include/linux/socket.h' diff -u tools/perf/trace/beauty/include/linux/socket.h include/linux/socket.h Cc: Changbin Du <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2021-06-19perf test: Fix non-bash issue with stat bpf countersIan Rogers1-2/+2
$(( .. )) is a bash feature but the test's interpreter is !/bin/sh, switch the code to use expr. Signed-off-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2021-06-19perf machine: Fix refcount usage when processing PERF_RECORD_KSYMBOLRiccardo Mancini1-1/+2
ASan reported a memory leak of BPF-related ksymbols map and dso. The leak is caused by refount never reaching 0, due to missing __put calls in the function machine__process_ksymbol_register. Once the dso is inserted in the map, dso__put() should be called (map__new2() increases the refcount to 2). The same thing applies for the map when it's inserted into maps (maps__insert() increases the refcount to 2). $ sudo ./perf record -- sleep 5 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.025 MB perf.data (8 samples) ] ================================================================= ==297735==ERROR: LeakSanitizer: detected memory leaks Direct leak of 6992 byte(s) in 19 object(s) allocated from: #0 0x4f43c7 in calloc (/home/user/linux/tools/perf/perf+0x4f43c7) #1 0x8e4e53 in map__new2 /home/user/linux/tools/perf/util/map.c:216:20 #2 0x8cf68c in machine__process_ksymbol_register /home/user/linux/tools/perf/util/machine.c:778:10 [...] Indirect leak of 8702 byte(s) in 19 object(s) allocated from: #0 0x4f43c7 in calloc (/home/user/linux/tools/perf/perf+0x4f43c7) #1 0x8728d7 in dso__new_id /home/user/linux/tools/perf/util/dso.c:1256:20 #2 0x872015 in dso__new /home/user/linux/tools/perf/util/dso.c:1295:9 #3 0x8cf623 in machine__process_ksymbol_register /home/user/linux/tools/perf/util/machine.c:774:21 [...] Indirect leak of 1520 byte(s) in 19 object(s) allocated from: #0 0x4f43c7 in calloc (/home/user/linux/tools/perf/perf+0x4f43c7) #1 0x87b3da in symbol__new /home/user/linux/tools/perf/util/symbol.c:269:23 #2 0x888954 in map__process_kallsym_symbol /home/user/linux/tools/perf/util/symbol.c:710:8 [...] Indirect leak of 1406 byte(s) in 19 object(s) allocated from: #0 0x4f43c7 in calloc (/home/user/linux/tools/perf/perf+0x4f43c7) #1 0x87b3da in symbol__new /home/user/linux/tools/perf/util/symbol.c:269:23 #2 0x8cfbd8 in machine__process_ksymbol_register /home/user/linux/tools/perf/util/machine.c:803:8 [...] Signed-off-by: Riccardo Mancini <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiapeng Chong <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tommi Rantala <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2021-06-19perf metricgroup: Return error code from ↵John Garry1-3/+5
metricgroup__add_metric_sys_event_iter() The error code is not set at all in the sys event iter function. This may lead to an uninitialized value of "ret" in metricgroup__add_metric() when no CPU metric is added. Fix by properly setting the error code. It is not necessary to init "ret" to 0 in metricgroup__add_metric(), as if we have no CPU or sys event metric matching, then "has_match" should be 0 and "ret" is set to -EINVAL. However gcc cannot detect that it may not have been set after the map_for_each_metric() loop for CPU metrics, which is strange. Fixes: be335ec28efa8 ("perf metricgroup: Support adding metrics for system PMUs") Signed-off-by: John Garry <[email protected]> Acked-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.