aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-06-06x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernelsJunichi Nomura1-36/+107
Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr() in the early parsing code tries to search RSDP from the EFI tables but that will crash because the table address is virtual when the kernel was booted by kexec (set_virtual_address_map() has run in the first kernel and cannot be run again in the second kernel). In the case of kexec, the physical address of EFI tables is provided via efi_setup_data in boot_params, which is set up by kexec(1). Factor out the table parsing code and use different pointers depending on whether the kernel is booted by kexec or not. [ bp: Massage. ] Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params") Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Cc: Chao Fan <fanc.fnst@cn.fujitsu.com> Cc: Dave Young <dyoung@redhat.com> Link: https://lkml.kernel.org/r/20190408231011.GA5402@jeru.linux.bs1.fc.nec.co.jp
2019-06-06x86/kexec: Add the EFI system tables and ACPI tables to the ident mapKairui Song1-0/+75
Currently, only the whole physical memory is identity-mapped for the kexec kernel and the regions reserved by firmware are ignored. However, the recent addition of RSDP parsing in the decompression stage and especially: 33f0df8d843d ("x86/boot: Search for RSDP in the EFI tables") which tries to access EFI system tables and to dig out the RDSP address from there, becomes a problem because in certain configurations, they might not be mapped in the kexec'ed kernel's address space. What is more, this problem doesn't appear on all systems because the kexec kernel uses gigabyte pages to build the identity mapping. And the EFI system tables and ACPI tables can, depending on the system configuration, end up being mapped as part of all physical memory, if they share the same 1 GB area with the physical memory. Therefore, make sure they're always mapped. [ bp: productize half-baked patch: - rewrite commit message. - correct the map_acpi_tables() function name in the !ACPI case. ] Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Cc: dyoung@redhat.com Cc: fanc.fnst@cn.fujitsu.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: j-nomura@ce.jp.nec.com Cc: kexec@lists.infradead.org Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Lianbo Jiang <lijiang@redhat.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190429002318.GA25400@MiWiFi-R3L-srv
2019-06-06x86/fpu: Use fault_in_pages_writeable() for pre-faultingHugh Dickins1-9/+2
Since commit d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") get_user_pages_unlocked() pre-faults user's memory if a write generates a page fault while the handler is disabled. This works in general and uncovered a bug as reported by Mike Rapoport¹. It has been pointed out that this function may be fragile and a simple pre-fault as in fault_in_pages_writeable() would be a better solution. Better as in taste and simplicity: that write (as performed by the alternative function) performs exactly the same faulting of memory as before. This was suggested by Hugh Dickins and Andrew Morton. Use fault_in_pages_writeable() for pre-faulting user's stack. [ bigeasy: Write commit message. ] [ bp: Massage some. ] ¹ https://lkml.kernel.org/r/1557844195-18882-1-git-send-email-rppt@linux.ibm.com Fixes: d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: linux-mm <linux-mm@kvack.org> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Rik van Riel <riel@surriel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190529072540.g46j4kfeae37a3iu@linutronix.de Link: https://lkml.kernel.org/r/1557844195-18882-1-git-send-email-rppt@linux.ibm.com
2019-06-06arm64: dts: renesas: Add HiHope RZ/G2M sub board supportBiju Das4-0/+73
The HiHope RZ/G2M sub board sits below the HiHope RZ/G2M main board. This patch also adds ethernet support along with a dtsi common to both HiHope RZ/G2M and RZ/G2N sub boards. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: hihope-common: Add pincontrol support to scif2/scif clockBiju Das1-0/+18
This patch adds pincontrol support to scif2/scif clock. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: Add HiHope RZ/G2M main board supportBiju Das3-0/+60
Basic support for the HiHope RZ/G2M main board: - Memory, - Main crystal, - Serial console This patch also includes a dtsi common to both HiHope RZ/G2M and RZ/G2N main boards. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: Silence gcc warnings about arch ABI driftDave Martin1-0/+1
Since GCC 9, the compiler warns about evolution of the platform-specific ABI, in particular relating for the marshaling of certain structures involving bitfields. The kernel is a standalone binary, and of course nobody would be so stupid as to expose structs containing bitfields as function arguments in ABI. (Passing a pointer to such a struct, however inadvisable, should be unaffected by this change. perf and various drivers rely on that.) So these warnings do more harm than good: turn them off. We may miss warnings about future ABI drift, but that's too bad. Future ABI breaks of this class will have to be debugged and fixed the traditional way unless the compiler evolves finer-grained diagnostics. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-06parisc: Fix crash due alternative coding for NP iopdir_fdc bitHelge Deller1-1/+2
According to the found documentation, data cache flushes and sync instructions are needed on the PCX-U+ (PA8200, e.g. C200/C240) platforms, while PCX-W (PA8500, e.g. C360) platforms aparently don't need those flushes when changing the IO PDIR data structures. We have no documentation for PCX-W+ (PA8600) and PCX-W2 (PA8700) CPUs, but Carlo Pisani reported that his C3600 machine (PA8600, PCX-W+) fails when the fdc instructions were removed. His firmware didn't set the NIOP bit, so one may assume it's a firmware bug since other C3750 machines had the bit set. Even if documentation (as mentioned above) states that PCX-W (PA8500, e.g. J5000) does not need fdc flushes, Sven could show that an Adaptec 29320A PCI-X SCSI controller reliably failed on a dd command during the first five minutes in his J5000 when fdc flushes were missing. Going forward, we will now NOT replace the fdc and sync assembler instructions by NOPS if: a) the NP iopdir_fdc bit was set by firmware, or b) we find a CPU up to and including a PCX-W+ (PA8600). This fixes the HPMC crashes on a C240 and C36XX machines. For other machines we rely on the firmware to set the bit when needed. In case one finds HPMC issues, people could try to boot their machines with the "no-alternatives" kernel option to turn off any alternative patching. Reported-by: Sven Schnelle <svens@stackframe.org> Reported-by: Carlo Pisani <carlojpisani@gmail.com> Tested-by: Sven Schnelle <svens@stackframe.org> Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure") Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # 5.0+
2019-06-06parisc: Use lpa instruction to load physical addresses in driver codeJohn David Anglin1-0/+24
Most I/O in the kernel is done using the kernel offset mapping. However, there is one API that uses aliased kernel address ranges: > The final category of APIs is for I/O to deliberately aliased address > ranges inside the kernel. Such aliases are set up by use of the > vmap/vmalloc API. Since kernel I/O goes via physical pages, the I/O > subsystem assumes that the user mapping and kernel offset mapping are > the only aliases. This isn't true for vmap aliases, so anything in > the kernel trying to do I/O to vmap areas must manually manage > coherency. It must do this by flushing the vmap range before doing > I/O and invalidating it after the I/O returns. For this reason, we should use the hardware lpa instruction to load the physical address of kernel virtual addresses in the driver code. I believe we only use the vmap/vmalloc API with old PA 1.x processors which don't have a sba, so we don't hit this problem. Tested on c3750, c8000 and rp3440. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de>
2019-06-06parisc: configs: Remove useless UEVENT_HELPER_PATHKrzysztof Kozlowski7-7/+0
Remove the CONFIG_UEVENT_HELPER_PATH because: 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was made default to 'n', 2. It is not recommended (help message: "This should not be used today [...] creates a high system load") and was kept only for ancient userland, 3. Certain userland specifically requests it to be disabled (systemd README: "Legacy hotplug slows down the system and confuses udev"). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Helge Deller <deller@gmx.de>
2019-06-06ARM: dts: sun8i: r40: Change the RTC compatibleMaxime Ripard1-2/+1
Unlike what's being reported in the device tree so far, the RTC in the R40 is quite different from the H3. Indeed it doesn't have the internal oscillator output, and it has only a single interrupt. Let's add a compatible for it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun8i: v3s: Add external crystals accuracyMaxime Ripard1-0/+2
The V3s datasheet mandates oscillators accuracy to be within 50ppm. Let's add that accuracy to their device tree nodes. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun8i: v3s: Fix the RTC nodeMaxime Ripard1-4/+7
For some reason, while the v3s has a dedicated compatible in the RTC binding, the one actually used was the A31's. However, it turns out that the controller is pretty different (which justified the compatible). Let's use the proper compatible, and use the proper binding description as well. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun6i: Add external crystals accuracyMaxime Ripard1-0/+2
The A31 datasheet mandates oscillators accuracy to be within 50ppm. Let's add that accuracy to their device tree nodes. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: sun6i: Fix RTC nodeMaxime Ripard1-6/+9
The RTC node doesn't match what is described in the binding for historical reasons. Let's add the proper description. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-06-06ARM: dts: rockchip: Split GPIO keys for veyron into multiple devicesMatthias Kaehlcke4-33/+38
With a single device DT overrides can become messy, especially when keys are added or removed. Multiple devices also allow to enable/disable wakeup per key/group. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> [used actual switch+event constants in new lid-switch entry] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Add HDMI i2c unwedging for rk3288-veyronDouglas Anderson1-1/+2
Veyron uses the builtin i2c controller that's part of dw-hdmi. Hook up the unwedging feature. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Add unwedge pinctrl entries for dw_hdmi on rk3288Douglas Anderson1-0/+9
This adds the "unwedge" pinctrl entries introduced by a recent dw_hdmi change that can unwedge the dw_hdmi i2c bus in some cases. It's expected that any boards using this would add: pinctrl-names = "default", "unwedge"; pinctrl-0 = <&hdmi_ddc>; pinctrl-1 = <&hdmi_ddc_unwedge>; Note that this isn't added by default because some boards may choose to mux i2c5 for their DDC bus (if that is more tested for them). Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM: dts: rockchip: Switch to builtin HDMI DDC bus on rk3288-veyronDouglas Anderson1-9/+2
Downstream Chrome OS kernels use the builtin DDC bus from dw_hdmi on veyron. This is the only way to get them to negotiate HDCP. Although HDCP isn't currently all supported upstream, it still seems like it makes sense to use dw_hdmi's builtin I2C. Maybe eventually we can get HDCP negotiation working. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-06-06ARM64: trivial: s/TIF_SECOMP/TIF_SECCOMP/ comment typo fixGeorge G. Davis1-1/+1
Fix a s/TIF_SECOMP/TIF_SECCOMP/ comment typo Cc: Jiri Kosina <trivial@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-06arm64: dts: renesas: r8a774a1: Add operating pointsFabrizio Castro1-0/+48
The RZ/G2M (a.k.a. r8a774a1) comes with two clusters of processors, similarly to the r8a7796. The first cluster is made of A57s, the second cluster is made of A53s. The operating points for the cluster with the A57s are: Frequency | Voltage -----------|--------- 500 MHz | 0.82V 1.0 GHz | 0.82V 1.5 GHz | 0.82V The operating points for the cluster with the A53s are: Frequency | Voltage -----------|--------- 800 MHz | 0.82V 1.0 GHz | 0.82V 1.2 GHz | 0.82V This patch adds the definitions for the operating points to the SoC specific DT. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77990: Add dynamic power coefficientSimon Horman1-0/+1
Describe the dynamic power coefficient of A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77990: Create thermal zone to support IPADien Pham1-3/+16
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. A single cooling device is described for all A53 CPUs as this reflects that physically there is only one cooling device present. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77965: Add dynamic power coefficientSimon Horman1-0/+1
Describe the dynamic power coefficient of A57 and A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a77965: Create thermal zone to support IPADien Pham1-0/+19
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel (on H3/M3/M3N SoCs, it is channel THS3). Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. The A57 cooling device supports 5 cooling states which can be categorised as follows: 0 & 1) boost (clocking up) 2) default 3 & 4) cooling (clocking down) Currently the thermal framework assumes that the default is the minimum, or in other words there is no provision for handling boost states. So this patch only describes the upper 3 states, default and cooling. A single cooling device is described for all A57 CPUs and a separate cooling device is described for all A53 CPUs. This reflects that physically there is only one cooling device present for each type of CPU. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Using cooling-device indexes such that maximum refers to maximum cooling rather than the inverse. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: An Huynh <an.huynh.uj@rvc.renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a7796: Add dynamic power coefficientSimon Horman1-0/+2
Describe the dynamic power coefficient of A57 and A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a7796: Create thermal zone to support IPADien Pham1-29/+15
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel (on H3/M3/M3N SoCs, it is channel THS3). Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. The A57 cooling device supports 5 cooling states which can be categorised as follows: 0 & 1) boost (clocking up) 2) default 3 & 4) cooling (clocking down) Currently the thermal framework assumes that the default is the minimum, or in other words there is no provision for handling boost states. So this patch only describes the upper 3 states, default and cooling. A single cooling device is described for all A57 CPUs and a separate cooling device is described for all A53 CPUs. This reflects that physically there is only one cooling device present for each type of CPU. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Using cooling-device indexes such that maximum refers to maximum cooling rather than the inverse. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Hien Dang <hien.dang.eb@rvc.renesas.com> Signed-off-by: An Huynh <an.huynh.uj@rvc.renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a7795: Add dynamic power coefficientSimon Horman1-0/+2
Describe the dynamic power coefficient of A57 and A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a7795: Create thermal zone to support IPADien Pham1-37/+15
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. In R-Car Gen3, IPA is supported for only one channel (on H3/M3/M3N SoCs, it is channel THS3). Reason: Currently, IPA controls base on only CPU temperature. And only one thermal channel is assembled closest CPU cores is selected as target of IPA. If other channels are used, IPA controlling is not properly. The A5 cooling device supports 5 cooling states which can be categorised as follows: 0 & 1) boost (clocking up) 2) default 3 & 4) cooling (clocking down) Currently the thermal framework assumes that the default is the minimum, or in other words there is no provision for handling boost states. So this patch only describes the upper 3 states, default and cooling. A single cooling device is described for all A57 CPUs and a separate cooling device is described for all A53 CPUs. This reflects that physically there is only one cooling device present for each type of CPU. This patch improves on an earlier version by: * Omitting cooling-max-level and cooling-min-level properties which are no longer present in mainline as of v4.17 * Removing an unused trip-point0 node sub-property from the trips property. * Using cooling-device indexes such that maximum refers to maximum cooling rather than the inverse. * Defers adding dynamic-power-coefficient properties to a separate patch as these are properties of the CPU. The long signed-off by chain below reflects many revisions, mainly internal, that this patch has been through. Signed-off-by: Dien Pham <dien.pham.ry@renesas.com> Signed-off-by: Keita Kobayashi <keita.kobayashi.ym@renesas.com> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> Signed-off-by: Hien Dang <hien.dang.eb@rvc.renesas.com> Signed-off-by: An Huynh <an.huynh.uj@rvc.renesas.com> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: Revise usb2_phy nodes and phys propertiesYoshihiro Shimoda7-47/+47
Since the commit 233da2c9ec22 ("dt-bindings: phy: rcar-gen3-phy-usb2: Revise #phy-cells property") revised the #phy-cells, this patch follows the updated document for R-Car Gen3 and RZ/A2 SoCs. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: ebisu: Remove renesas, no-ether-link propertyTakeshi Kihara1-1/+0
It is incorrect to specify the no-ether-link property for the AVB device on the Ebisu board. This is because the property should only be used when a board does not provide a proper AVB_LINK signal. However, the Ebisu board does provide this signal. As per 87c059e9c39d ("arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property") this fixes a bug: Steps to reproduce: - start AVB TX stream (Using aplay via MSE), - disconnect+reconnect the eth cable, - after a reconnection the eth connection goes iteratively up/down without user interaction, - this may heal after some seconds or even stay for minutes. As the documentation specifies, the "renesas,no-ether-link" option should be used when a board does not provide a proper AVB_LINK signal. There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS and ULCB starter kits since the AVB_LINK is correctly handled by HW. Choosing to keep or remove the "renesas,no-ether-link" option will have impact on the code flow in the following ways: - keeping this option enabled may lead to unexpected behavior since the RX & TX are enabled/disabled directly from adjust_link function without any HW interrogation, - removing this option, the RX & TX will only be enabled/disabled after HW interrogation. The HW check is made through the LMON pin in PSR register which specifies AVB_LINK signal value (0 - at low level; 1 - at high level). In conclusion, the present change is also a safety improvement because it removes the "renesas,no-ether-link" option leading to a proper way of detecting the link state based on HW interrogation and not on software heuristic. Fixes: 8441ef643d7d ("arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB") Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> [simon: updated changelog] Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: r8a774c0: Clean up CPU compatiblesRobin Murphy1-2/+2
Apparently this DTS crossed over with commit 31af04cd60d3 ("arm64: dts: Remove inconsistent use of 'arm,armv8' compatible string") and missed out on the cleanup, so put it right. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06arm64: dts: renesas: Use ip=on for bootargsMagnus Damm6-6/+6
Convert bootargs from ip=dhcp to ip=on Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-06x86/CPU: Add more Icelake model numbersKan Liang1-0/+3
Add the CPUID model numbers of Icelake (ICL) desktop and server processors to the Intel family list. [ Qiuxu: Sort the macros by model number. ] Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Cc: rui.zhang@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/20190603134122.13853-1-kan.liang@linux.intel.com
2019-06-06crypto: arm64/sha2-ce - correct digest for empty data in finupElena Petrova1-1/+1
The sha256-ce finup implementation for ARM64 produces wrong digest for empty input (len=0). Expected: the actual digest, result: initial value of SHA internal state. The error is in sha256_ce_finup: for empty data `finalize` will be 1, so the code is relying on sha2_ce_transform to make the final round. However, in sha256_base_do_update, the block function will not be called when len == 0. Fix it by setting finalize to 0 if data is empty. Fixes: 03802f6a80b3a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer") Cc: stable@vger.kernel.org Signed-off-by: Elena Petrova <lenaptr@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-06-06crypto: arm64/sha1-ce - correct digest for empty data in finupElena Petrova1-1/+1
The sha1-ce finup implementation for ARM64 produces wrong digest for empty input (len=0). Expected: da39a3ee..., result: 67452301... (initial value of SHA internal state). The error is in sha1_ce_finup: for empty data `finalize` will be 1, so the code is relying on sha1_ce_transform to make the final round. However, in sha1_base_do_update, the block function will not be called when len == 0. Fix it by setting finalize to 0 if data is empty. Fixes: 07eb54d306f4 ("crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer") Cc: stable@vger.kernel.org Signed-off-by: Elena Petrova <lenaptr@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-06-06arm64: dts: imx8mm: Move gic node into soc nodeAnson Huang1-9/+9
GIC is inside of SoC from architecture perspective, it should be located inside of soc node in DT. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-06ARM: imx6: cpuidle: Use raw_spinlock_tSebastian Andrzej Siewior1-5/+5
The idle call back is invoked with disabled interrupts and requires raw_spinlock_t locks to work. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-05arm64: ptrace: add support for syscall emulationSudeep Holla2-2/+9
Add PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support on arm64. We don't need any special handling for PTRACE_SYSEMU_SINGLESTEP. It's quite difficult to generalize handling PTRACE_SYSEMU cross architectures and avoid calls to tracehook_report_syscall_entry twice. Different architecture have different mechanism to indicate NO_SYSCALL and trying to generalise adds more code for no gain. Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-05arm64: add PTRACE_SYSEMU{,SINGLESTEP} definations to uapi headersSudeep Holla1-0/+3
x86 and um use 31 and 32 for PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP while powerpc uses different value maybe for legacy reasons. Though handling of PTRACE_SYSEMU can be made architecture independent, it's hard to make these definations generic. To add to this existing mess few architectures like arm, c6x and sh use 31 for PTRACE_GETFDPIC (get the ELF fdpic loadmap address). It's not possible to move the definations to generic headers. So we unfortunately have to duplicate the same defination to ARM64 if we need to support PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP. Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-05ptrace: move clearing of TIF_SYSCALL_EMU flag to coreSudeep Holla2-4/+0
While the TIF_SYSCALL_EMU is set in ptrace_resume independent of any architecture, currently only powerpc and x86 unset the TIF_SYSCALL_EMU flag in ptrace_disable which gets called from ptrace_detach. Let's move the clearing of TIF_SYSCALL_EMU flag to __ptrace_unlink which gets executed from ptrace_detach and also keep it along with or close to clearing of TIF_SYSCALL_TRACE. Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 449Thomas Gleixner1-3/+1
Based on 1 normalized pattern(s): this file is licensed under the terms of the gnu general public license version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 1 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190116.254216506@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 445Thomas Gleixner13-117/+13
Based on 1 normalized pattern(s): this program is free software you can distribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 24 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.872212424@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441Thomas Gleixner94-471/+94
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 315 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 437Thomas Gleixner2-4/+2
Based on 1 normalized pattern(s): this file is licensed under gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 22 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.129548190@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 430Thomas Gleixner7-12/+9
Based on 1 normalized pattern(s): distribute under gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 8 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.475576622@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 429Thomas Gleixner1-2/+1
Based on 1 normalized pattern(s): this code is licenced under the gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 1 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.383521217@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 428Thomas Gleixner9-18/+9
Based on 1 normalized pattern(s): this file is released under the gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 68 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 422Thomas Gleixner15-60/+15
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 101 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190113.822954939@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 419Thomas Gleixner9-36/+9
Based on 1 normalized pattern(s): this is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 9 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190113.515971893@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>