- 13 Jan, 2019 25 commits
-
-
Yussuf Khalil authored
[ Upstream commit ca504728 ] Before commit 7fd6d98b ("i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus"), enabling RMI on the T560 would cause the touchpad to stop working after resuming from suspend. Now that this issue is fixed, RMI can be enabled safely and works fine. Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Yussuf Khalil <dev@pp3345.net> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Tony Lindgren authored
[ Upstream commit e2ca26ec ] With PM enabled, I noticed that pressing a key on the droid4 keyboard will block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>. From the hardware point of view, looks like we need to manage the registers for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE register now gone with IRQF_ONESHOT, also the SoC idle state problem is gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent blocking deeper SoC idle states after rmmod omap4-keypad. Reported-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 9ae4f842 ] If "interface" is NULL then we can't release it and trying to will only lead to an Oops. Fixes: aea71a02 ("[SCSI] bnx2fc: Introduce interface structure for each vlan interface") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Himanshu Madhani authored
[ Upstream commit c64a87f9 ] This reverts commit db186382. This commit introduced regression with FCP discovery so revert it to fix discovery for FCP luns. Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 530aad77 ] When adjusting sack block sequence numbers, skb_make_writable() gets called to make sure tcp options are all in the linear area, and buffer is not shared. This can cause tcp header pointer to get reallocated, so we must reaload it to avoid memory corruption. This bug pre-dates git history. Reported-by:
Neel Mehta <nmehta@google.com> Reported-by:
Shane Huntley <shuntley@google.com> Reported-by:
Heather Adkins <argv@google.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Taehee Yoo authored
[ Upstream commit 4c05ec47 ] basechain->stats is rcu protected data which is updated from nft_chain_stats_replace(). This function is executed from the commit phase which holds the pernet nf_tables commit mutex - not the global nfnetlink subsystem mutex. Test commands to reproduce the problem are: %iptables-nft -I INPUT %iptables-nft -Z %iptables-nft -Z This patch uses RCU calls to handle basechain->stats updates to fix a splat that looks like: [89279.358755] ============================= [89279.363656] WARNING: suspicious RCU usage [89279.368458] 4.20.0-rc2+ #44 Tainted: G W L [89279.374661] ----------------------------- [89279.379542] net/netfilter/nf_tables_api.c:1404 suspicious rcu_dereference_protected() usage! [...] [89279.406556] 1 lock held by iptables-nft/5225: [89279.411728] #0: 00000000bf45a000 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1f/0x70 [nf_tables] [89279.424022] stack backtrace: [89279.429236] CPU: 0 PID: 5225 Comm: iptables-nft Tainted: G W L 4.20.0-rc2+ #44 [89279.430135] Call Trace: [89279.430135] dump_stack+0xc9/0x16b [89279.430135] ? show_regs_print_info+0x5/0x5 [89279.430135] ? lockdep_rcu_suspicious+0x117/0x160 [89279.430135] nft_chain_commit_update+0x4ea/0x640 [nf_tables] [89279.430135] ? sched_clock_local+0xd4/0x140 [89279.430135] ? check_flags.part.35+0x440/0x440 [89279.430135] ? __rhashtable_remove_fast.constprop.67+0xec0/0xec0 [nf_tables] [89279.430135] ? sched_clock_cpu+0x126/0x170 [89279.430135] ? find_held_lock+0x39/0x1c0 [89279.430135] ? hlock_class+0x140/0x140 [89279.430135] ? is_bpf_text_address+0x5/0xf0 [89279.430135] ? check_flags.part.35+0x440/0x440 [89279.430135] ? __lock_is_held+0xb4/0x140 [89279.430135] nf_tables_commit+0x2555/0x39c0 [nf_tables] Fixes: f102d66b ("netfilter: nf_tables: use dedicated mutex to guard transactions") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
-
Alexander Aring authored
[ Upstream commit a73d4e14 ] This patch fixes a off-by-one mistake in nla_parse_nested() functions of mac802154_hwsim driver. I had to enabled stack protector so I was able to reproduce it. Reference: https://github.com/linux-wpan/wpan-tools/issues/17Signed-off-by:
Alexander Aring <aring@mojatatu.com> Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 0152eee6 ] Since commit 222d7dbd ("net: prevent dst uses after free") skb_dst_force() might clear the dst_entry attached to the skb. The xfrm code doesn't expect this to happen, so we crash with a NULL pointer dereference in this case. Fix it by checking skb_dst(skb) for NULL after skb_dst_force() and drop the packet in case the dst_entry was cleared. We also move the skb_dst_force() to a codepath that is not used when the transformation was offloaded, because in this case we don't have a dst_entry attached to the skb. The output and forwarding path was already fixed by commit 9e143793 ("xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.") Fixes: 222d7dbd ("net: prevent dst uses after free") Reported-by:
Jean-Philippe Menil <jpmenil@gmail.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Benjamin Poirier authored
[ Upstream commit ca92e173 ] sadhcnt is reported by `ip -s xfrm state count` as "buckets count", not the hash mask. Fixes: 28d8909b ("[XFRM]: Export SAD info.") Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 533555e5 ] xfrm_output_one() does not return a error code when there is no dst_entry attached to the skb, it is still possible crash with a NULL pointer dereference in xfrm_output_resume(). Fix it by return error code -EHOSTUNREACH. Fixes: 9e143793 ("xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Qian Cai authored
[ Upstream commit f1733a1d ] There is actually a space after "sp," like this, ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]! Right now, checkstack.pl isn't able to print anything on aarch64, because it won't be able to match the stating objdump line of a function due to this missing space. Hence, it displays every stack as zero-size. After this patch, checkpatch.pl is able to match the start of a function's objdump, and is then able to calculate each function's stack correctly. Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pwSigned-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mark Zhang authored
[ Upstream commit 37fbd834 ] When support for bonding of RoCE devices was added, there was necessarily a link between the RoCE device and the paired netdevice that was part of the bond. If you remove the mlx4_en module, that paired association is broken (the RoCE device is still present but the paired netdevice has been released). We need to account for this in is_upper_ndev_bond_master_filter() and filter out those links with a broken pairing or else we later oops in netdev_next_upper_dev_rcu(). Fixes: 408f1242 ("IB/core: Delete lower netdevice default GID entries in bonding scenario") Signed-off-by:
Mark Zhang <markz@mellanox.com> Reviewed-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Andrey Grodzovsky authored
[ Upstream commit c5542060 ] If CS is submitted using guilty ctx, we terminate amdgpu_cs_parser_init before locking ctx->lock, latter in amdgpu_cs_parser_fini we still are trying to release the lock just becase parser->ctx != NULL. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Oliver O'Halloran authored
[ Upstream commit 9ef34630 ] The "altmap" is used to provide a pool of memory that is reserved for the vmemmap backing of hot-plugged memory. This is useful when adding large amount of ZONE_DEVICE memory to a system with a limited amount of normal memory. On ppc64 we use huge pages to map the vmemmap which requires the backing storage to be contigious and aligned to the hugepage size. The altmap implementation allows for the altmap provider to reserve a few PFNs at the start of the range for it's own uses and when this occurs the first chunk of the altmap is not usable for hugepage mappings. On hash there is no sane way to fall back to a normal sized page mapping so we fail the allocation. This results in memory hotplug failing with ENOMEM when the new range doesn't fall into an existing vmemmap block. This patch handles this case by falling back to using system memory rather than failing if we cannot allocate from the altmap. This fallback should only ever be used for the first vmemmap block so it should not cause excess memory consumption. Fixes: 7b73d978 ("mm: pass the vmem_altmap to vmemmap_populate") Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Peter Hutterer authored
[ Upstream commit c201e380 ] ABS_RESERVED was added in d9ca1c99 and accidentally removed as part of ffe0e7cf when the high-resolution scrolling code was removed. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by:
Martin Kepplinger <martin.kepplinger@ginzinger.com> Acked-by:
-
Yishai Hadas authored
[ Upstream commit 47f07f03 ] Blocks creating a DEVX UMEM with the non applicable access flags as of ODP, MW_BIND, etc. Specifically when an ODP flag is used below WARN call trace is issued. [ 2510.404131] RIP: 0010:__mlx5_ib_populate_pas+0x207/0x220 [mlx5_ib] ... [ 2510.404143] Call Trace: [ 2510.404150] ? __kmalloc_node+0x1b3/0x280 [ 2510.404156] ? _uverbs_alloc+0x63/0x90 [ib_uverbs] [ 2510.404158] ? _uverbs_alloc+0x63/0x90 [ib_uverbs] [ 2510.404162] mlx5_ib_populate_pas+0x53/0x60 [mlx5_ib] [ 2510.404167] mlx5_ib_handler_MLX5_IB_METHOD_DEVX_UMEM_REG+0x273/0x3f0 [mlx5_ib] Fixes: aeae9457 ("IB/mlx5: Add DEVX support for memory registration") Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Reviewed-by:
Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit f15096f1 ] According to bindings/regulator/fixed-regulator.txt the 'clocks' and 'clock-names' properties are not valid ones. In order to turn on the Wifi clock the correct location for describing the CLKO2 clock is via a mmc-pwrseq handle, so do it accordingly. Fixes: 56354959 ("ARM: dts: imx: add Boundary Devices Nitrogen7 board") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Anson Huang authored
[ Upstream commit 1e434b70 ] The sw2iso count should cover ARM LDO ramp-up time, the MAX ARM LDO ramp-up time may be up to more than 100us on some boards, this patch sets sw2iso to 0xf (~384us) which is the reset value, and it is much more safe to cover different boards, since we have observed that some customer boards failed with current setting of 0x2. Fixes: 05136f08 ("ARM: imx: support arm power off in cpuidle for i.mx6sx") Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
-
Fabio Estevam authored
[ Upstream commit c3b9ab5d ] The Wifi chip should be clocked by a 32kHz clock coming from i.MX7D CLKO2 output pin, so describe the pinmux and clock hierarchy in the device tree to allow the Wifi chip to be properly clocked. Managed to successfully test Wifi with such change. Used the standard nvram.txt file provided by TechNexion, which selects an external 32kHz clock for the Wifi chip by default. Fixes: 99a52450 ("ARM: dts: imx7d-pico: Add Wifi support") Suggested-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Tested-by:
Otavio Salvador <otavio@ossystems.com.br> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 40502074 ] The 258a:6a88 keyboard-dock shipped with the Prowise PT301 tablet is likely another ITE based design. The controller die is directly bonded to the PCB with a blob of black glue on top so there are no markings and the 258a vendor-id used is unknown anywhere. But the keyboard has the exact same hotkeys mapped to Fn+F1 - F10 as the other ITE8595 keyboard I have *and* it has the same quirky behavior wrt the rfkill hotkey. Either way as said this keyboard has the same quirk for its rfkill / airplane mode hotkey as the ITE 8595 chip, it only sends a single release event when pressed and released, it never sends a press event. This commit adds the 258a:6a88 USB id to the hid-ite id-table, fixing the rfkill key not working on this keyboard. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 462951cd ] For some configs the build fails with: arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers': arch/powerpc/mm/dump_linuxpagetables.c:306:39: error: 'PKMAP_BASE' undeclared (first use in this function) arch/powerpc/mm/dump_linuxpagetables.c:314:50: error: 'LAST_PKMAP' undeclared (first use in this function) These come from highmem.h, including that fixes the build. Signed-off-by:
-
Paul Mackerras authored
[ Upstream commit 5564597d ] Commit 6975a783 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor at the start of crt0.S to have a hard-coded start address of 0x500000 rather than a reference to _zimage_start, presumably because having a reference to a symbol introduced a relocation which is awkward to handle in a position-independent executable. Unfortunately, what is at 0x500000 in the COFF image is not the first instruction, but the procedure descriptor itself, that is, a word containing 0x500000, which is not a valid instruction. Hence, booting a COFF zImage results in a "DEFAULT CATCH!, code=FFF00700" message from Open Firmware. This fixes the problem by (a) putting the procedure descriptor in the data section and (b) adding a branch to _zimage_start as the first instruction in the program. Fixes: 6975a783 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN") Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Ryder Lee authored
[ Upstream commit 6c05946e ] No default serial console on boot. Fix this by using a 'stdout-path' property that points to the device. Fixes: c0d9f9ad ("arm64: dts: mt7622: add earlycon to mt7622-rfb1 board") Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Tested-by:
Kevin Hilman <khilman@baylibre.com> [mb: Fix commit message] Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 614b1868 ] We just changed the code so we apply bias disable on the correct register but forgot to align the register calculation. The result is that we apply the change on the correct register, but possibly at the incorrect offset/bit This went undetected because offsets tends to be the same between REG_PULL and REG_PULLEN for a given pin the EE controller. This is not true for the AO controller. Fixes: e39f9dd8 ("pinctrl: meson: fix pinconf bias disable") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Corentin Labbe authored
[ Upstream commit 5f8208f5 ] Since commit d7c5f686 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes") my BPIM3 no longer works at gigabit speed. With the default setting, dldo3 is regulated at 2.9v which seems sufficient for the PHY but the aforementioned commit drops it to 2.5V which is insufficient. Note that this behaviour is random for all BPIM3. Some work with 2.5V, but some don't. Finnaly, someone from Bananapi confirmed that this regulator must be set to 3.3V. Fixes: d7c5f686 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> [wens@csie.org: Reworked commit message] Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
- 09 Jan, 2019 15 commits
-
-
Greg Kroah-Hartman authored
-
Paul Burton authored
commit 66a4059b upstream. MIPS' asm/mmzone.h includes the machine/platform mmzone.h unconditionally, but since commit bb53fdf3 ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES. This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the loongson3 & ip27 mmzone.h headers unconditionally define the NODE_DATA preprocessor macro which is aready defined by linux/mmzone.h, resulting in the following build error: In file included from ./arch/mips/include/asm/mmzone.h:10, from ./arch/mips/include/asm/r4kcache.h:23, from arch/mips/mm/c-r4k.c:33: ./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror] #define NODE_DATA(n) (&__node_data[(n)]->pglist) In file included from ./include/linux/topology.h:32, from ./include/linux/irq.h:19, from ./include/asm-generic/hardirq.h:13, from ./arch/mips/include/asm/hardirq.h:16, from ./include/linux/hardirq.h:9, from arch/mips/mm/c-r4k.c:11: ./include/linux/mmzone.h:907: note: this is the location of the previous definition #define NODE_DATA(nid) (&contig_page_data) Resolve this by only including the machine mmzone.h when CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty mach-generic version of the header which we delete. Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: bb53fdf3 ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lukas Wunner authored
commit 29bdedfd upstream. Commit e82b0b38 ("spi: bcm2835: Fix race on DMA termination") broke the build with COMPILE_TEST=y on arches whose cmpxchg() requires 32-bit operands (xtensa, older arm ISAs). Fix by changing the dma_pending flag's type from bool to unsigned int. Fixes: e82b0b38 ("spi: bcm2835: Fix race on DMA termination") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Martin Sperl <kernel@martin.sperl.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Tomas Winkler authored
commit 2ba5780c upstream. tpm_i2c_nuvoton calculated commands duration using TPM 1.x values via tpm_calc_ordinal_duration() also for TPM 2.x chips. Call tpm2_calc_ordinal_duration() for retrieving ordinal duration for TPM 2.X chips. Cc: stable@vger.kernel.org Cc: Nayna Jain <nayna@linux.vnet.ibm.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
Nayna Jain <nayna@linux.ibm.com> Tested-by: Nayna Jain <nayna@linux.ibm.com> (For TPM 2.0) Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Tomas Winkler authored
commit 01f54664 upstream. First, rename out_no_locality to out_locality for bailing out on both tpm_cmd_ready() and tpm_request_locality() failure. Second, ignore the return value of go_to_idle() as it may override the return value of the actual tpm operation, the go_to_idle() error will be caught on any consequent command. Last, fix the wrong 'goto out', that jumped back instead of forward. Cc: stable@vger.kernel.org Fixes: 627448e8 ("tpm: separate cmd_ready/go_idle from runtime_pm") Signed-off-by:
-
Will Deacon authored
commit 169113ec upstream. The ARM Linux kernel handles the EABI syscall numbers as follows: 0 - NR_SYSCALLS-1 : Invoke syscall via syscall table NR_SYSCALLS - 0xeffff : -ENOSYS (to be allocated in future) 0xf0000 - 0xf07ff : Private syscall or -ENOSYS if not allocated > 0xf07ff : SIGILL Our compat code gets this wrong and ends up sending SIGILL in response to all syscalls greater than NR_SYSCALLS which have a value greater than 0x7ff in the bottom 16 bits. Fix this by defining the end of the ARM private syscall region and checking the syscall number against that directly. Update the comment while we're at it. Cc: <stable@vger.kernel.org> Cc: Dave Martin <Dave.Martin@arm.com> Reported-by:
Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Robin Murphy authored
commit 3cd508a8 upstream. When we insert the sync sequence number into the CMD_SYNC.MSIData field, we do so in CPU-native byte order, before writing out the whole command as explicitly little-endian dwords. Thus on big-endian systems, the SMMU will receive and write back a byteswapped version of sync_nr, which would be perfect if it were targeting a similarly-little-endian ITS, but since it's actually writing back to memory being polled by the CPUs, they're going to end up seeing the wrong thing. Since the SMMU doesn't care what the MSIData actually contains, the minimal-overhead solution is to simply add an extra byteswap initially, such that it then writes back the big-endian format directly. Cc: <stable@vger.kernel.org> Fixes: 37de98f8 ("iommu/arm-smmu-v3: Use CMD_SYNC completion MSI") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Gustavo A. R. Silva authored
commit c23b2e6f upstream. When using the nospec API, it should be taken into account that: "...if the CPU speculates past the bounds check then * array_index_nospec() will clamp the index within the range of [0, * size)." The above is part of the header for macro array_index_nospec() in linux/nospec.h Now, in this particular case, if intid evaluates to exactly VGIC_MAX_SPI or to exaclty VGIC_MAX_PRIVATE, the array_index_nospec() macro ends up returning VGIC_MAX_SPI - 1 or VGIC_MAX_PRIVATE - 1 respectively, instead of VGIC_MAX_SPI or VGIC_MAX_PRIVATE, which, based on the original logic: /* SGIs and PPIs */ if (intid <= VGIC_MAX_PRIVATE) return &vcpu->arch.vgic_cpu.private_irqs[intid]; /* SPIs */ if (intid <= VGIC_MAX_SPI) return &kvm->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS]; are valid values for intid. Fix this by calling array_index_nospec() macro with VGIC_MAX_PRIVATE + 1 and VGIC_MAX_SPI + 1 as arguments for its parameter size. Fixes: 41b87599 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> [dropped the SPI part which was fixed separately] Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Christoffer Dall authored
commit 60c3ab30 upstream. When restoring the active state from userspace, we don't know which CPU was the source for the active state, and this is not architecturally exposed in any of the register state. Set the active_source to 0 in this case. In the future, we can expand on this and exposse the information as additional information to userspace for GICv2 if anyone cares. Cc: stable@vger.kernel.org Signed-off-by:
Christoffer Dall <christoffer.dall@arm.com> Signed-off-by:
-
Marc Zyngier authored
commit bea2ef80 upstream. SPIs should be checked against the VMs specific configuration, and not the architectural maximum. Cc: stable@vger.kernel.org Signed-off-by:
-
Julien Thierry authored
commit 2e2f6c3c upstream. To change the active state of an MMIO, halt is requested for all vcpus of the affected guest before modifying the IRQ state. This is done by calling cond_resched_lock() in vgic_mmio_change_active(). However interrupts are disabled at this point and we cannot reschedule a vcpu. We actually don't need any of this, as kvm_arm_halt_guest ensures that all the other vcpus are out of the guest. Let's just drop that useless code. Signed-off-by:
Julien Thierry <julien.thierry@arm.com> Suggested-by:
-
Maciej W. Rozycki authored
commit 3cc9ffbb upstream. Add the missing adjustment of the month range on alarm reads from the RTC, correcting an issue coming from commit 9c6dfed9 ("rtc: m41t80: add alarm functionality"). The range is 1-12 for hardware and 0-11 for `struct rtc_time', and is already correctly handled on alarm writes to the RTC. It was correct up until commit 48e97667 ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality") too, which removed the previous implementation of alarm support. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Fixes: 9c6dfed9 ("rtc: m41t80: add alarm functionality") References: 48e97667 ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality") Cc: stable@vger.kernel.org # 4.7+ Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Sylwester Nawrocki authored
commit 8ac686d7 upstream. The assigned parent clocks should be normally specified in the consumer device's DT node, this ensures respective driver always sees correct clock settings when required. This patch fixes regression in audio subsystem on Odroid XU3/XU4 boards that appeared after commits: commit 647d04f8 ("ASoC: samsung: i2s: Ensure the RCLK rate is properly determined") commit 995e73e5 ("ASoC: samsung: i2s: Fix rclk_srcrate handling") commit 48279c53 ("ASoC: samsung: i2s: Prevent external abort on exynos5433 I2S1 access") Without this patch the driver gets wrong clock as the I2S function clock (op_clk) in probe() and effectively the clock which is finally assigned from DT is not being enabled/disabled in the runtime resume/suspend ops. Without the above listed commits the EXYNOS_I2S_BUS clock was always set as parent of CLK_I2S_RCLK_SRC regardless of DT settings so there was no issue with not enabled EXYNOS_SCLK_I2S. Cc: <stable@vger.kernel.org> # 4.17.x Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Marc Zyngier authored
commit 107352a2 upstream. We currently only halt the guest when a vCPU messes with the active state of an SPI. This is perfectly fine for GICv2, but isn't enough for GICv3, where all vCPUs can access the state of any other vCPU. Let's broaden the condition to include any GICv3 interrupt that has an active state (i.e. all but LPIs). Cc: stable@vger.kernel.org Reviewed-by:
-
Will Deacon authored
commit df655b75 upstream. Although bit 31 of VTCR_EL2 is RES1, we inadvertently end up setting all of the upper 32 bits to 1 as well because we define VTCR_EL2_RES1 as signed, which is sign-extended when assigning to kvm->arch.vtcr. Lucky for us, the architecture currently treats these upper bits as RES0 so, whilst we've been naughty, we haven't set fire to anything yet. Cc: <stable@vger.kernel.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by:
-
