- 14 Feb, 2020 40 commits
-
-
Shubhrajyoti Datta authored
commit 10747568 upstream. Currently we are doing a read of the status register. Move the spinlock after that as the reads need not be spinlock protected. This patch prevents relaxing the cpu with spinlock held. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Cc: Pavel Machek <pavel@denx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Zijlstra authored
commit ea1ed38d upstream. When CONFIG_FRAME_POINTER, we should mark pt_regs frames. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Josh Poimboeuf <jpoimboe@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> [4.19 backport; added user-visible changelog] Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
-
Peter Zijlstra authored
commit a9b3c699 upstream. In preparation for wider use, move the ENCODE_FRAME_POINTER macros to a common header and provide inline asm versions. These macros are used to encode a pt_regs frame for the unwinder; see unwind_frame.c:decode_frame_pointer(). Signed-off-by:
-
Anand Lodnoor authored
commit 6d753727 upstream. Driver initiates OCR if a DCMD command times out. But there is a deadlock if the driver attempts to invoke another OCR before the mutex lock (reset_mutex) is released from the previous session of OCR. This patch takes care of the above scenario using new flag MEGASAS_FUSION_OCR_NOT_POSSIBLE to indicate if OCR is possible. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1579000882-20246-9-git-send-email-anand.lodnoor@broadcom.comSigned-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
Anand Lodnoor <anand.lodnoor@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Nicolai Stange authored
[ Upstream commit 1754c4f6 ] Commit e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing() and made it to return on overflow. However, the aforementioned commit doesn't set the return value accordingly and thus, lbs_ibss_join_existing() would return with zero even though it failed. Make lbs_ibss_join_existing return -EINVAL in case the bounds check on the number of supplied rates fails. Fixes: e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by:
Nicolai Stange <nstange@suse.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nicolai Stange authored
[ Upstream commit c7bf1fb7 ] Commit e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing(). Unfortunately, it introduced a return path from within a RCU read side critical section without a corresponding rcu_read_unlock(). Fix this. Fixes: e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by:
-
Qing Xu authored
[ Upstream commit b70261a2 ] mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by:
Qing Xu <m1s5p6688@gmail.com> Signed-off-by:
-
Qing Xu authored
[ Upstream commit 3a9b153c ] mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by:
-
Geert Uytterhoeven authored
commit 805f6357 upstream. The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means one set of users must be wrong. Replace them by the correct enum IDs. Fixes: 87f8c988 ("sh-pfc: Add r8a7778 pinmux support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.beSigned-off-by:
-
Gustavo A. R. Silva authored
commit 0d962e06 upstream. Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a ("media: i2c: adv748x: add adv748x driver") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Eric Biggers authored
commit b529f198 upstream. HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated any error as a "bad key length" error. Fix it to correctly propagate the -ENOMEM error code and not set any tfm result flags. Fixes: 81d8750b ("crypto: atmel-sha - add support to hmac(shaX)") Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Eric Biggers authored
commit b828f905 upstream. ->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1. Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
-
YueHaibing authored
commit f33113b5 upstream. The unsigned variable log_num is being assigned a return value from the call to sharpsl_nand_get_logical_num that can return -EINVAL. Detected using Coccinelle: ./drivers/mtd/parsers/sharpslpart.c:207:6-13: WARNING: Unsigned expression compared with zero: log_num > 0 Fixes: 8a4580e4 ("mtd: sharpslpart: Add sharpslpart partition parser") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Nathan Chancellor authored
commit 0e7ca83e upstream. Clang warns: ../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] while (!ret) { ^ ../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous statement is here if (column + thislen > writesize) ^ 1 warning generated. This warning occurs because there is a space before the tab of the while loop. There are spaces at the beginning of a lot of the lines in this block, remove them so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: a8de85d5 ("[MTD] OneNAND: Implement read-while-load") Link: https://github.com/ClangBuiltLinux/linux/issues/794Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Eric Auger authored
commit 3837407c upstream. The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1 if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc70 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Andrew Murray <andrew.murray@arm.com> Acked-by:
-
James Morse authored
commit 21aecdbd upstream. KVM's inject_abt64() injects an external-abort into an aarch64 guest. The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but for an aarch32 guest inject_abt32() injects an implementation-defined exception, 'Lockdown fault'. Change this to external abort. For non-LPAE we now get the documented: | Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00 and for LPAE: | Unhandled fault: synchronous external abort (0x210) at 0x9c800f00 Fixes: 74a64a98 ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by:
Beata Michalska <beata.michalska@linaro.org> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
-
James Morse authored
commit 018f22f9 upstream. Beata reports that KVM_SET_VCPU_EVENTS doesn't inject the expected exception to a non-LPAE aarch32 guest. The host intends to inject DFSR.FS=0x14 "IMPLEMENTATION DEFINED fault (Lockdown fault)", but the guest receives DFSR.FS=0x04 "Fault on instruction cache maintenance". This fault is hooked by do_translation_fault() since ARMv6, which goes on to silently 'handle' the exception, and restart the faulting instruction. It turns out, when TTBCR.EAE is clear DFSR is split, and FS[4] has to shuffle up to DFSR[10]. As KVM only does this in one place, fix up the static values. We now get the expected: | Unhandled fault: lock abort (0x404) at 0x9c800f00 Fixes: 74a64a98 ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by:
-
Gavin Shan authored
commit cf2d23e0 upstream. kvm_test_age_hva() is called upon mmu_notifier_test_young(), but wrong address range has been passed to handle_hva_to_gpa(). With the wrong address range, no young bits will be checked in handle_hva_to_gpa(). It means zero is always returned from mmu_notifier_test_young(). This fixes the issue by passing correct address range to the underly function handle_hva_to_gpa(), so that the hardware young (access) bit will be visited. Fixes: 35307b9a ("arm/arm64: KVM: Implement Stage-2 page aging") Signed-off-by:
Gavin Shan <gshan@redhat.com> Signed-off-by:
-
Suzuki K Poulose authored
commit c9d66999 upstream. When fp/simd is not supported on the system, fail the operations of FP/SIMD regsets. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Suzuki K Poulose authored
commit 449443c0 upstream. The NO_FPSIMD capability is defined with scope SYSTEM, which implies that the "absence" of FP/SIMD on at least one CPU is detected only after all the SMP CPUs are brought up. However, we use the status of this capability for every context switch. So, let us change the scope to LOCAL_CPU to allow the detection of this capability as and when the first CPU without FP is brought up. Also, the current type allows hotplugged CPU to be brought up without FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace up. Fix both of these issues by changing the capability to BOOT_RESTRICTED_LOCAL_CPU_FEATURE. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
-
Olof Johansson authored
commit 31f3010e upstream. As of commit ac7c3e4f ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly"), free_memmap() might not always be inlined, and thus is triggering a section warning: WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free() Mark it as __init, since the faller (free_unused_memmap) already is. Fixes: ac7c3e4f ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly") Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Eric Auger authored
commit 8c58be34 upstream. Saving/restoring an unmapped collection is a valid scenario. For example this happens if a MAPTI command was sent, featuring an unmapped collection. At the moment the CTE fails to be restored. Only compare against the number of online vcpus if the rdist base is set. Fixes: ea1ad53e ("KVM: arm64: vgic-its: Collection table save/restore") Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191213094237.19627-1-eric.auger@redhat.comSigned-off-by:
-
Shameer Kolothum authored
commit 935d43ba upstream. CMDQ_OP_TLBI_NH_VA requires VMID and this was missing since commit 1c27df1c ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA"). Add it back. Fixes: 1c27df1c ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA") Signed-off-by:
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by:
-
Alexey Kardashevskiy authored
commit 7559d3d2 upstream. By default a pseries guest supports a H_PUT_TCE hypercall which maps a single IOMMU page in a DMA window. Additionally the hypervisor may support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once; this is advertised via the device tree /rtas/ibm,hypertas-functions property which Linux converts to FW_FEATURE_MULTITCE. FW_FEATURE_MULTITCE is checked when dma_iommu_ops is used; however the code managing the huge DMA window (DDW) ignores it and calls H_PUT_TCE_INDIRECT even if it is explicitly disabled via the "multitce=off" kernel command line parameter. This adds FW_FEATURE_MULTITCE checking to the DDW code path. This changes tce_build_pSeriesLP to take liobn and page size as the huge window does not have iommu_table descriptor which usually the place to store these numbers. Fixes: 4e8b0cf4 ("powerpc/pseries: Add support for dynamic dma windows") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by:
Thiago Jung Bauermann <bauerman@linux.ibm.com> Tested-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191216041924.42318-3-aik@ozlabs.ruSigned-off-by:
-
Tyrel Datwyler authored
commit aff8c824 upstream. Commit e5afdf9d ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table") missed an iommu_table allocation in the pseries vio code. The iommu_table is allocated with kzalloc and as a result the associated kref gets a value of zero. This has the side effect that during a DLPAR remove of the associated virtual IOA the iommu_tce_table_put() triggers a use-after-free underflow warning. Call Trace: [c0000002879e39f0] [c00000000071ecb4] refcount_warn_saturate+0x184/0x190 (unreliable) [c0000002879e3a50] [c0000000000500ac] iommu_tce_table_put+0x9c/0xb0 [c0000002879e3a70] [c0000000000f54e4] vio_dev_release+0x34/0x70 [c0000002879e3aa0] [c00000000087cfa4] device_release+0x54/0xf0 [c0000002879e3b10] [c000000000d64c84] kobject_cleanup+0xa4/0x240 [c0000002879e3b90] [c00000000087d358] put_device+0x28/0x40 [c0000002879e3bb0] [c0000000007a328c] dlpar_remove_slot+0x15c/0x250 [c0000002879e3c50] [c0000000007a348c] remove_slot_store+0xac/0xf0 [c0000002879e3cd0] [c000000000d64220] kobj_attr_store+0x30/0x60 [c0000002879e3cf0] [c0000000004ff13c] sysfs_kf_write+0x6c/0xa0 [c0000002879e3d10] [c0000000004fde4c] kernfs_fop_write+0x18c/0x260 [c0000002879e3d60] [c000000000410f3c] __vfs_write+0x3c/0x70 [c0000002879e3d80] [c000000000415408] vfs_write+0xc8/0x250 [c0000002879e3dd0] [c0000000004157dc] ksys_write+0x7c/0x120 [c0000002879e3e20] [c00000000000b278] system_call+0x5c/0x68 Further, since the refcount was always zero the iommu_tce_table_put() fails to call the iommu_table release function resulting in a leak. Fix this issue be initilizing the iommu_table kref immediately after allocation. Fixes: e5afdf9d ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table") Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Reviewed-by:
-
Zhengyuan Liu authored
commit 1985f8c7 upstream. If we compile tools/acpi target in the top source directory, we'd get a compilation error showing as bellow: # make tools/acpi DESCEND power/acpi DESCEND tools/acpidbg CC tools/acpidbg/acpidbg.o Assembler messages: Fatal error: can't create /home/lzy/kernel-upstream/power/acpi/\ tools/acpidbg/acpidbg.o: No such file or directory ../../Makefile.rules:26: recipe for target '/home/lzy/kernel-upstream/\ power/acpi/tools/acpidbg/acpidbg.o' failed make[3]: *** [/home/lzy/kernel-upstream//power/acpi/tools/acpidbg/\ acpidbg.o] Error 1 Makefile:19: recipe for target 'acpidbg' failed make[2]: *** [acpidbg] Error 2 Makefile:54: recipe for target 'acpi' failed make[1]: *** [acpi] Error 2 Makefile:1607: recipe for target 'tools/acpi' failed make: *** [tools/acpi] Error 2 Fixes: d5a4b1a5 ("tools/power/acpi: Remove direct kernel source include reference") Signed-off-by:
Zhengyuan Liu <liuzhengyuan@kylinos.cn> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Alexandre Belloni authored
commit a7e0f3fc upstream. The clock rate range for the TCB1 clock is missing. define it in the device tree. Reported-by:
Karl Rudbæk Olsen <karl@micro-technic.com> Fixes: d2e8190b ("ARM: at91/dt: define sama5d3 clocks") Link: https://lore.kernel.org/r/20200110172007.1253659-2-alexandre.belloni@bootlin.comSigned-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Alexandre Belloni authored
commit ee0aa926 upstream. Currently the maximum rate for peripheral clock is calculated based on a typical 133MHz MCK. The maximum frequency is defined in the datasheet as a ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the device trees to match the maximum rate based on 166MHz. Reported-by:
-
Tero Kristo authored
commit 01053dad upstream. clkout1 clock node and its generation tree was missing. Add this based on the data on TRM and PRCM functional spec. commit 664ae1ab ("ARM: dts: am43xx: add clkctrl nodes") effectively reverted this commit 8010f13a ("ARM: dts: am43xx: add support for clkout1 clock") which is needed for the ov2659 camera sensor clock definition hence it is being re-applied here. Note that because of the current dts node name dependency for mapping to clock domain, we must still use "clkout1-*ck" naming instead of generic "clock@" naming for the node. And because of this, it's probably best to apply the dts node addition together along with the other clock changes. Fixes: 664ae1ab ("ARM: dts: am43xx: add clkctrl nodes") Signed-off-by:
Tero Kristo <t-kristo@ti.com> Tested-by:
Benoit Parrot <bparrot@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Ingo van Lil authored
commit 9d39d86c upstream. Pull-ups for SAM9 UART/USART TX lines were disabled in a previous commit. However, several chips in the SAM9 family require pull-ups to prevent the TX lines from falling (and causing an endless break condition) when the transceiver is disabled. From the SAM9G20 datasheet, 32.5.1: "To prevent the TXD line from falling when the USART is disabled, the use of an internal pull up is mandatory.". This commit reenables the pull-ups for all chips having that sentence in their datasheets. Fixes: 5e04822f ("ARM: dts: at91: fixes uart pinctrl, set pullup on rx, clear pullup on tx") Signed-off-by:
Ingo van Lil <inguin@gmx.de> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20191203142147.875227-1-inguin@gmx.deSigned-off-by:
-
Mika Westerberg authored
commit 5e0c94d3 upstream. The driver gets driver_data from memory that is marked as const (which is probably put to read-only memory) and it then modifies it. This likely causes some sort of fault to happen. Fix this by taking a copy of the structure. Fixes: c94a8ff1 ("platform/x86: intel_mid_powerbtn: make mid_pb_ddata const") Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Jose Abreu authored
commit 7980dff3 upstream. Add a missing property to GMAC node so that multicast filtering works correctly. Fixes: 556cc1c5 ("ARC: [axs101] Add support for AXS101 SDP (software development platform)") Acked-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Andy Shevchenko authored
commit b6da197a upstream. As reported by Guilherme G. Piccoli: ---8<---8<---8<--- The rtc-cmos interrupt setting was changed in the commit 079062b2 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order to allow shared interrupts; according to that commit's description, some machine got kernel warnings due to the interrupt line being shared between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing that time. After the aforementioned commit though it was observed a huge increase in lost HPET interrupts in some systems, observed through the following kernel message: [...] hpet1: lost 35 rtc interrupts After investigation, it was narrowed down to the shared interrupts usage when having the kernel option "irqpoll" enabled. In this case, all IRQ handlers are called for non-timer interrupts, if such handlers are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to hpet_rtc_interrupt(), which will produce the kernel "lost interrupts" message after doing work - lots of readl/writel to HPET registers, which are known to be slow. Although "irqpoll" is not a default kernel option, it's used in some contexts, one being the kdump kernel (which is an already "impaired" kernel usually running with 1 CPU available), so the performance burden could be considerable. Also, the same issue would happen (in a shorter extent though) when using "irqfixup" kernel option. In a quick experiment, a virtual machine with uptime of 2 minutes produced >300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without sharing interrupts this number reduced to 1 interrupt. Machines with more hardware than a VM should generate even more unnecessary HPET interrupts in this scenario. ---8<---8<---8<--- After looking into the rtc-cmos driver history and DSDT table from the Microsoft Surface 3, we may notice that Hans de Goede submitted a correct fix (see dependency below). Thus, we simply revert the culprit commit. Fixes: 079062b2 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch") Depends-on: a1e23a42 ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs") Reported-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200123131437.28157-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Paul Kocialkowski authored
commit f236a2a2 upstream. The current code returns -EPERM when the voltage loss bit is set. Since the bit indicates that the time value is not valid, return -EINVAL instead, which is the appropriate error code for this situation. Fixes: dcaf0384 ("rtc: add hym8563 rtc-driver") Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://lore.kernel.org/r/20191212153111.966923-1-paul.kocialkowski@bootlin.comSigned-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit aea3877e ] On r8a7791/koelsch: m25p80 spi0.0: error -22 reading 9f m25p80: probe of spi0.0 failed with error -22 Apparently the logic in spi_mem_check_op() is wrong, rejecting the spi-mem operation if any buswidth is valid, instead of invalid. Fixes: 38058322 ("spi: spi-mem: Add extra sanity checks on the op param") Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Boris Brezillon authored
commit 38058322 upstream Some combinations are simply not valid and should be rejected before the op is passed to the SPI controller driver. Add an spi_mem_check_op() helper and use it in spi_mem_exec_op() and spi_mem_supports_op() to make sure the spi-mem operation is valid. Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Brandon Maier authored
commit 6169005c upstream The Zynq's gpios can be configured by the bootloader. But Linux will erroneously report all gpios as inputs unless we implement get_direction(). Signed-off-by:
Brandon Maier <Brandon.Maier@collins.com> Tested-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: stable <stable@vger.kernel.org> # 4.19 Signed-off-by:
-
Shubhrajyoti Datta authored
commit 277375b8 upstream In case the cable is not connected then the target gets into an infinite wait for tx empty. Add a timeout to the tx empty wait. Reported-by:
Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by:
-
Robert Milkowski authored
commit 924491f2 upstream. Currently, if an nfs server returns NFS4ERR_EXPIRED to open(), we return EIO to applications without even trying to recover. Fixes: 272289a3 ("NFSv4: nfs4_do_handle_exception() handle revoke/expiry of a single stateid") Signed-off-by:
Robert Milkowski <rmilkowski@gmail.com> Reviewed-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 221203ce upstream. Instead of making assumptions about the commit verifier contents, change the commit code to ensure we always check that the verifier was set by the XDR code. Fixes: f54bcf2e ("pnfs: Prepare for flexfiles by pulling out common code") Signed-off-by:
-
