aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-02-03ARM: dts: lpc32xx: phy3250: add unit address to memory device nodeVladimir Zapolskiy1-3/+2
The change adds a unit address to memory device node, the issue was reported as a unit_address_vs_reg warning by dtc. Root device node properties #address-cells and #size-cells were removed as inherited from lpc32xx.dtsi. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: phy3250: setup LCD controller to panel interfaceVladimir Zapolskiy1-0/+19
The change adds description of Sharp LQ035Q7DB03 3.5" 320x240 TFT panel, which is connected to Phytec phyCORE-LPC3250 board, ARM PrimeCell PL111 LCD controller on NXP LPC3250 SoC gets its configuration appropriately to support graphics output to the panel. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: phy3250: remove regulators umbrella device nodeVladimir Zapolskiy1-32/+31
The originally added 'regulators' device node has a number of flaws, to name a few its children has unit addresses but no reg properties, the regulators are not captured by a device driver due to a missing 'simple-bus' compatible, the regulator names are selected by killing either alphabetical order or device node grouping property. The change removes 'regulators' device node and renames the regulators and labels. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: phy3250: fix SD card regulator voltageVladimir Zapolskiy1-2/+2
The fixed voltage regulator on Phytec phyCORE-LPC3250 board, which supplies SD/MMC card's power, has a constant output voltage level of either 3.15V or 3.3V, the actual value depends on JP4 position, the power rail is referenced as VCC_SDIO in the board hardware manual. Fixes: d06670e96267 ("arm: dts: phy3250: add SD fixed regulator") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: fix ARM PrimeCell LCD controller clocks propertyVladimir Zapolskiy1-2/+2
The originally added ARM PrimeCell PL111 clocks property misses the required "clcdclk" clock, which is the same as a clock to enable the LCD controller on NXP LPC3230 and NXP LPC3250 SoCs. Fixes: 93898eb775e5 ("arm: dts: lpc32xx: add clock properties to device nodes") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: fix ARM PrimeCell LCD controller variantVladimir Zapolskiy1-1/+1
ARM PrimeCell PL111 LCD controller is found on On NXP LPC3230 and LPC3250 SoCs variants, the original reference in compatible property to an older one ARM PrimeCell PL110 is invalid. Fixes: e04920d9efcb3 ("ARM: LPC32xx: DTS files for device tree conversion") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: reparent keypad controller to SIC1Vladimir Zapolskiy1-1/+2
After switching to a new interrupt controller scheme by separating SIC1 and SIC2 from MIC interrupt controller just one SoC keypad controller was not taken into account, fix it now: WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:524 irq_domain_associate+0x50/0x1b0 error: hwirq 0x36 is too large for interrupt-controller@40008000 ... lpc32xx_keys 40050000.key: failed to get platform irq lpc32xx_keys: probe of 40050000.key failed with error -22 Fixes: 9b8ad3fb81ae ("ARM: dts: lpc32xx: reparent SIC1 and SIC2 interrupts from MIC") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: add required clocks property to keypad device nodeVladimir Zapolskiy1-0/+1
NXP LPC32xx keypad controller requires a clock property to be defined. The change fixes the driver initialization problem: lpc32xx_keys 40050000.key: failed to get clock lpc32xx_keys: probe of 40050000.key failed with error -2 Fixes: 93898eb775e5 ("arm: dts: lpc32xx: add clock properties to device nodes") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: Add DT for MYIR Tech MYD-LPC4357 Development BoardVladimir Zapolskiy2-1/+621
Add support for MYIR Tech MYD-LPC4357 Development Board and MY-LCD70TP-C 7" TFT LCD module with Innolux AT070TN82 panel. The board contains quite rich periferals, the list features NXP LPC4357 SoC, 32 MB SDRAM, 4 MB SPI Flash, audio input/output interface, LCD panel, micro SD card slot, USB, USB OTG, Ethernet, 2 CAN ports, 4 UARTs, I2C and SPI interfaces routed to external interface. More information can be found on http://www.myirtech.com/list.asp?id=422 Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: dts: lpc32xx: Remove leading 0x and 0s from bindings notationMathieu Malaterre1-9/+9
Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} + For simplicity, two sed expressions were used to solve each warnings separately. To make the regex expression more robust a few other issues were resolved, namely setting unit-address to lower case, and adding a whitespace before the opening curly brace: https://elinux.org/Device_Tree_Linux#Linux_conventions This will solve as a side effect warning: Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>" This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation") Reported-by: David Daney <ddaney@caviumnetworks.com> Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Mathieu Malaterre <malat@debian.org> [vzapolskiy: fixed commit message to pass checkpatch.pl test] Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: defconfig: lpc32xx: enable DRM simple panel driverVladimir Zapolskiy1-0/+1
Phytec phyCORE-LPC3250 board is equipped with a Sharp LQ035Q7DB03 3.5" QVGA TFT panel, enable simple panel device driver to get it supported in the kernel image by default. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03ARM: defconfig: lpc32xx: enable fixed voltage regulator supportVladimir Zapolskiy1-0/+2
Fixed voltage regulators are found on Phytec phyCORE-LPC3250 board, enable the correspondent device driver by default. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
2019-02-03sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEWDeepa Dinamani4-9/+35
Add new socket timeout options that are y2038 safe. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: ccaulfie@redhat.com Cc: davem@davemloft.net Cc: deller@gmx.de Cc: paulus@samba.org Cc: ralf@linux-mips.org Cc: rth@twiddle.net Cc: cluster-devel@redhat.com Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-alpha@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixesDeepa Dinamani5-10/+20
SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval as the time format. struct timeval is not y2038 safe. The subsequent patches in the series add support for new socket timeout options with _NEW suffix that will use y2038 safe data structures. Although the existing struct timeval layout is sufficiently wide to represent timeouts, because of the way libc will interpret time_t based on user defined flag, these new flags provide a way of having a structure that is the same for all architectures consistently. Rename the existing options with _OLD suffix forms so that the right option is enabled for userspace applications according to the architecture and time_t definition of libc. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: ccaulfie@redhat.com Cc: deller@gmx.de Cc: paulus@samba.org Cc: ralf@linux-mips.org Cc: rth@twiddle.net Cc: cluster-devel@redhat.com Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-alpha@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03socket: Add SO_TIMESTAMPING_NEWDeepa Dinamani4-8/+12
Add SO_TIMESTAMPING_NEW variant of socket timestamp options. This is the y2038 safe versions of the SO_TIMESTAMPING_OLD for all architectures. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: chris@zankel.net Cc: fenghua.yu@intel.com Cc: rth@twiddle.net Cc: tglx@linutronix.de Cc: ubraun@linux.ibm.com Cc: linux-alpha@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-ia64@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-s390@vger.kernel.org Cc: linux-xtensa@linux-xtensa.org Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03socket: Add SO_TIMESTAMP[NS]_NEWDeepa Dinamani4-8/+48
Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of socket timestamp options. These are the y2038 safe versions of the SO_TIMESTAMP_OLD and SO_TIMESTAMPNS_OLD for all architectures. Note that the format of scm_timestamping.ts[0] is not changed in this patch. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: jejb@parisc-linux.org Cc: ralf@linux-mips.org Cc: rth@twiddle.net Cc: linux-alpha@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-parisc@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: netdev@vger.kernel.org Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03arch: sparc: Override struct __kernel_old_timevalDeepa Dinamani1-0/+10
struct __kernel_old_timeval is supposed to have the same layout as struct timeval. But, it was inadvarently missed that __kernel_suseconds has a different definition for sparc64. Provide an asm-specific override that fixes it. Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03sockopt: Rename SO_TIMESTAMP* to SO_TIMESTAMP*_OLDDeepa Dinamani4-29/+64
SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING options, the way they are currently defined, are not y2038 safe. Subsequent patches in the series add new y2038 safe versions of these options which provide 64 bit timestamps on all architectures uniformly. Hence, rename existing options with OLD tag suffixes. Also note that kernel will not use the untagged SO_TIMESTAMP* and SCM_TIMESTAMP* options internally anymore. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: deller@gmx.de Cc: dhowells@redhat.com Cc: jejb@parisc-linux.org Cc: ralf@linux-mips.org Cc: rth@twiddle.net Cc: linux-afs@lists.infradead.org Cc: linux-alpha@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-parisc@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03arch: Use asm-generic/socket.h when possibleDeepa Dinamani9-366/+5
Many architectures maintain an arch specific copy of the file even though there are no differences with the asm-generic one. Allow these architectures to use the generic one instead. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Willem de Bruijn <willemb@google.com> Cc: chris@zankel.net Cc: fenghua.yu@intel.com Cc: tglx@linutronix.de Cc: schwidefsky@de.ibm.com Cc: linux-ia64@vger.kernel.org Cc: linux-xtensa@linux-xtensa.org Cc: linux-s390@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-03Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds10-12/+24
Pull x86 fixes from Thomas Gleixner: "A few updates for x86: - Fix an unintended sign extension issue in the fault handling code - Rename the new resource control config switch so it's less confusing - Avoid setting up EFI info in kexec when the EFI runtime is disabled. - Fix the microcode version check in the AMD microcode loader so it only loads higher version numbers and never downgrades - Set EFER.LME in the 32bit trampoline before returning to long mode to handle older AMD/KVM behaviour properly. - Add Darren and Andy as x86/platform reviewers" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/resctrl: Avoid confusion over the new X86_RESCTRL config x86/kexec: Don't setup EFI info if EFI runtime is not enabled x86/microcode/amd: Don't falsely trick the late loading mechanism MAINTAINERS: Add Andy and Darren as arch/x86/platform/ reviewers x86/fault: Fix sign-extend unintended sign extension x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning to long mode x86/cpu: Add Atom Tremont (Jacobsville)
2019-02-03Merge branch 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds2-2/+3
Pull cpu hotplug fixes from Thomas Gleixner: "Two fixes for the cpu hotplug machinery: - Replace the overly clever 'SMT disabled by BIOS' detection logic as it breaks KVM scenarios and prevents speculation control updates when the Hyperthreads are brought online late after boot. - Remove a redundant invocation of the speculation control update function" * 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM x86/speculation: Remove redundant arch_smt_update() invocation
2019-02-03x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out()Tony Luck1-0/+1
Internal injection testing crashed with a console log that said: mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0: bd80000000100134 This caused a lot of head scratching because the MCACOD (bits 15:0) of that status is a signature from an L1 data cache error. But Linux says that it found it in "Bank 0", which on this model CPU only reports L1 instruction cache errors. The answer was that Linux doesn't initialize "m->bank" in the case that it finds a fatal error in the mce_no_way_out() pre-scan of banks. If this was a local machine check, then this partially initialized struct mce is being passed to mce_panic(). Fix is simple: just initialize m->bank in the case of a fatal error. Fixes: 40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message") Signed-off-by: Tony Luck <tony.luck@intel.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: Vishal Verma <vishal.l.verma@intel.com> Cc: x86-ml <x86@kernel.org> Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.com
2019-02-03x86/MCE/AMD, EDAC/mce_amd: Add new error descriptions for some SMCA bank typesYazen Ghannam1-4/+4
Some SMCA bank types on future systems will report new error types even though the bank type is not treated as a new version. These new error types will reported by bits that are reserved in past systems. Add the new error descriptions to the lists in edac_mce_amd. Signed-off-by: Yazen Ghannam <yazen.ghannam@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: linux-edac <linux-edac@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Shirish S <Shirish.S@amd.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190201225534.8177-4-Yazen.Ghannam@amd.com
2019-02-03x86/MCE/AMD, EDAC/mce_amd: Add new McaTypes for CS, PSP, and SMU unitsYazen Ghannam2-0/+9
The existing CS, PSP, and SMU SMCA bank types will see new versions (as indicated by their McaTypes) in future SMCA systems. Add the new (HWID, MCATYPE) tuples for these new versions. Reuse the same names as the older versions, since they are logically the same to the user. SMCA systems won't mix and match IP blocks with different McaType versions in the same system, so there isn't a need to distinguish them. The MCA_IPID register is saved when logging an MCA error, and that can be used to triage the error. Also, add the new error descriptions to edac_mce_amd. Some error types (positions in the list) are overloaded compared to the previous McaTypes. Therefore, just create new lists of the error descriptions to keep things simple even if some of the error descriptions are the same between versions. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Pu Wen <puwen@hygon.cn> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: Shirish S <Shirish.S@amd.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/20190201225534.8177-3-Yazen.Ghannam@amd.com
2019-02-03x86/MCE/AMD, EDAC/mce_amd: Add new MP5, NBIO, and PCIE SMCA bank typesYazen Ghannam2-0/+15
Add the (HWID, MCATYPE) tuples and names for the new MP5, NBIO, and PCIE SMCA bank types. Also, add their respective error descriptions to the MCE decoding module edac_mce_amd. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Pu Wen <puwen@hygon.cn> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: Shirish S <Shirish.S@amd.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/20190201225534.8177-2-Yazen.Ghannam@amd.com
2019-02-03Move static keyword at beginning of declarationMathieu Malaterre2-4/+4
Move the static keyword around to remove the following warnings (W=1): arch/powerpc/platforms/ps3/os-area.c:212:1: error: 'static' is not at beginning of declaration [-Werror=old-style-declaration] arch/powerpc/platforms/ps3/system-bus.c:45:1: error: 'static' is not at beginning of declaration [-Werror=old-style-declaration] Signed-off-by: Mathieu Malaterre <malat@debian.org> Acked-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-03powerpc: Remove trailing semicolon after curly braceMathieu Malaterre1-1/+1
There is not point in having a trailing semicolon after a closing curly brace. Remove it. Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-03ARM: dts: rockchip: Use the correct regulator properties on rv1108-evbOtavio Salvador1-10/+10
The following properties: - regulator-state-enabled - regulator-state-disabled - regulator-state-uv are not valid ones as per Documentation/devicetree/bindings/regulator/regulator.txt Fix it by using the correct properties as per the dt bindings. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-02-03ARM: dts: rockchip: Use the correct regulator properties on rv1108-elginOtavio Salvador1-10/+10
The following properties: - regulator-state-enabled - regulator-state-disabled - regulator-state-uv are not valid ones as per Documentation/devicetree/bindings/regulator/regulator.txt Fix it by using the correct properties as per the dt bindings. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-02-03ARM: dts: rockchip: Fix vcc5/6-supply representation on rv1108-elginOtavio Salvador1-6/+8
On rv1108-elgin-r1 board the RK805 VCC5 and VCC6 supplies come from the BUCK2 regulator at 2.2V, so fix the representation in the device tree. While at it, rename it from vdd_cam to vdd_buck2, which is a better name for the regulator label. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-02-03arm64: dts: rockchip: enable mali power supply on rk3399-rockpro64Andrius Štikonas1-0/+5
Enable the gpu node and add the supplying regulator Signed-off-by: Andrius Štikonas <andrius@stikonas.eu> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-02-03arm64: dts: rockchip: Enable HDMI audio devices on rk3399-rock960Ezequiel Garcia1-0/+8
This commit enable the hdmi-sound and i2s2 devices needed to have audio over HDMI on both rock960 and the related ficus board. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-02-02Merge tag 'riscv-for-linus-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linuxLinus Torvalds9-14/+30
Pull RISC-V fixes from Palmer Dabbelt: "This contains a handful of mostly-independent patches: - make our port respect TIF_NEED_RESCHED, which fixes CONFIG_PREEMPT=y kernels - fix double-put of OF nodes - fix a misspelling of target in our Kconfig - generic PCIe is enabled in our defconfig - fix our SBI early console to properly handle line endings - fix max_low_pfn being counted in PFNs - a change to TASK_UNMAPPED_BASE to match what other arches do This has passed my standard 'boot Fedora' flow" * tag 'riscv-for-linus-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: riscv: Adjust mmap base address at a third of task size riscv: fixup max_low_pfn with PFN_DOWN. tty/serial: use uart_console_write in the RISC-V SBL early console RISC-V: defconfig: Add CRYPTO_DEV_VIRTIO=y RISC-V: defconfig: Enable Generic PCIE by default RISC-V: defconfig: Move CONFIG_PCI{,E_XILINX} RISC-V: Kconfig: fix spelling mistake "traget" -> "target" RISC-V: asm/page.h: fix spelling mistake "CONFIG_64BITS" -> "CONFIG_64BIT" RISC-V: fix bad use of of_node_put RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y
2019-02-02Merge branch 'akpm' (patches from Andrew)Linus Torvalds15-7/+11
Merge misc fixes from Andrew Morton: "24 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (24 commits) autofs: fix error return in autofs_fill_super() autofs: drop dentry reference only when it is never used fs/drop_caches.c: avoid softlockups in drop_pagecache_sb() mm: migrate: don't rely on __PageMovable() of newpage after unlocking it psi: clarify the Kconfig text for the default-disable option mm, memory_hotplug: __offline_pages fix wrong locking mm: hwpoison: use do_send_sig_info() instead of force_sig() kasan: mark file common so ftrace doesn't trace it init/Kconfig: fix grammar by moving a closing parenthesis lib/test_kmod.c: potential double free in error handling mm, oom: fix use-after-free in oom_kill_process mm/hotplug: invalid PFNs from pfn_to_online_page() mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages psi: fix aggregation idle shut-off mm, memory_hotplug: test_pages_in_a_zone do not pass the end of zone mm, memory_hotplug: is_mem_section_removable do not pass the end of a zone oom, oom_reaper: do not enqueue same task twice mm: migrate: make buffer_migrate_page_norefs() actually succeed kernel/exit.c: release ptraced tasks before zap_pid_ns_processes x86_64: increase stack size for KASAN_EXTRA ...
2019-02-02Merge remote-tracking branch 'tip/x86/urgent' into edac-for-5.1Borislav Petkov23-21/+63
... to pick up dependent change: 00ae831dfe44 ("x86/cpu: Add Atom Tremont (Jacobsville)") introducing the model number define which will be needed by the new i10nm_edac driver for 10nm Intel Atoms. Signed-off-by: Borislav Petkov <bp@suse.de>
2019-02-02x86/resctrl: Avoid confusion over the new X86_RESCTRL configJohannes Weiner4-8/+8
"Resource Control" is a very broad term for this CPU feature, and a term that is also associated with containers, cgroups etc. This can easily cause confusion. Make the user prompt more specific. Match the config symbol name. [ bp: In the future, the corresponding ARM arch-specific code will be under ARM_CPU_RESCTRL and the arch-agnostic bits will be carved out under the CPU_RESCTRL umbrella symbol. ] Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Babu Moger <Babu.Moger@amd.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morse <james.morse@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: linux-doc@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Pu Wen <puwen@hygon.cn> Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190130195621.GA30653@cmpxchg.org
2019-02-01arm64: dts: sdm845: Add interconnect provider DT nodesDavid Dai1-0/+5
Add RSC (Resource State Coordinator) provider dictating network-on-chip interconnect bus performance found on SDM845-based platforms. Signed-off-by: David Dai <daidavid1@codeaurora.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-01arm64: dts: qcom: msm8996: Disabled VFE SMMUBjorn Andersson1-1/+1
Initializing the SMMU trips a security violation, so disable the VFE SMMU for now. Fixes: f3442ab97257 ("arm64: dts: qcom: msm8996: Add VFE SMMU node") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-01arm64: dts: qcom: qcs404: Add rpmcc nodeBjorn Andersson1-0/+6
Add the rpm clock controller node, to provide the low-noise baseband clock for the USB PHYs, among other things. Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-01arm64: dts: qcom: msm8998: Add rpmcc nodeMarc Gonzalez1-0/+6
Add MSM8998 Resource Power Manager Clock Controller DT node. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-01arm64: dts: qcom: msm8998: Add USB-related nodesJeffrey Hugo2-0/+114
Add nodes for USB and related PHYs. Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-01Merge tag 'xtensa-20190201' of git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds10-26/+43
Pull xtensa fixes from Max Filippov: - fix ccount_timer_shutdown for secondary CPUs - fix secondary CPU initialization - fix secondary CPU reset vector clash with double exception vector - fix present CPUs when booting with 'maxcpus' parameter - limit possible CPUs by configured NR_CPUS - issue a warning if xtensa PIC is asked to retrigger anything other than software IRQ - fix masking/unmasking of the first two IRQs on xtensa MX PIC - fix typo in Kconfig description for user space unaligned access feature - fix Kconfig warning for selecting BUILTIN_DTB * tag 'xtensa-20190201' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: SMP: limit number of possible CPUs by NR_CPUS xtensa: rename BUILTIN_DTB to BUILTIN_DTB_SOURCE xtensa: Fix typo use space=>user space drivers/irqchip: xtensa-mx: fix mask and unmask drivers/irqchip: xtensa: add warning to irq_retrigger xtensa: SMP: mark each possible CPU as present xtensa: smp_lx200_defconfig: fix vectors clash xtensa: SMP: fix secondary CPU initialization xtensa: SMP: fix ccount_timer_shutdown
2019-02-01Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds5-5/+14
Pull arm64 fixes from Will Deacon: "Although we're still debugging a few minor arm64-specific issues in mainline, I didn't want to hold this lot up in the meantime. We've got an additional KASLR fix after the previous one wasn't quite complete, a fix for a performance regression when mapping executable pages into userspace and some fixes for kprobe blacklisting. All candidates for stable. Summary: - Fix module loading when KASLR is configured but disabled at runtime - Fix accidental IPI when mapping user executable pages - Ensure hyp-stub and KVM world switch code cannot be kprobed" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: hibernate: Clean the __hyp_text to PoC after resume arm64: hyp-stub: Forbid kprobing of the hyp-stub arm64: kprobe: Always blacklist the KVM world-switch code arm64: kaslr: ensure randomized quantities are clean also when kaslr is off arm64: Do not issue IPIs for user executable ptes
2019-02-01x86_64: increase stack size for KASAN_EXTRAQian Cai1-0/+4
If the kernel is configured with KASAN_EXTRA, the stack size is increasted significantly because this option sets "-fstack-reuse" to "none" in GCC [1]. As a result, it triggers stack overrun quite often with 32k stack size compiled using GCC 8. For example, this reproducer https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c triggers a "corrupted stack end detected inside scheduler" very reliably with CONFIG_SCHED_STACK_END_CHECK enabled. There are just too many functions that could have a large stack with KASAN_EXTRA due to large local variables that have been called over and over again without being able to reuse the stacks. Some noticiable ones are size 7648 shrink_page_list 3584 xfs_rmap_convert 3312 migrate_page_move_mapping 3312 dev_ethtool 3200 migrate_misplaced_transhuge_page 3168 copy_process There are other 49 functions are over 2k in size while compiling kernel with "-Wframe-larger-than=" even with a related minimal config on this machine. Hence, it is too much work to change Makefiles for each object to compile without "-fsanitize-address-use-after-scope" individually. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23 Although there is a patch in GCC 9 to help the situation, GCC 9 probably won't be released in a few months and then it probably take another 6-month to 1-year for all major distros to include it as a default. Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020 when GCC 9 is everywhere. Until then, this patch will help users avoid stack overrun. This has already been fixed for arm64 for the same reason via 6e8830674ea ("arm64: kasan: Increase stack size for KASAN_EXTRA"). Link: http://lkml.kernel.org/r/20190109215209.2903-1-cai@lca.pw Signed-off-by: Qian Cai <cai@lca.pw> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-01arch: unexport asm/shmparam.h for all architecturesMasahiro Yamada14-7/+7
Most architectures do not export shmparam.h to user-space. $ find arch -name shmparam.h | sort arch/alpha/include/asm/shmparam.h arch/arc/include/asm/shmparam.h arch/arm64/include/asm/shmparam.h arch/arm/include/asm/shmparam.h arch/csky/include/asm/shmparam.h arch/ia64/include/asm/shmparam.h arch/mips/include/asm/shmparam.h arch/nds32/include/asm/shmparam.h arch/nios2/include/asm/shmparam.h arch/parisc/include/asm/shmparam.h arch/powerpc/include/asm/shmparam.h arch/s390/include/asm/shmparam.h arch/sh/include/asm/shmparam.h arch/sparc/include/asm/shmparam.h arch/x86/include/asm/shmparam.h arch/xtensa/include/asm/shmparam.h Strangely, some users of the asm-generic wrapper export shmparam.h $ git grep 'generic-y += shmparam.h' arch/c6x/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/h8300/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/hexagon/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/m68k/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/microblaze/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/openrisc/include/uapi/asm/Kbuild:generic-y += shmparam.h arch/riscv/include/asm/Kbuild:generic-y += shmparam.h arch/unicore32/include/uapi/asm/Kbuild:generic-y += shmparam.h The newly added riscv correctly creates the asm-generic wrapper in the kernel space, but the others (c6x, h8300, hexagon, m68k, microblaze, openrisc, unicore32) create the one in the uapi directory. Digging into the git history, now I guess fcc8487d477a ("uapi: export all headers under uapi directories") was the misconversion. Prior to that commit, no architecture exported to shmparam.h As its commit description said, that commit exported shmparam.h for c6x, h8300, hexagon, m68k, openrisc, unicore32. 83f0124ad81e ("microblaze: remove asm-generic wrapper headers") accidentally exported shmparam.h for microblaze. This commit unexports shmparam.h for those architectures. There is no more reason to export include/uapi/asm-generic/shmparam.h, so it has been moved to include/asm-generic/shmparam.h Link: http://lkml.kernel.org/r/1546904307-11124-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Stafford Horne <shorne@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Michal Simek <monstr@monstr.eu> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Guo Ren <guoren@kernel.org> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: Mark Salter <msalter@redhat.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Jonas Bonn <jonas@southpole.se> Cc: Vincent Chen <deanbo422@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-01arm64: dts: broadcom: Add reference to RPi 3 A+Stefan Wahren2-1/+4
This adds a reference to the dts of the Raspberry Pi 3 A+, so we don't need to maintain the content in arm64. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-02-01ARM: dts: add Raspberry Pi 3 A+Stefan Wahren2-0/+176
The Raspberry Pi 3 A+ is similar to the Pi 3 B+ but has only 512 MB RAM, 1 USB 2.0 port and no Ethernet. Compared to the Raspberry Pi 3 B it isn't possible to control BT_ON and WL_ON separately. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-02-01ARM: avoid Cortex-A9 livelock on tight dmb loopsRussell King5-4/+17
machine_crash_nonpanic_core() does this: while (1) cpu_relax(); because the kernel has crashed, and we have no known safe way to deal with the CPU. So, we place the CPU into an infinite loop which we expect it to never exit - at least not until the system as a whole is reset by some method. In the absence of erratum 754327, this code assembles to: b . In other words, an infinite loop. When erratum 754327 is enabled, this becomes: 1: dmb b 1b It has been observed that on some systems (eg, OMAP4) where, if a crash is triggered, the system tries to kexec into the panic kernel, but fails after taking the secondary CPU down - placing it into one of these loops. This causes the system to livelock, and the most noticable effect is the system stops after issuing: Loading crashdump kernel... to the system console. The tested as working solution I came up with was to add wfe() to these infinite loops thusly: while (1) { cpu_relax(); wfe(); } which, without 754327 builds to: 1: wfe b 1b or with 754327 is enabled: 1: dmb wfe b 1b Adding "wfe" does two things depending on the environment we're running under: - where we're running on bare metal, and the processor implements "wfe", it stops us spinning endlessly in a loop where we're never going to do any useful work. - if we're running in a VM, it allows the CPU to be given back to the hypervisor and rescheduled for other purposes (maybe a different VM) rather than wasting CPU cycles inside a crashed VM. However, in light of erratum 794072, Will Deacon wanted to see 10 nops as well - which is reasonable to cover the case where we have erratum 754327 enabled _and_ we have a processor that doesn't implement the wfe hint. So, we now end up with: 1: wfe b 1b when erratum 754327 is disabled, or: 1: dmb nop nop nop nop nop nop nop nop nop nop wfe b 1b when erratum 754327 is enabled. We also get the dmb + 10 nop sequence elsewhere in the kernel, in terminating loops. This is reasonable - it means we get the workaround for erratum 794072 when erratum 754327 is enabled, but still relinquish the dead processor - either by placing it in a lower power mode when wfe is implemented as such or by returning it to the hypervisior, or in the case where wfe is a no-op, we use the workaround specified in erratum 794072 to avoid the problem. These as two entirely orthogonal problems - the 10 nops addresses erratum 794072, and the wfe is an optimisation that makes the system more efficient when crashed either in terms of power consumption or by allowing the host/other VMs to make use of the CPU. I don't see any reason not to use kexec() inside a VM - it has the potential to provide automated recovery from a failure of the VMs kernel with the opportunity for saving a crashdump of the failure. A panic() with a reboot timeout won't do that, and reading the libvirt documentation, setting on_reboot to "preserve" won't either (the documentation states "The preserve action for an on_reboot event is treated as a destroy".) Surely it has to be a good thing to avoiding having CPUs spinning inside a VM that is doing no useful work. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-02-01ARM: smp: remove arch-provided "pen_release"Russell King12-43/+56
Consolidating the "pen_release" stuff amongst the various SoC implementations gives credence to having a CPU holding pen for secondary CPUs. However, this is far from the truth. Many SoC implementations cargo-cult copied various bits of the pen release implementation from the initial Realview/Versatile Express implementation without understanding what it was or why it existed. The reason it existed is because these are _development_ platforms, and some board firmware is unable to individually control the startup of secondary CPUs. Moreover, they do not have a way to power down or reset secondary CPUs for hot-unplug. Hence, the pen_release implementation was designed for ARM Ltd's development platforms to provide a working implementation, even though it is very far from what is required. It was decided a while back to reduce the duplication by consolidating the "pen_release" variable, but this only made the situation worse - we have ended up with several implementations that read this variable but do not write it - again, showing the cargo-cult mentality at work, lack of proper review of new code, and in some cases a lack of testing. While it would be preferable to remove pen_release entirely from the kernel, this is not possible without help from the SoC maintainers, which seems to be lacking. However, I want to remove pen_release from arch code to remove the credence that having it gives. This patch removes pen_release from the arch code entirely, adding private per-SoC definitions for it instead, and explicitly stating that write_pen_release() is cargo-cult copied and should not be copied any further. Rename write_pen_release() in a similar fashion as well. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-02-01ARM: actions: remove boot_lock and pen_releaseRussell King1-15/+0
The actions SMP implementation has several issues: 1. pen_release is only ever read and compared to -1, and is defined in arch/arm/kernel/smp.c to be -1. This test will always succeed. 2. we are already guaranteed to be single threaded while bringing up a CPU, so the spinlock makes no sense, remove it. 3. owl_secondary_startup() is not referenced nor defined, the prototype is redundant, remove it. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>