| Age | Commit message (Collapse) | Author |
|---|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into next/dt
Pull "Amlogic 64-bit DT updates for v4.17" from Kevin Hilman:
- AXG: add/enable UART_A, I2C, RMII, system controller, HW RNG
- accept MAC from u-boot environment
- misc. fixes
* tag 'amlogic-dt64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
ARM64: dts: meson-gx: make efuse read-only
ARM64: dts: meson: bump mali450 clk to 744MHz
meson-gx-socinfo: Add package id for S905H
ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2
ARM64: dts: meson: reduce odroid-c2 eMMC maximum rate
ARM64: dts: amlogic: Convert to new-style SPDX license identifiers
ARM64: dts: meson-axg: fix pwm_AO_cd compatible
ARM64: dts: meson-axg: add sec_AO system controller
ARM64: dts: meson: accept MAC addr from u-boot environment
ARM64: dts: meson s905x: accept MAC addr from u-boot environment
ARM64: dts: meson-axg: enable the UART_A controller
ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
ARM64: dts: meson-axg: uart: Add the pinctrl info description
ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
ARM64: dts: meson-axg: add RMII pins for ethernet controller
ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker
ARM64: dts: meson-axg: describe pin DT info for I2C controller
ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
ARM64: meson-axg: enable hardware rng
|
|
next/dt
Pull "mvebu dt64 for 4.17 (part 2)" from Gregory CLEMENT:
- Add registers clock for all the peripheral nodes that had been yet
converted for CP110 (Armada 7K/8K)
- Document URL for schematic for the EspressoBin (Armada 3720)
* tag 'mvebu-dt64-4.17-2' of git://git.infradead.org/linux-mvebu:
arm64: dts: armada-3720-espressobin: Document URL for schematic
ARM64: dts: marvell: armada-cp110: Add registers clock for the PCIe nodes
ARM64: dts: marvell: armada-cp110: Add registers clock for the NAND node
ARM64: dts: marvell: armada-cp110: Add registers clock for the crypto node
ARM64: dts: marvell: armada-cp110: Add registers clock for the trng node
ARM64: dts: marvell: armada-cp110: Add registers clock for XOR engine nodes
ARM64: dts: marvell: armada-cp110: Add registers clock for USB host nodes
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/dt
Pull "ARM: mediatek: dts64 updates for v4.16-next" from Matthias Brugger:
- mt2712e add auxadc devcie
mt7622:
- fix clock bindings description
- add nodes for mmc, usb, SATA, PCI, ethernet, cpufreq, PMIC mt6380,
pinctrl, scpsys and clock devices
* tag 'v4.16-next-dts64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
arm64: dts: mt2712: Add auxadc device node.
dt-bindings: clock: mediatek: add missing required #reset-cells
arm64: dts: mt7622: add mmc related device nodes
arm64: dts: mt7622: add usb device nodes
arm64: dts: mt7622: add SATA device nodes
arm64: dts: mt7622: add PCIe device nodes
arm64: dts: mt7622: add ethernet device nodes
arm64: dts: mt7622: add flash related device nodes
arm64: dts: mt7622: add SoC and peripheral related device nodes
arm64: dts: mt7622: turn uart0 clock to real ones
arm64: dts: mt7622: add cpufreq related device nodes
arm64: dts: mt7622: add PMIC MT6380 related nodes
arm64: dts: mt7622: add pinctrl related device nodes
arm64: dts: mt7622: add power domain controller device nodes
arm64: dts: mt7622: add clock controller device nodes
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/dt
Pull "ARM: mediatek: dts32 updates for v4.16-next" from Matthias Brugger:
mt7623:
- fix style issues of the dts
- add cpu clock properties
- add PCI controller
- add mt7623 reference board
banapi-r2:
- enable missing uarts
- fix regulator for mmc
- fix USB initialization
* tag 'v4.16-next-dts32' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
arm: dts: mt7623: add PCIe related nodes
arm: dts: mt7623: use - instead of _ in DT node name
arm: dts: mt7623: remove useless property pinctrl-names at node switch@0
arm: dts: mt7623: add related clock properties to cpu[1-3] nodes
arm: dts: mt7623: enable three available UARTs on bananapi-r2
arm: dts: mt7623: fix the regulators mmc should use on bananapi-r2
arm: dts: mt7623: fix USB initialization fails on bananapi-r2
dt-bindings: arm: mediatek: add support for more mt7623 reference boards
|
|
We need linux/compiler.h for unreachable(), so #include it here.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
We want to avoid pulling linux/preempt.h into cmpxchg.h, since that can
introduce a circular dependency on linux/bitops.h. linux/preempt.h is
only needed by the per-cpu cmpxchg implementation, which is better off
alongside the per-cpu xchg implementation in percpu.h, so move it there
and add the missing #include.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Having asm/cmpxchg.h pull in linux/bug.h is problematic because this
ends up pulling in the atomic bitops which themselves may be built on
top of atomic.h and cmpxchg.h.
Instead, just include build_bug.h for the definition of BUILD_BUG.
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
When the LL/SC atomics are moved out-of-line, they are annotated as
notrace and exported to modules. Ensure we pull in the relevant include
files so that these macros are defined when we need them.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
fpsimd.h uses the __init annotation, so pull in linux/init.h
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/dt
Pull "Samsung DTS ARM changes for v4.17, part two" from Krzysztof Kozłowski:
1. Fix audio on Exynos5250 Chromebook Snow.
2. Enable HDMI audio Chromebook Snow, Peach Pit and Peach Pi.
3. Fix debounce of "OK" key on Midas (Trats2, Galaxy S3) boards.
* tag 'samsung-dt-4.17-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: exynos: Add #sound-dai-cells property to exynos5250 i2s nodes
ARM: dts: exynos: Fix "debounce-interval" property misspelling in Midas
ARM: dts: exynos: Enable HDMI audio support on Peach Pi
ARM: dts: exynos: Enable HDMI audio support on Peach Pit
ARM: dts: exynos: Enable HDMI audio on Snow Chromebook
ARM: dts: exynos: Add missing clock and DAI properties to the max98095 node in Snow Chromebook
ARM: dts: exynos: Add audio clocks configuration for Snow Chromebook
ARM: dts: exynos: Add #sound-dai-cells property to hdmi node in exynos5250.dtsi
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/dt
Pull "Renesas ARM Based SoC DT Updates for v4.17" from Simon Horman:
* Silk board with R-Car E2 (r8a7794) SoC
- Add r1ex24002 EEPROM to DT
Magnus Damm says "Extend the Silk board support to include U14 which is
an I2C based EEPROM hooked up to the I2C1 bus."
- Add GPIO keys to DT
Magnus Damm says "Extend the Silk board support to include SW3, SW4,
SW6 and SW12. They are all connected via GPIO lines and handled by the
gpio-keys driver"
* Marzen board with R-Car H1 (r7a7779) SoC
- Add SDHI0 VCCQ Regulator
Magnus Damm says "Add support for the on-board voltage regulator hooked
up to GPIO3_20 on r8a7779 Marzen. The board schematics describes the
regulator as U4 TPS2110A. Input wise, U4 has D0 fixed to ground, D1
tied to GPIO3_20 while IN1 is fixed to 3.3V and IN2 is fixed to 1.8V.
OUT goes to the pull-ups for the data pins of SDHI0."
* Porter board with R-Car M3W (r8a7791) SoC
- Fix HDMI output routing
Laurent Pinchart says "The HDMI encoder is connected to the RGB output
of the DU, which is port@0, not port@1."
* iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) and
iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
- Enable cmt0
* Stout board with R-Car H2 (r8a7790) SoC
- Initial support
* Lager board with R-Car H2 (r8a7790) SoC
- Add CEC clock for HDMI transmitter
Niklas Söderlund says "The adv7511 on the Lager board has a 12 MHz
fixed clock for the CEC block. Specify this in the dts to enable CEC
support."
- Move cec_clock to root node
By definition nodes without a bus address do not belong on the bus
* kzm9d board with EMMA Mobile EV2 (EMEV2) SoC
- Fix "debounce-interval" property misspelling
* RZ/G1M (r8a7743) and RZ/G1H (r8a7745) SoCs
- Add IPMMU DT nodes
- Add VSP support
* R-Car Gen2 boards
- Use I2C demuxer for
This allows run-time switching between alternate I2C IP blocks
* R-Car Gen2 and RZ/G1 SoCs
- Clean up DT files to ease future maintenance
+ add soc node for IP attached to the bus
+ sort subnodes of soc and root node
+ consistently use single space after =
* R-Car H2 (r8a7790), M3-W (r8a7791) and M3-N (r7a7793) SoCs
- Reduce size of thermal registers
According to the "User's Manual: Hardware" v2.00 the registers at base
0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the
case on the r8a73a4 (R-Mobile APE6).
This should not have any runtime affect as mapping granularity is
PAGE_SIZE.
* tag 'renesas-dt-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (47 commits)
ARM: dts: silk: Add GPIO keys to DT
ARM: dts: silk: Add r1ex24002 EEPROM to DT
ARM: dts: marzen: Add SDHI0 VCCQ Regulator
ARM: dts: stout: Initial r8a7790 Stout board support
ARM: dts: lager: Move cec_clock to root node
ARM: dts: kzm9d: Fix "debounce-interval" property misspelling
ARM: dts: gose: use demuxer for I2C4
ARM: dts: gose: use demuxer for I2C2
ARM: dts: silk: use demuxer for I2C1
ARM: dts: alt: use demuxer for I2C1
ARM: dts: porter: use demuxer for I2C2
ARM: dts: koelsch: use demuxer for I2C4
ARM: dts: koelsch: use demuxer for I2C2
ARM: dts: lager: use demuxer for IIC3/I2C3
ARM: dts: lager: use demuxer for IIC2/I2C2
ARM: dts: r8a7745: Add VSP support
ARM: dts: r8a7743: Add VSP support
ARM: dts: r8a7745: Add IPMMU DT nodes
ARM: dts: r8a7743: Add IPMMU DT nodes
ARM: dts: r8a7745: sort subnodes of soc node
...
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/dt
Pull "Renesas ARM64 Based SoC DT Updates for v4.17" from Simon Horman:
* R-Car Gen3 boards and SoCs
- Make phy-mode of EtherAVB a board-specific property.
The SoC DTs file now uses "rgmii" and boards override this with
"rgmii-txid" as appropriate. Previously "rgmii-txid" was used
in SoC DTs but this did not describe that more sophiticated
functionality is a board rather than SoC property.
* Condor board with R-Car V3H (r8a77980) SoC
- Initial upstream support
* Condor board with R-Car V3H (r8a77980) SoC
- Initial upstream support
* R-Car D3 (r8a77995)
- Add I2C nodes and then describing the PCA9654 I/O expander connected to
the I2C0 bus.
* Eagle board with R-Car V3M (r8a77970) SoC
- Enable PFC support for configuring SCIF0 pins
This uses PFC support added to the V3M DT
- Describe EtherAVB PHY IRQ
This uses support for GPIO added to the V3M DT
- Enable I2C0 support
Sergei Shtylyov says "The I2C0 bus is populated by ON Semiconductor
PCA9653 I/O expander and Analog Devices ADV7511W HDMI transmitter (but
we're only describing the former chip now)."
* R-Car V3M (r8a77970) SoCs
- Add PFC support
- Describe GPIO devices
- Describe I2C devices
- Srt subnodes of root node alphabetically to eas future maintence overhead
* Draak board with R-Car D3 (r8a77995) SoC
- Enable SDHI2
Wolfram Sang says "The single SDHI controller is connected to eMMC."
- Enable DU
Kieran Bingham says "Enable the DU, providing only the VGA output for
now."
* R-Car D3 (r8a77995) and V3M (r8a77970) SoCs
- Move nodes which have no reg property out of bus
By deffinition the bus only has hardware with an address on the bus
- Remove non-existing STBE region from EtherAVB
Stream Buffer for EtherAVB-IF (STBE) is not present on these SoCs
* R-Car D3 (r8a77995) SoC
- Add FCPV, VSP and DU support
Kieran Bingham says "The r8a77995-d3 platform supports 3 VSP instances.
One VSPBS can be used as a dual-input image blender, while two VSPD
instances can be utilised as part of a display (DU) pipeline.
Add support for these, along with their required FCPV nodes."
* Salvator-X and Salvator-XS boards with R-Car Gen3 SoCs
- Add GPIO extender
This is a basis for follow-up work to configure the GPIOs of the extender
* Salvator-X and Salvator-XS board with R-Car M3-N (r8a77965) SoC
- Initial upstream support
* R-Car H3 (r8a7795) and M3-W (r8a7796) SoCs
- Add OPPs table for cpu devices
This, along with recently upstreamed Z and Z2 clock support allows
use of CPUFreq with both A57 and A53 CPUs.
- Add thermal cooling management
Allows the use of CPUFreq as a cooling device on A57 CPUs
- Correct register size of thermal node
Niklas Söderlund says "To be able to read fused calibration values from
hardware the size of the register resource of TSC1 needs to be
incremented to cover one more register which holds the information if
the calibration values have been fused or not.
Instead of increasing TSC1 size to the value from the datasheet update
all TSC's size to the smallest granularity of the address decoder
circuitry"
- Fix register mappings on VSPs
Kieran Bingham says "The VSPD includes a CLUT on RPF2. Ensure that the
register space is mapped correctly to support this."
* R-Car H3 (r8a7795) SoC
- Move SCIF node into alphabetical order to ease future maintenance overhead
- Add IPMMU-PV1 device node
This resolves an oversight when IPMMU nodes were added to the H3 DT.
All IPMMU devices should now be described in DT.
- Add missing SYS-DMAC2 dmas
Geert Uytterhoeven says "On R-Car H3, on-chip peripheral modules that
can make use of DMA are wired to either SYS-DMAC0 only, or to both
SYS-DMAC1 and SYS-DMAC2.
Add the missing DMA properties pointing to SYS-DMAC2 for HSCIF[0-2],
SCIF[0125], and I2C[0-2]. These were initially left out because early
firmware versions prohibited using SYS-DMAC2. This restriction has
been lifted in IPL and Secure Monitor Rev1.0.6 (released on Feb 25,
2016)."
* tag 'renesas-arm64-dt-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (69 commits)
arm64: dts: renesas: v3msk: add SCIF0 pins
arm64: dts: renesas: r8a7795: Add missing SYS-DMAC2 dmas
arm64: dts: renesas: r8a7795: Add IPMMU-PV1 device node
arm64: dts: renesas: r8a77970: sort subnodes of root node alphabetically
arm64: dts: renesas: eagle: add I2C0 support
arm64: dts: renesas: r8a77970: add I2C support
arm64: dts: renesas: r8a77965-salvator-xs: Add SoC name to file header
arm64: dts: renesas: r8a77965: Add EtherAVB device node
arm64: dts: renesas: r8a77970: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"
arm64: dts: renesas: v3msk: Override EtherAVB phy-mode
arm64: dts: renesas: eagle: Override EtherAVB phy-mode
arm64: dts: renesas: draak: Override EtherAVB phy-mode
arm64: dts: renesas: ulcb: Override EtherAVB phy-mode
arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode
arm64: dts: renesas: r8a77965: Add INTC-EX device node
arm64: dts: renesas: r8a77965: Add IIC-DVFS device node
arm64: dts: renesas: Add support for Salvator-XS with R-Car M3-N
...
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/dt
Pull "arm64: tegra: Device tree changes for v4.17-rc1" from Thierry Reding:
Adds initial support for the P2972-0000 development board based on
Tegra194 and enables the AHCI controller on Jetson TX1.
* tag 'tegra-for-4.17-arm64-dt' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Enable AHCI on Jetson TX1
arm64: tegra: Add SATA node for Tegra210
arm64: tegra: Add device tree for the Tegra194 P2972-0000 board
arm64: tegra: Add Tegra194 chip device tree
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/dt
Pull "ARM: tegra: Device tree changes for v4.17-rc1" from Thierry Reding:
Support for the VDE is added on Tegra30 along with some general cleanup
and some improvements to the various Toradex boards.
* tag 'tegra-for-4.17-arm-dt' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: apalis-tk1: Support v1.2 hardware revision
ARM: tegra: apalis-tk1: Copyright period, spurious newlines
ARM: tegra: apalis-tk1: Hog group for ethernet, PCIe, reset GPIOs
ARM: tegra: apalis-tk1: Add missing as3722 gpio0 configuration
ARM: tegra: apalis-tk1: Activate PWM pin muxing for pwm3
ARM: tegra: apalis-tk1: Set critical trips
ARM: tegra: apalis/colibri: Remove unneeded reg property
ARM: tegra: apalis/colibri: Use correct compatible for RTC
ARM: tegra: Fix I2C bus frequencies on Apalis/Colibri
ARM: tegra: venice2: Remove duplicate pcie-1 node
ARM: tegra: beaver: Remove invalid uses of rsvd1
ARM: tegra: Use proper IRQ type definitions
ARM: tegra: Fix ULPI regression on Tegra20
ARM: tegra: Add unit address to VDE IRAM area
ARM: tegra: Add video decoder node on Tegra30
ARM: tegra: Add IRAM node on Tegra30
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
Pull "Allwinner Fixes for 4.16" from Maxime Ripard:
The first and second patches fix the regulator support for the Bananapi M2
board.
The last one updates my email address in MAINTAINERS.
* tag 'sunxi-fixes-for-4.16' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
MAINTAINERS: update email address for Maxime Ripard
ARM: dts: sun6i: a31s: bpi-m2: add missing regulators
ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Pull "Two fixes for omap variants for v4.16-rc cycle" from Tony Lindgren:
Fix insecure W+X mapping warning for SRAM for omaps that
don't yet use drivers/misc/*sram*.c code. An earlier attempt
at fixing this turned out to cause problems with PM on omap3,
this version works with PM on omap3.
Also fix dmtimer probe for omap16xx devices that was noticed
with the pending dmtimer move to drivers. It seems this has
been broken for a while and is a non-critical for booting.
It is needed for PM on omap16xx though.
* tag 'omap-for-v4.16/sram-fix-signed' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: Fix SRAM W+X mapping
ARM: OMAP: Fix dmtimer init for omap1
|
|
This reverts commit 1f85b42a691cd8329ba82dbcaeec80ac1231b32a.
The internal dma-direct.h API has changed in -next, which collides with
us trying to use it to manage non-coherent DMA devices on systems with
unreasonably large cache writeback granules.
This isn't at all trivial to resolve, so revert our changes for now and
we can revisit this after the merge window. Effectively, this just
restores our behaviour back to that of 4.16.
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
An allnoconfig build complains about unused symbols due to functions
that are called via conditional cpufeature and cpu_errata table entries.
Annotate these as __maybe_unused if they are likely to be generic, or
predicate their compilation on the same option as the table entry if
they are specific to a given alternative.
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
High latencies can be observed caused by a daemon periodically reading
CPUID on all cpus. On KASAN enabled kernels ~10ms latencies can be
observed. Even without KASAN, sending an IPI to a CPU, which is in a deep
sleep state or in a long hard IRQ disabled section, waiting for the answer
can consume hundreds of microseconds.
cpuid_read() is invoked in preemptible context, so it can be converted to
sleep instead of busy wait.
Switching to smp_call_function_single_async() and a completion allows to
reschedule and reduces CPU usage and latencies.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Link: https://lkml.kernel.org/r/20180323215818.127774-2-edumazet@google.com
|
|
High latencies can be observed caused by a daemon periodically reading
various MSR on all cpus. On KASAN enabled kernels ~10ms latencies can be
observed simply reading one MSR. Even without KASAN, sending an IPI to a
CPU, which is in a deep sleep state or in a long hard IRQ disabled section,
waiting for the answer can consume hundreds of microseconds.
All usage sites are in preemptible context, convert rdmsr_safe_on_cpu() to
use a completion instead of busy polling.
Overall daemon cpu usage was reduced by 35 %, and latencies caused by
msr_read() disappeared.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Link: https://lkml.kernel.org/r/20180323215818.127774-1-edumazet@google.com
|
|
As Kai pointed out, the primary reason for adjusting x86_phys_bits is to
reflect that the the address space is reduced and not the ability to
communicate the available physical address space to virtual machines.
Suggested-by: Kai Huang <kai.huang@linux.intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: linux-mm@kvack.org
Link: https://lkml.kernel.org/r/20180315134907.9311-2-kirill.shutemov@linux.intel.com
|
|
dmi_get_bios_year() may return 0 when it cannot parse
the BIOS date string. Previously this has been checked in
pci_acpi_crs_quirks().
Update the code to restore old behaviour.
Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J . Wysocki <rjw@rjwysocki.net>
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Fixes: 69c42d493db4 ("x86/pci: Simplify code by using the new dmi_get_bios_year() helper")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Currently the rfi-flush messages print 'Using <type> flush' for all
enabled_flush_types, but that is not necessarily true -- as now the
fallback flush is always enabled on pseries, but the fixup function
overwrites its nop/branch slot with other flush types, if available.
So, replace the 'Using <type> flush' messages with '<type> flush is
available'.
Also, print the patched flush types in the fixup function, so users
can know what is (not) being used (e.g., the slower, fallback flush,
or no flush type at all if flush is disabled via the debugfs switch).
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This ensures the fallback flush area is always allocated on pseries,
so in case a LPAR is migrated from a patched to an unpatched system,
it is possible to enable the fallback flush in the target system.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area after memblock has gone away (i.e., boot-time only).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
rfi_flush_enable() includes a check to see if we're already
enabled (or disabled), and in that case does nothing.
But that means calling setup_rfi_flush() a 2nd time doesn't actually
work, which is a bit confusing.
Move that check into the debugfs code, where it really belongs.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
These events either do not count, or do not count correctly, so to
prevent user confusion block counting them at all.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[mpe: Change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
These events either do not count, or do not count correctly, so to
prevent user confusion block counting them at all.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[mpe: Change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Introduce code to support addition of blacklisted events for a
processor version. Blacklisted events are events that are known to not
count correctly on that CPU revision, and so should be prevented from
being counted so as to avoid user confusion.
A 'pointer' and 'int' variable to hold the number of events are added
to 'struct power_pmu', along with a generic function to loop through
the list to validate the given event. Generic function
'is_event_blacklisted' is called in power_pmu_event_init() to detect
and reject early.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Sampled Data Address Register (SDAR) is a 64-bit register that
contains the effective address of the storage operand of an
instruction that was being executed, possibly out-of-order, at or
around the time that the Performance Monitor alert occurred.
In certain scenario SDAR happen to contain the kernel address even for
userspace only sampling. Add checks to prevent it.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
The current Branch History Rolling Buffer (BHRB) code does not check
for any privilege levels before updating the data from BHRB. This
could leak kernel addresses to userspace even when profiling only with
userspace privileges. Add proper checks to prevent it.
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Current code in power_pmu_disable() does not clear the sampling
registers like Sampling Instruction Address Register (SIAR) and
Sampling Data Address Register (SDAR) after disabling the PMU. Since
these are userspace readable and could contain kernel addresses, add
code to explicitly clear the content of these registers.
Also add a "context synchronizing instruction" to enforce no further
updates to these registers as suggested by Power ISA v3.0B. From
section 9.4, on page 1108:
"If an mtspr instruction is executed that changes the value of a
Performance Monitor register other than SIAR, SDAR, and SIER, the
change is not guaranteed to have taken effect until after a
subsequent context synchronizing instruction has been executed (see
Chapter 11. "Synchronization Requirements for Context Alterations"
on page 1133)."
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[mpe: Massage change log and add ISA reference]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
On POWER9, since commit cc3d2940133d ("powerpc/64: Enable use of radix
MMU under hypervisor on POWER9", 2017-01-30), we set both the radix and
HPT bits in the client-architecture-support (CAS) vector, which tells
the hypervisor that we can do either radix or HPT. According to PAPR,
if we use this combination we are promising to do a H_REGISTER_PROC_TBL
hcall later on to let the hypervisor know whether we are doing radix
or HPT. We currently do this call if we are doing radix but not if
we are doing HPT. If the hypervisor is able to support both radix
and HPT guests, it would be entitled to defer allocation of the HPT
until the H_REGISTER_PROC_TBL call, and to fail any attempts to create
HPTEs until the H_REGISTER_PROC_TBL call. Thus we need to do a
H_REGISTER_PROC_TBL call when we are doing HPT; otherwise we may
crash at boot time.
This adds the code to call H_REGISTER_PROC_TBL in this case, before
we attempt to create any HPT entries using H_ENTER.
Fixes: cc3d2940133d ("powerpc/64: Enable use of radix MMU under hypervisor on POWER9")
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This reverts commit f81d7af7957539b7808961f929f945381530acb9.
As explained by Rob Herring:
"This "fix" is wrong. Memory controllers with chip selects should have
the chip select in the unit-address. The correct fix here is you should
drop "simple-bus"."
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The file Documentation/x86/early-microcode.txt was renamed to
Documentation/x86/microcode.txt in 0e3258753f81, but it was still
referenced by its old name in a three places:
* Documentation/x86/00-INDEX
* arch/x86/Kconfig
* arch/x86/kernel/cpu/microcode/amd.c
This commit updates these references accordingly.
Fixes: 0e3258753f81 ("x86/microcode: Document the three loading methods")
Signed-off-by: Jaak Ristioja <jaak@ristioja.ee>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The following pattern fails to compile while the same pattern
with alternative_call() does:
if (...)
alternative_call_2(...);
else
alternative_call_2(...);
as it expands into
if (...)
{
}; <===
else
{
};
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20180114120504.GA11368@avx2
|
|
CONFIG_NEED_NODE_MEMMAP_SIZE logic
node_memmap_size_bytes() has been unused since the v3.9 kernel, so remove it.
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Fixes: f03574f2d5b2 ("x86-32, mm: Rip out x86_32 NUMA remapping code")
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1803262325540.256524@chino.kir.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Conflicts:
arch/x86/mm/init_64.c
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
this patch fix a bug in how the pebs->real_ip is handled in the PEBS
handler. real_ip only exists in Haswell and later processor. It is
actually the eventing IP, i.e., where the event occurred. As opposed
to the pebs->ip which is the PEBS interrupt IP which is always off
by one.
The problem is that the real_ip just like the IP needs to be fixed up
because PEBS does not record all the machine state registers, and
in particular the code segement (cs). This is why we have the set_linear_ip()
function. The problem was that set_linear_ip() was only used on the pebs->ip
and not the pebs->real_ip.
We have profiles which ran into invalid callstacks because of this.
Here is an example:
..... 0: ffffffffffffff80 recent entry, marker kernel v
..... 1: 000000000040044d <= user address in kernel space!
..... 2: fffffffffffffe00 marker enter user v
..... 3: 000000000040044d
..... 4: 00000000004004b6 oldest entry
Debugging output in get_perf_callchain():
[ 857.769909] CALLCHAIN: CPU8 ip=40044d regs->cs=10 user_mode(regs)=0
The problem is that the kernel entry in 1: points to a user level
address. How can that be?
The reason is that with PEBS sampling the instruction that caused the event
to occur and the instruction where the CPU was when the interrupt was posted
may be far apart. And sometime during that time window, the privilege level may
change. This happens, for instance, when the PEBS sample is taken close to a
kernel entry point. Here PEBS, eventing IP (real_ip) captured a user level
instruction. But by the time the PMU interrupt fired, the processor had already
entered kernel space. This is why the debug output shows a user address with
user_mode() false.
The problem comes from PEBS not recording the code segment (cs) register.
The register is used in x86_64 to determine if executing in kernel vs user
space. This is okay because the kernel has a software workaround called
set_linear_ip(). But the issue in setup_pebs_sample_data() is that
set_linear_ip() is never called on the real_ip value when it is available
(Haswell and later) and precise_ip > 1.
This patch fixes this problem and eliminates the callchain discrepancy.
The patch restructures the code around set_linear_ip() to minimize the number
of times the IP has to be set.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: kan.liang@intel.com
Link: http://lkml.kernel.org/r/1521788507-10231-1-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
No changes in refcount semantics -- use DEFINE_STATIC_KEY_FALSE()
for initialization and replace:
static_key_slow_inc|dec() => static_branch_inc|dec()
static_key_false() => static_branch_unlikely()
Added a '_key' suffix to rdpmc_always_available, for better self-documentation.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: akpm@linux-foundation.org
Link: http://lkml.kernel.org/r/20180326210929.5244-5-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to skip enabling the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected. There are some other cores suffering from this
errata, which could be added to the midr_list to trigger the work
around.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: ckadabi@codeaurora.org
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
We enable hardware DBM bit in a capable CPU, very early in the
boot via __cpu_setup. This doesn't give us a flexibility of
optionally disable the feature, as the clearing the bit
is a bit costly as the TLB can cache the settings. Instead,
we delay enabling the feature until the CPU is brought up
into the kernel. We use the feature capability mechanism
to handle it.
The hardware DBM is a non-conflicting feature. i.e, the kernel
can safely run with a mix of CPUs with some using the feature
and the others don't. So, it is safe for a late CPU to have
this capability and enable it, even if the active CPUs don't.
To get this handled properly by the infrastructure, we
unconditionally set the capability and only enable it
on CPUs which really have the feature. Also, we print the
feature detection from the "matches" call back to make sure
we don't mislead the user when none of the CPUs could use the
feature.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Update the MIDR encodings for the Cortex-A55 and Cortex-A35
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Some capabilities have different criteria for detection and associated
actions based on the matching criteria, even though they all share the
same capability bit. So far we have used multiple entries with the same
capability bit to handle this. This is prone to errors, as the
cpu_enable is invoked for each entry, irrespective of whether the
detection rule applies to the CPU or not. And also this complicates
other helpers, e.g, __this_cpu_has_cap.
This patch adds a wrapper entry to cover all the possible variations
of a capability by maintaining list of matches + cpu_enable callbacks.
To avoid complicating the prototypes for the "matches()", we use
arm64_cpu_capabilities maintain the list and we ignore all the other
fields except the matches & cpu_enable.
This ensures :
1) The capabilitiy is set when at least one of the entry detects
2) Action is only taken for the entries that "matches".
This avoids explicit checks in the cpu_enable() take some action.
The only constraint here is that, all the entries should have the
same "type" (i.e, scope and conflict rules).
If a cpu_enable() method is associated with multiple matches for a
single capability, care should be taken that either the match criteria
are mutually exclusive, or that the method is robust against being
called multiple times.
This also reverts the changes introduced by commit 67948af41f2e6818ed
("arm64: capabilities: Handle duplicate entries for a capability").
Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Add helpers for detecting an errata on list of midr ranges
of affected CPUs, with the same work around.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Add helpers for checking if the given CPU midr falls in a range
of variants/revisions for a given model.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
We are about to introduce generic MIDR range helpers. Clean
up the existing helpers in erratum handling, preparing them
to use generic version.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
We expect all CPUs to be running at the same EL inside the kernel
with or without VHE enabled and we have strict checks to ensure
that any mismatch triggers a kernel panic. If VHE is enabled,
we use the feature based on the boot CPU and all other CPUs
should follow. This makes it a perfect candidate for a capability
based on the boot CPU, which should be matched by all the CPUs
(both when is ON and OFF). This saves us some not-so-pretty
hooks and special code, just for verifying the conflict.
The patch also makes the VHE capability entry depend on
CONFIG_ARM64_VHE.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The kernel detects and uses some of the features based on the boot
CPU and expects that all the following CPUs conform to it. e.g,
with VHE and the boot CPU running at EL2, the kernel decides to
keep the kernel running at EL2. If another CPU is brought up without
this capability, we use custom hooks (via check_early_cpu_features())
to handle it. To handle such capabilities add support for detecting
and enabling capabilities based on the boot CPU.
A bit is added to indicate if the capability should be detected
early on the boot CPU. The infrastructure then ensures that such
capabilities are probed and "enabled" early on in the boot CPU
and, enabled on the subsequent CPUs.
Cc: Julien Thierry <julien.thierry@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
