summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2020-03-10ARM: dts: colibri_imx6: fix analogue camera adapter detectionMarcel Ziswiler
Out-of-the-box the analogue camera adapter fails detecting with the following error: [ 6.503046] adv7280 2-0021: adv7280_probe:Analog Device adv7280 not detected -6! Unfortunately, the camera seems to be held in reset due to the BL_ON pin not being serviced. Fix this by hogging the camera_nreset aka BL_ON pin to output high. Related-to: ELB-2580 Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2020-03-09ARM64: boot: dts: verdin-imx8mm: Remove unsupported rgmii dly from fecPhilippe Schenker
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-03-09ARM64: boot: dts: apalis-imx8qm: Correct comment from 3.3V to 1.8VPhilippe Schenker
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-03-04ARM64: dts: verdin-imx8mm: Add rxc txc dll 2ns delayPhilippe Schenker
This patch enables both RXC and TXC 2ns dll delay lines on the KSZ9131 PHY. Both are neede because the i.MX8MM SoC is RGMII v1.3 compliant. This means we need the TXC delay of the PHY. Related-to: ELB-1299 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-03-04ARM64: dts: apalis-imx8qm-v1.1: Remove RXC delay in MACPhilippe Schenker
The RXC delay is provided in both PHYs used (KSZ9031 and KSZ9131) on the PHY itself so it is not needed on the MAC. Related-to: ELB-1299 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-03-04ARM: mach-imx6q: add ksz9131rn_phy_fixupPhilippe Schenker
The MAC of the i.MX6 SoC is compliant with RGMII v1.3. The KSZ9131 PHY is like KSZ9031 adhering to RGMII v2.0 specification. This means the MAC should provide a delay to the TXC line. Because the i.MX6 MAC does not provide this delay this has to be done in the PHY. This patch adds by default ~1.4ns delay to the TXC line. This should be good for all boards that have all RGMII signals routed with the same length. The KSZ9131 has relatively high tolerances on skew registers from MMD 2.4 to MMD 2.8. Therefore the new DLL-based delay of 2ns is used and then as little as possibly subtracted from that so we get more accurate delay. This is actually needed because the i.MX6 SoC has an asyn skew on TXC from -100ps to 900ps. Related-to: ELB-1299 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-24ARM64: dts: verdin-imx8mm: add ctrl_sleep_mociMarcel Ziswiler
Add CTRL_SLEEP_MOCI required for e.g. the Dahlia carrier board. Related-to: ELB-2520 Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2020-02-17ARM64: dts: verdin-imx8mm: Add off-on-delay to usdhc2Philippe Schenker
The hardware of verdin has some bypass caps after the switch that switches power to the sd-card. These caps are resulting in a slow discharge. Add off-on-delay to set a minimum off-time of the regulator so it can fully discharge until it turns on again. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-17ARM: dts: imx7-colibri: Fix frequency for eMMCOleksandr Suvorov
eMMC, used in Colibri iMX7D eMMC modules, supports 200Mhz mode with vccq=1.8v. Remove the max-frequency limit, it increases the performance significantly: == before fix ==== root@colibri-imx7-emmc:~# hdparm -t /dev/mmcblk1 /dev/mmcblk1: Timing buffered disk reads: `^H252 MB in 3.02 seconds = 83.54 MB/sec ================== === after fix ==== root@colibri-imx7-emmc:~# hdparm -t /dev/mmcblk0 /dev/mmcblk0: Timing buffered disk reads: 408 MB in 3.00 seconds = 135.94 MB/sec ================== Related-to: ELB-1442 Fixes: f928a4a377e4 ("ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support") Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-02-12ARM64: dts: apalis-imx8qm: V1.0 devicetree inherit from V1.1 dtsPhilippe Schenker
This commit basically deletes the devicetree for V1.0 Apalis iMX8 modules. It includes V1.1 devicetree then and only puts in the differences and deletes the nodes that are not used in V1.0. This is done to prevent code duplication and have better overview of what has changed. Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-12ARM64: dts: apalis-imx8qm: add new v1.1-eval.dtsPhilippe Schenker
Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-12ARM64: dts: apalis-imx8qm: changes to v1.1 modulePhilippe Schenker
Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-12ARM64: dts: apalis-imx8qm: copy v1.0 devicetree to v1.1Philippe Schenker
This commit does no code changes it just copies fsl-imx8qm-apalis.dtsi to fsl-imx8qm-apalis-v1.1.dtsi. This is done to be able to track changes made between those versions. Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-12ARM: dts: imx6q-apalis: Fix pin nameOleksandr Suvorov
The interface of Apalis modules is MXM3, not SODIMM. Just fix the name of the reset touch pin. Fixes: 96458caa3562 ("ARM: dts: imx6: Add touchscreens used on Toradex eval boards") Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-02-06ARM64: dts: verdin-imx8mm: bump copyright yearPhilippe Schenker
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-06ARM64: dts: add sn65dsi84 dsi-to-lvds bridge to devicetreePhilippe Schenker
Related-to: ELB-2289 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-06ARM64: dts: verdin-imx8mm: add atmel_mxt_ts touchscreen controllerPhilippe Schenker
Related-to: ELB-2289 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-06ARM64: dts: imx8mm-verdin: add backlightPhilippe Schenker
Related-to: ELB-2289 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-03ARM64: dts: apalis-imx8qm: add wifi power down pin to pcie supplyPhilippe Schenker
Related-to: ELB-2359 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-02-03ARM64: dts: apalis-imx8qm: add sleep-mode to fecPhilippe Schenker
Note: there is still backfeeding present at this moment from those pads: SC_P_ENET0_RGMII_TXD0 SC_P_ENET0_RGMII_TXD1 SC_P_ENET0_RGMII_RXD0 SC_P_ENET0_RGMII_RXD1 Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-01-31ARM64: dts: apalis-imx8qm: add phy interrupt and led-modePhilippe Schenker
Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-01-31ARM64: dts: apalis-imx8qm: add power-domain to power down ETH PHYPhilippe Schenker
Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-01-31ARM64: defconfig: add SIMPLE_PM_BUS used for powering down ETH PHYPhilippe Schenker
Related-to: ELB-1254 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-01-16arm64: dts: fsl-imx8mm-verdin: eth phy: prevent backfeeding during sleepMax Krummenacher
Add a 'sleep' pinmuxing which prevents driving RGMII pins and backfeed the unpowered Ethernet PHY. When switching the Ethernet PHY supply off, it takes about 400 ms for the PHY power to go down. So wait a minimum of 500 ms before reenabling the PHY supply. Related-to: HAR-2339 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-01-16arm64: dts: fsl-imx8mm-verdin: eth phy: improve startupMax Krummenacher
After the Ethernet PHY supply is enabled an RC holds the reset asserted for about 120 ms. Reduce the time waited from 1000 ms to 200 ms which should account for any possible tolerance. U-Boot enables the PHY supply, switching it off in Linux with the RGMII pins allready muxed creates backfeeding, thus set regulator-boot-on. Related-to: HAR-2339 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-01-09Revert "arm64: dts: imx8qm-apalis: disable dsp"Max Krummenacher
The driver now checks the fuses for a disabled DSP. Thus enable the DSP device in the device tree and let the driver decide at run-time if the DSP can be used or not. This reverts commit 862886b0c48296d34b0e63d7497fa671e6fe25d7. Related-to: ELB-1380 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2019-12-24apalis/colibri_imx6/-imx6ull/_imx7_defconfig: fix ip firewall (bpf/cgroup)Verdin-iMX8MM_Console-Image_3.0b3.118-20200101Colibri-iMX8X_Console-Image_3.0b3.118-20200101Colibri-iMX7_Console-Image_3.0b3.118-20200101Colibri-iMX7-eMMC_Console-Image_3.0b3.118-20200101Colibri-iMX6_Console-Image_3.0b3.118-20200101Colibri-iMX6ULL_Console-Image_3.0b3.118-20200101Apalis-iMX8_Console-Image_3.0b3.118-20200101Apalis-iMX8X_Console-Image_3.0b3.118-20191231Apalis-iMX6_Console-Image_3.0b3.118-20191231Marcel Ziswiler
This fixes the following systemd error during boot: [ 4.225226] systemd[1]: File /lib/systemd/system/systemd-journald. service:36 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. [ 4.242360] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.) Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> (similar to arm64 commit cfbad309c60a13bb7fb0ad4b1139a52d485db0cd)
2019-12-19Merge branch 'github.com/Freescale/linux-fslc/4.14-2.0.x-imx' into ↵Marcel Ziswiler
toradex_4.14-2.0.x-imx-next Conflicts: sound/soc/codecs/sgtl5000.c
2019-12-18Merge tag 'v4.14.159' into 4.14-2.0.x-imxMarcel Ziswiler
This is the 4.14.159 stable release Conflicts: arch/arm/Kconfig.debug arch/arm/boot/dts/imx7s.dtsi arch/arm/mach-imx/cpuidle-imx6sx.c drivers/crypto/caam/caamalg.c drivers/crypto/mxs-dcp.c drivers/dma/imx-sdma.c drivers/input/keyboard/imx_keypad.c drivers/net/can/flexcan.c drivers/net/can/rx-offload.c drivers/net/wireless/ath/ath10k/pci.c drivers/pci/dwc/pci-imx6.c drivers/spi/spi-fsl-lpspi.c drivers/usb/dwc3/gadget.c
2019-12-17powerpc: Fix vDSO clock_getres()Vincenzo Frascino
[ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ] clock_getres in the vDSO library has to preserve the same behaviour of posix_get_hrtimer_res(). In particular, posix_get_hrtimer_res() does: sec = 0; ns = hrtimer_resolution; and hrtimer_resolution depends on the enablement of the high resolution timers that can happen either at compile or at run time. Fix the powerpc vdso implementation of clock_getres keeping a copy of hrtimer_resolution in vdso data and using that directly. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Cc: stable@vger.kernel.org Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr> Acked-by: Shuah Khan <skhan@linuxfoundation.org> [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES] Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17powerpc: Avoid clang warnings around setjmp and longjmpNathan Chancellor
[ Upstream commit c9029ef9c95765e7b63c4d9aa780674447db1ec0 ] Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when setjmp is used") disabled -Wbuiltin-requires-header because of a warning about the setjmp and longjmp declarations. r367387 in clang added another diagnostic around this, complaining that there is no jmp_buf declaration. In file included from ../arch/powerpc/xmon/xmon.c:47: ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of built-in function 'setjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header <setjmp.h>. [-Werror,-Wincomplete-setjmp-declaration] extern long setjmp(long *); ^ ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of built-in function 'longjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header <setjmp.h>. [-Werror,-Wincomplete-setjmp-declaration] extern void longjmp(long *, long); ^ 2 errors generated. We are not using the standard library's longjmp/setjmp implementations for obvious reasons; make this clear to clang by using -ffreestanding on these files. Cc: stable@vger.kernel.org # 4.14+ Suggested-by: Segher Boessenkool <segher@kernel.crashing.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17x86/MCE/AMD: Carve out the MC4_MISC thresholding quirkShirish S
[ Upstream commit 30aa3d26edb0f3d7992757287eec0ca588a5c259 ] The MC4_MISC thresholding quirk needs to be applied during S5 -> S0 and S3 -> S0 state transitions, which follow different code paths. Carve it out into a separate function and call it mce_amd_feature_init() where the two code paths of the state transitions converge. [ bp: massage commit message and the carved out function. ] Signed-off-by: Shirish S <shirish.s@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Yazen Ghannam <yazen.ghannam@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1547651417-23583-3-git-send-email-shirish.s@amd.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17x86/MCE/AMD: Turn off MC4_MISC thresholding on all family 0x15 modelsShirish S
[ Upstream commit c95b323dcd3598dd7ef5005d6723c1ba3b801093 ] MC4_MISC thresholding is not supported on all family 0x15 processors, hence skip the x86_model check when applying the quirk. [ bp: massage commit message. ] Signed-off-by: Shirish S <shirish.s@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1547106849-3476-2-git-send-email-shirish.s@amd.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251H. Nikolaus Schaller
[ Upstream commit 2398c41d64321e62af54424fd399964f3d48cdc2 ] With a wl1251 child node of mmc3 in the device tree decoded in omap_hsmmc.c to handle special wl1251 initialization, we do no longer need to instantiate the mmc3 through pdata quirks. We also can remove the wlan regulator and reset/interrupt definitions and do them through device tree. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: <stable@vger.kernel.org> # v4.7+ Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17powerpc/xive: Skip ioremap() of ESB pages for LSI interruptsCédric Le Goater
commit b67a95f2abff0c34e5667c15ab8900de73d8d087 upstream. The PCI INTx interrupts and other LSI interrupts are handled differently under a sPAPR platform. When the interrupt source characteristics are queried, the hypervisor returns an H_INT_ESB flag to inform the OS that it should be using the H_INT_ESB hcall for interrupt management and not loads and stores on the interrupt ESB pages. A default -1 value is returned for the addresses of the ESB pages. The driver ignores this condition today and performs a bogus IO mapping. Recent changes and the DEBUG_VM configuration option make the bug visible with : kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=1024 NUMA pSeries Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-0.rc6.git0.1.fc32.ppc64le #1 NIP: c000000000f63294 LR: c000000000f62e44 CTR: 0000000000000000 REGS: c0000000fa45f0d0 TRAP: 0700 Not tainted (5.4.0-0.rc6.git0.1.fc32.ppc64le) ... NIP ioremap_page_range+0x4c4/0x6e0 LR ioremap_page_range+0x74/0x6e0 Call Trace: ioremap_page_range+0x74/0x6e0 (unreliable) do_ioremap+0x8c/0x120 __ioremap_caller+0x128/0x140 ioremap+0x30/0x50 xive_spapr_populate_irq_data+0x170/0x260 xive_irq_domain_map+0x8c/0x170 irq_domain_associate+0xb4/0x2d0 irq_create_mapping+0x1e0/0x3b0 irq_create_fwspec_mapping+0x27c/0x3e0 irq_create_of_mapping+0x98/0xb0 of_irq_parse_and_map_pci+0x168/0x230 pcibios_setup_device+0x88/0x250 pcibios_setup_bus_devices+0x54/0x100 __of_scan_bus+0x160/0x310 pcibios_scan_phb+0x330/0x390 pcibios_init+0x8c/0x128 do_one_initcall+0x60/0x2c0 kernel_init_freeable+0x290/0x378 kernel_init+0x2c/0x148 ret_from_kernel_thread+0x5c/0x80 Fixes: bed81ee181dd ("powerpc/xive: introduce H_INT_ESB hcall") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191203163642.2428-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17powerpc: Allow flush_icache_range to work across ranges >4GBAlastair D'Silva
commit 29430fae82073d39b1b881a3cd507416a56a363f upstream. When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva <alastair@d-silva.org> Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191104023305.9581-2-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17powerpc/xive: Prevent page fault issues in the machine crash handlerCédric Le Goater
commit 1ca3dec2b2dff9d286ce6cd64108bda0e98f9710 upstream. When the machine crash handler is invoked, all interrupts are masked but interrupts which have not been started yet do not have an ESB page mapped in the Linux address space. This crashes the 'crash kexec' sequence on sPAPR guests. To fix, force the mapping of the ESB page when an interrupt is being mapped in the Linux IRQ number space. This is done by setting the initial state of the interrupt to OFF which is not necessarily the case on PowerNV. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191031063100.3864-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GBAlastair D'Silva
commit f9ec11165301982585e5e5f606739b5bae5331f3 upstream. When calling __kernel_sync_dicache with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva <alastair@d-silva.org> Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191104023305.9581-3-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarityJarkko Nikula
commit 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream. The MMC card detection GPIO polarity is active low on TAO3530, like in many other similar boards. Now the card is not detected and it is unable to mount rootfs from an SD card. Fix this by using the correct polarity. This incorrect polarity was defined already in the commit 30d95c6d7092 ("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18 kernel and later changed to use defined GPIO constants in v4.4 kernel by the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards"). While the latter commit did not introduce the issue I'm marking it with Fixes tag due the v4.4 kernels still being maintained. Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards") Cc: linux-stable <stable@vger.kernel.org> # 4.4+ Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17s390/mm: properly clear _PAGE_NOEXEC bit when it is not supportedGerald Schaefer
commit ab874f22d35a8058d8fdee5f13eb69d8867efeae upstream. On older HW or under a hypervisor, w/o the instruction-execution- protection (IEP) facility, and also w/o EDAT-1, a translation-specification exception may be recognized when bit 55 of a pte is one (_PAGE_NOEXEC). The current code tries to prevent setting _PAGE_NOEXEC in such cases, by removing it within set_pte_at(). However, ptep_set_access_flags() will modify a pte directly, w/o using set_pte_at(). There is at least one scenario where this can result in an active pte with _PAGE_NOEXEC set, which would then lead to a panic due to a translation-specification exception (write to swapped out page): do_swap_page pte = mk_pte (with _PAGE_NOEXEC bit) set_pte_at (will remove _PAGE_NOEXEC bit in page table, but keep it in local variable pte) vmf->orig_pte = pte (pte still contains _PAGE_NOEXEC bit) do_wp_page wp_page_reuse entry = vmf->orig_pte (still with _PAGE_NOEXEC bit) ptep_set_access_flags (writes entry with _PAGE_NOEXEC bit) Fix this by clearing _PAGE_NOEXEC already in mk_pte_phys(), where the pgprot value is applied, so that no pte with _PAGE_NOEXEC will ever be visible, if it is not supported. The check in set_pte_at() can then also be removed. Cc: <stable@vger.kernel.org> # 4.11+ Fixes: 57d7f939e7bd ("s390: add no-execute support") Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17ARM: dts: pandora-common: define wl1251 as child node of mmc3H. Nikolaus Schaller
commit 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream. Since v4.7 the dma initialization requires that there is a device tree property for "rx" and "tx" channels which is not provided by the pdata-quirks initialization. By conversion of the mmc3 setup to device tree this will finally allows to remove the OpenPandora wlan specific omap3 data-quirks. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: <stable@vger.kernel.org> # v4.7+ Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17KVM: x86: fix out-of-bounds write in KVM_GET_EMULATED_CPUID (CVE-2019-19332)Paolo Bonzini
commit 433f4ba1904100da65a311033f17a9bf586b287e upstream. The bounds check was present in KVM_GET_SUPPORTED_CPUID but not KVM_GET_EMULATED_CPUID. Reported-by: syzbot+e3f4897236c4eeb8af4f@syzkaller.appspotmail.com Fixes: 84cffe499b94 ("kvm: Emulate MOVBE", 2013-10-29) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIESPaolo Bonzini
commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream. KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented to the guests. It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR && !RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not hidden (it actually was), yet the value says that TSX is not vulnerable to microarchitectural data sampling. Fix both. Cc: stable@vger.kernel.org Tested-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17KVM: x86: do not modify masked bits of shared MSRsPaolo Bonzini
commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream. "Shared MSRs" are guest MSRs that are written to the host MSRs but keep their value until the next return to userspace. They support a mask, so that some bits keep the host value, but this mask is only used to skip an unnecessary MSR write and the value written to the MSR is always the guest MSR. Fix this and, while at it, do not update smsr->values[slot].curr if for whatever reason the wrmsr fails. This should only happen due to reserved bits, so the value written to smsr->values[slot].curr will not match when the user-return notifier and the host value will always be restored. However, it is untidy and in rare cases this can actually avoid spurious WRMSRs on return to userspace. Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson <jmattson@google.com> Tested-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defectKai-Heng Feng
commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream. The AMD FCH USB XHCI Controller advertises support for generating PME# while in D0. When in D0, it does signal PME# for USB 3.0 connect events, but not for USB 2.0 or USB 1.1 connect events, which means the controller doesn't wake correctly for those events. 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI]) Subsystem: Dell FCH USB XHCI Controller [1028:087e] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not assert PME# from D0 so we don't rely on it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673 Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17ARM: dts: sunxi: Fix PMU compatible stringsRob Herring
[ Upstream commit 5719ac19fc32d892434939c1756c2f9a8322e6ef ] "arm,cortex-a15-pmu" is not a valid fallback compatible string for an Cortex-A7 PMU, so drop it. Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17MIPS: OCTEON: cvmx_pko_mem_debug8: use oldest forward compatible definitionAaro Koskinen
[ Upstream commit 1c6121c39677175bd372076020948e184bad4b6b ] cn58xx is compatible with cn50xx, so use the latter. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> [paul.burton@mips.com: s/cn52xx/cn50xx/ in commit message.] Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17powerpc/math-emu: Update macros from GCCJoel Stanley
[ Upstream commit b682c8692442711684befe413cf93cf01c5324ea ] The add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate from GCC's longlong.h which in turn was copied from GMP's longlong.h a few decades ago. This was found when compiling with clang: arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions FP_ADD_D(R, T, B); ^~~~~~~~~~~~~~~~~ ... ./arch/powerpc/include/asm/sfp-machine.h:283:27: note: expanded from macro 'sub_ddmmss' : "=r" ((USItype)(sh)), \ ~~~~~~~~~~^~~ Segher points out: this was fixed in GCC over 16 years ago ( https://gcc.gnu.org/r56600 ), and in GMP (where it comes from) presumably before that. Update the add_ssaaaa, sub_ddmmss, umul_ppmm and udiv_qrnnd macros to the latest GCC version in order to git rid of the invalid casts. These were taken as-is from GCC's longlong in order to make future syncs obvious. Other parts of sfp-machine.h were left as-is as the file contains more features than present in longlong.h. Link: https://github.com/ClangBuiltLinux/linux/issues/260 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17ARM: dts: realview: Fix some more duplicate regulator nodesRob Herring
[ Upstream commit f3b2f758ec1e6cdb13c925647cbd8ad4938b78fb ] There's a bug in dtc in checking for duplicate node names when there's another section (e.g. "/ { };"). In this case, skeleton.dtsi provides another section. Upon removal of skeleton.dtsi, the dtb fails to build due to a duplicate node 'fixedregulator@0'. As both nodes were pretty much the same 3.3V fixed regulator, it hasn't really mattered. Fix this by renaming the nodes to something unique. In the process, drop the unit-address which shouldn't be present wtihout reg property. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17ARM: dts: pxa: clean up USB controller nodesDaniel Mack
[ Upstream commit c40ad24254f1dbd54f2df5f5f524130dc1862122 ] PXA25xx SoCs don't have a USB controller, so drop the node from the common pxa2xx.dtsi base file. Both pxa27x and pxa3xx have a dedicated node already anyway. While at it, unify the names for the nodes across all pxa platforms. Signed-off-by: Daniel Mack <daniel@zonque.org> Reported-by: Sergey Yanovich <ynvich@gmail.com> Link: https://patchwork.kernel.org/patch/8375421/ Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Sasha Levin <sashal@kernel.org>