Commit 9ccd608070 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Previously I attempted to resolve this by creating a shared location
for such things but we have been unable to come to a consensus on
where that should be.
Instead this patch simply replaces the use of ../../ in the dts
/include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
file arch/arm/boot/dts.
Since the split device tree repo will shortly be required to flatten
symlinks for other reasons this will cause the dtsi file to appear in
both src/arm and src/arm64 in the split repo, which is an improvement
on not building for arm64 now.
[0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Frank Rowand <frank.rowand@sonymobile.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: arm@kernel.org
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The DTS erronously uses the wrong reg mapping and IRQ numbers for some
UART, WDT and timer nodes. Fix this.
Reported-by: John Wehle <john@feith.com>
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
DT patches for the 4.4 merge window, most notably:
- Enable the OTG controller on more boards
- Create new DTSI for the q8's design
- Added RSB support to the A23 and A33 SoCs
- New boards: Olimex A20 EVB, Yones bs1078v2
Plus the usual random patches enabling and / or enhancing a few things in
particular boards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWGo6+AAoJEBx+YmzsjxAgF2MP/imuN2sb41+N2J0dL8OoH0W7
JgjXR+h5OSLDvvHp2w6b2mOzo/f0QWcZgIDDvW4hMLsiI4eYuPBgd3wqNAsFxS56
2Xs+RgNnE3KfQBY8nFzpKGKTt3YaDcaiZDA3uA5XuYJudDM0Oim7PqMQ0eDEz/Bt
1Pm5c8ngykRhhlUdBEQ7Vjz6+AAPx3CSeYUKWHgin3jAp4NF/MutxJvJk1TJDjGA
bV5H5pDIhwFY+niIZJOcWxqR5HGi3TcXRnRVs9MxEj9fwdrbJR4iRLT2kxTE/m1t
9Ph3MGg9F7q3AijK10uzaX6AxcNPfLQuY6+SGNPyAZNhfi/A/KcnJSDFD0P+iqzb
PVfYRhPffSsUkmZCT16aTkU3+meIGx3uS268v5o9DDf9eUTfK11sgsiJhAG28KJ1
n0WyA4saVTHkXFbRr2qecigCsPC8mnOS3b0IsTqnScLCctL/UgaUOSPo7Vp7luOt
di4OwVVU7TWh0Ggj+q/9jMFLhJyBOy4FUVla8vnQ1TEY2c7VRi8OB26gIKxQcFwo
MXVhK8Icko+oHq68wqYP7yrprDNRjXKUsDh62Q22pE3nYIGVkEop8qO0NcD3eBZ/
d1swKuVFye+Uk+UrLilm3dYTdCB/P1W3c8ZsfbsW9TXAZ5FsLo8Pnn2J4DwfxhUg
lWCj7PXmNsxLLFkEKe2k
=Q2Q4
-----END PGP SIGNATURE-----
Merge tag 'sunxi-dt-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into next/dt
Pull "Allwinner DT changes for 4.4" from Maxime Ripard:
DT patches for the 4.4 merge window, most notably:
- Enable the OTG controller on more boards
- Create new DTSI for the q8's design
- Added RSB support to the A23 and A33 SoCs
- New boards: Olimex A20 EVB, Yones bs1078v2
Plus the usual random patches enabling and / or enhancing a few things in
particular boards.
* tag 'sunxi-dt-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: (59 commits)
ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies
ARM: dts: sun8i: sinlinx-sina33: Enable Reduced Serial Bus controller
ARM: dts: sun8i: q8-common: Enable RSB controller for A23/A33 Q8 tablets
ARM: dts: sun8i: Add Reduced Serial Bus controller device node to A23/A33 dtsi
ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2
ARM: sun7i: dt: Add new Olimex A20 EVB device
ARM: dts: sun6i: hummingbird: Add aliases for rtc devices
ARM: dts: sun7i: Add dts file for Wits Pro A20 DKT
ARM: dts: sun7i: Enable USB DRC on Wexler TAB7200
ARM: dts: sun7i: Enable USB DRC on the Orange pi
ARM: dts: sun7i: Enable USB DRC on orangepi-mini
ARM: dts: axp209: Add usb_power_supply child node to the ax209 node
ARM: dts: sun8i: Make ippo-q8h-v1.2.dts a symlink to q8-tablet.dts
ARM: dts: sun8i: Add sun8i-a33-q8-tablet.dts file
ARM: dts: sun6i: Add support for Yones Toptech bs1078v2 tablets
ARM: dts: sun4i: Enable USB DRC on the Marsboard A10
ARM: dts: sun4i: gemei-g9: Add accelerometer (bma250) IRQ
ARM: dts: sun8i-a33: Add security system crypto engine clock and device nodes
ARM: dts: sun8i: Add pwm-backlight device for A23/A33 Q8 format tablets
ARM: sun8i: A23: Add missing msgbox gate
...
- use serial aliases and stdout path
- add cpufreq properties to all SoCs
- add pwm nodes for all SoCs
This depends on topic branch berlin-cpuclk-for-4.4-1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWEr3kAAoJEN2kpao7fSL4aiMP/RZtVig0BWx9ndsht/PNye40
2AKvH33gnQZTEbS3LVprG19MUmKyOh8g5SEgxPkAtoIdGoEwDwdWgGRXzaFQVPbb
QGZZ2tyoBnJMWhVWMst/dQx1hpQ7wyI2yanLDLH8wbJ8v7ctC7oAQLlenuntkjjQ
jakxbaDRwB5cJUS3RWNi+0E35sCXetdmWHRergp1LL77dWGxDgBjEr/9zoSZ6ChH
vqPX685Cb1pTuADX3Ihm+euRDH2xjF9bMj1qVLjpFVSqq0yNF7bThAuzatQtOC5q
M7neEcO0p3KVA5YvJBr8qBJgsrVC0KkuRfkcdppw7sJEpObOqi+fw24mXNEys/ze
rpudmXp9U3oazGrvN6LGK7HHeYRRVMtkgVUjXEhrav/Gn+N6/zg2DZUYZ5zSSUvJ
guv4BmdO2tbIXZw282gcWLGDxZG/R33QEMBe6GPh5UtjMs9ICpJKaEyGXrNUbnch
fhg0ZF4Rsh2vI9zc35nCHNm/TBnRjemJ5lVABPq1HtFxclnZRHALz3h8Z5u45lPL
4PCihtRZugvwrAfDVUJ4Mu9jm2Sc5tIL4xhKJySwJp3GYMO4Mw9aR2LxKUYZYw04
gojxR+yeghMK5OVA3bBkRtOtzjeQxaOC64hEFwAWyxULoLukMFThuZymy2XUIOmd
q2sZmkgF+hvHCDzTqyaH
=3SFe
-----END PGP SIGNATURE-----
Merge tag 'berlin-dt-for-4.4-1' of git://git.infradead.org/users/hesselba/linux-berlin into next/dt
Merge "Marvell Berlin DT for 4.4 take 1" from Sebastian Hesselbarth:
- use serial aliases and stdout path
- add cpufreq properties to all SoCs
- add pwm nodes for all SoCs
This depends on topic branch berlin-cpuclk-for-4.4-1
* tag 'berlin-dt-for-4.4-1' of git://git.infradead.org/users/hesselba/linux-berlin:
ARM: berlin: add a PWM node on the BG2CD
ARM: berlin: add a PWM node on the BG2
ARM: berlin: add a PWM node on the BG2Q
ARM: berlin: dts: add the cpufreq-dt bindings on the BG2CD
ARM: berlin: dts: add the cpufreq-dt bindings on the BG2
ARM: berlin: dts: add the cpufreq-dt bindings on the BG2Q
arm: dts: berlin: use stdout-path
arm: dts: berlin: add aliases for serial
Update dts to use the new crypto driver on mvebu SoCs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlYX5x8ACgkQCwYYjhRyO9XoUgCeOcVjHqbrmPUsxyuJt6wF8L9p
kasAn0hDt61/LCd/Tf4UJW+HzpRgoDG7
=J1D5
-----END PGP SIGNATURE-----
Merge tag 'mvebu-dt-4.4-1' of git://git.infradead.org/linux-mvebu into next/dt
Merge "mvebu dt for 4.4 (part 1)" from Gregory CLEMENT:
Update dts to use the new crypto driver on mvebu SoCs
* tag 'mvebu-dt-4.4-1' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: modify Orion and Kirkwoord crypto compatible strings
ARM: mvebu: use new bindings for existing crypto devices
ARM: mvebu: define crypto SRAM ranges for all armada-38x boards
ARM: mvebu: add crypto related nodes to armada 38x dtsi
ARM: mvebu: define crypto SRAM ranges in armada-375-db.dts
ARM: mvebu: add crypto related nodes to armada 375 dtsi
ARM: mvebu: define crypto SRAM ranges for all armada-370 boards
ARM: mvebu: add crypto related nodes to armada 370 dtsi
ARM: mvebu: define crypto SRAM ranges for all armada-xp boards
ARM: mvebu: add crypto related nodes to armada-xp.dtsi
ARM: mvebu: add CPU config registers in the Armada 370/XP Device Tree
Add Chen-Yu Tsai as a co-maintainer to the ARM sunxi support.
While we are doing so, also update the entry for new SoCs.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Some recently added code to avoid a bug introduced a build error
when CONFIG_PM is disabled and a macro is hidden:
arch/arm/mach-pxa/pxa3xx.c: In function 'pxa3xx_init':
arch/arm/mach-pxa/pxa3xx.c:439:3: error: 'NDCR' undeclared (first use in this function)
NDCR = (NDCR & ~NDCR_ND_ARB_EN) | NDCR_ND_ARB_CNTL;
^
This moves the macro outside of the #ifdef so it can be
referenced correctly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: adf3442cc8 ("ARM: pxa: fix DFI bus lockups on startup")
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
It includes a single fix for i.MX7D, which corrects the base address of
UART2 in device tree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWG7gvAAoJEFBXWFqHsHzOnysH/3g6f2HhjnyP627EgE8ipJJB
3S/rteN22cV0e8siM6oxa97gMjVGX9A6asGKkpE5v26SGKDbvhUhH5WCqKUioFCn
LDjcNUK1Yd830K/t7dyBM4bZlPp7nLCfLMzFG+8PvVWl5OvfR5eJ14KLAyS0mO9b
F/GoqV2VSrTw5AA3gOfBhckHtVZJJ01b4vu28G9NSc8eU4W5aJDQMDaZ40MLftuS
ZEt9o+us/YlJQzuIeKN2sk5Rb+w2jeZOXWEKOZfIFab3aE8BY+/NgedqMNwf1J1Z
EWGQ6oIOIe5vU6k9j0neQ4a5hVqW+layzgdXZaYhWzfkpM7DFuvVyeK08yiARts=
=h6oq
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
Pull "The i.MX fixes for 4.3, 2nd round:" from Shawn Guo:
It includes a single fix for i.MX7D, which corrects the base address of
UART2 in device tree.
* tag 'imx-fixes-4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx7d: Fix UART2 base address
- BG2Q USB PHY compatible fix (also tagged for stable v4.2)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWEr7WAAoJEN2kpao7fSL4qYgP/3q44RBV2KgWmFFmTdINPhQK
yotBdpgahWtK/5VndZGW0VTWSPvuXBju2wbE5ZjkxQZaQJPEnqoZ17dsvR5w5ZAe
hvauZ64UbL7yCqpPXR8L1DRQQ96rLaU51eHWUSJbLl2d0UEQ1Wiaqviqypa0xN1W
0AGLRJdXMqqRhvKj4vd7NrC4UAlsU2FsYgNfnq6IqKmM4Nxt2bk9lVwc2/BUf+sm
uk/lUalwbOWv/YV9eF4GFOMZFXWZarY/d/dP/ksWe3U/2rv18kohv2xsn6/mmc0T
GMX7mdCIB2nXERtJByJFTh1bJSub8moJJYts0ci1hZooZ5GgWV7lwmCJitocBd53
kNeQ/1tq/RTzh9b4AY39XjBx+a8rR+nbaG4SoYkGCQXNGll2xE9IZ9F7AaoFxbqH
UQ2DC1w+ga8UB/xY7TlAtVrF9Q66EF6T5VthRQ1f3DSBWr5fCHGLRBoT1qfJURgm
K1UFh3hTXsTREsCFMSiyIp64n5rute5Tjb5tijaQa3/mxUvWFlFvZu2EmmWddukV
JQc/XD+UM1AU1PrAs+g1JSDbwO5AGE7FRC/4Y+y+g8BCktJRagPDeBzc76maBdkm
89g/up1hbqrmTep/AaBb7oPYSspVd9TN73eX3rxaN6WvsyvnGmcgwr1jKOX3pVGg
lWEFVJJgaUkYH1EuVpZz
=BDI7
-----END PGP SIGNATURE-----
Merge tag 'berlin-fixes-for-4.3-1' of git://git.infradead.org/users/hesselba/linux-berlin into fixes
Merge "Marvell Berlin fixes for v4.3 take 1" from Sebastian Hesselbarth:
- BG2Q USB PHY compatible fix (also tagged for stable v4.2)
* tag 'berlin-fixes-for-4.3-1' of git://git.infradead.org/users/hesselba/linux-berlin:
ARM: dts: berlin: change BG2Q's USB PHY compatible
It adds support for the following features provided by SCP firmware
using different subsystems in Linux:
1. SCPI mailbox protocol driver which using mailbox framework
2. Clocks provided by SCP using clock framework
3. CPU DVFS(cpufreq) using existing arm-big-little driver
4. SCPI based sensors including temperature sensors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJWF7ifAAoJEABBurwxfuKYAfMP/34ka/n4+U/aPQXzStNIwr3v
Nme9WSf3mUPv26MstRDrWRYi1G2WLOTlc196MpdIt6m6QLOjxzEl3tSq5ILrj7yN
KoLojtISmu/pbhVcJN5fllxgpcJzufLoEWBa5T/Y/4GoIhh1NCYa82QpNgzPmsMd
rPCkYHqwT6I3sIS+/mbDkGA/QnwJ2qtJ8sp3+fL+dyJbI7Aa1zJZP6ectPsxK22+
HFoFTY45rdFv/ojZZFZL8E/gcblYwRWKzIgwdASHuDXxIhd/IPwjrex2Iyv75AQK
zusRQ5Xv82GaYWHVa9GXmZqXkTsvBg4AJwc4Uq2JdB0qOi2a4tc8PkK7Ts5YdHgS
YVGxbY1POtMBi2bJUjsviMY7dGR3I+iEXJTYnbPnkVa+GTv8/FViVmOOLQnnBF4R
fN5FN0vfuL6zaQzOPYLGx3SuEHix3ko2DCAcMg6idIxuBHArlJuS7XKECWdHuc0+
+qn6Iqf8YSKIZ1zrWMggqY/sXuxjtABUBXe3jP3iTKQh8h+9SLfN3wgQM4GFJJcB
gNfvk3Hl5aPFy/7gsgSDlaYbhGKPwTup+R8Fqd6nSBQO+rpRXvQQftwigYQiIEcE
IiOS3BntVQWjoVr9WIifguf6rHG1ZoSMTHdtVVEaqsspT/OGJyq/ynEFJYSFqcqX
NRPdQJNuoXGolGhyoWxD
=9u+p
-----END PGP SIGNATURE-----
Merge tag 'arm-scpi-for-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers
Merge "ARM System Control and Power Interface(SCPI) support" from Sudeep Holla
It adds support for the following features provided by SCP firmware
using different subsystems in Linux:
1. SCPI mailbox protocol driver which using mailbox framework
2. Clocks provided by SCP using clock framework
3. CPU DVFS(cpufreq) using existing arm-big-little driver
4. SCPI based sensors including temperature sensors
* tag 'arm-scpi-for-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
hwmon: Support thermal zones registration for SCP temperature sensors
hwmon: Support sensors exported via ARM SCP interface
firmware: arm_scpi: Extend to support sensors
Documentation: add DT bindings for ARM SCPI sensors
cpufreq: arm_big_little: add SCPI interface driver
clk: scpi: add support for cpufreq virtual device
clk: add support for clocks provided by SCP(System Control Processor)
firmware: add support for ARM System Control and Power Interface(SCPI) protocol
Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol
A new limit selected arbitrarily as power of two greater than
required minimum for Xeon Phi processor (72 for Knights Landing).
Currently driver is not able to handle cores with core ID greater than 32.
Such attempt ends up with the following error in dmesg:
coretemp coretemp.0: Adding Core XXX failed
Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The TMP75C has a different control register layout and only supports
12-bit temperature samples (0.0625 deg C).
The continuous sample rate is ~12 Hz.
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix module autoload for IBM and Open power platforms.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The description in the driver states: "ABX500 does not provide auto ADC,
so to monitor the required temperatures, a periodic work is used. It is
more important to not wake up the CPU... If the chip gets too hot during
a sleep state it's most likely due to external factors, such as the
surrounding temperature and nothing can be done in S/W."
So it makes no sense to keep IRQs enabled as it need not be wakeup
source. This patch removes the use of IRQF_NO_SUSPEND flag
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
max31790_update_device() return the error code in ERR_PTR. We were
checking if it has returned error or not but before checking we have
dereferenced it.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
They are currently unused, and I don't think that anyone was
ever particularly happy with them. They had the unfortunate
property that they made it easy to CFI-annotate things without
thinking about them -- when pushing, do you want to just update
the CFA offset, or do you also want to update the saved location
of the register being pushed?
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1447bfbd10bb268b4593b32534ecefa1f4df287e.1444696194.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Checkpatch is really quite bad for user code like this, but it
caught two legit style issues.
Reported-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/3335040bdd40d2bca4b1a28a3f8b165361c801b7.1444696194.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
non-modular by ripping out the module_* code since Kconfig doesn't
allow it to be built as a module anyway - Paul Gortmaker
* Make the x86 efi=debug kernel parameter, which enables EFI debug
code and output, generic and usable by arm64 - Leif Lindholm
* Add support to the x86 EFI boot stub for 64-bit Graphics Output
Protocol frame buffer addresses - Matt Fleming
* Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled
in the firmware and set an efi.flags bit so the kernel knows when
it can apply more strict runtime mapping attributes - Ard Biesheuvel
* Auto-load the efi-pstore module on EFI systems, just like we
currently do for the efivars module - Ben Hutchings
* Add "efi_fake_mem" kernel parameter which allows the system's EFI
memory map to be updated with additional attributes for specific
memory ranges. This is useful for testing the kernel code that handles
the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware
doesn't include support - Taku Izumi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWG7OwAAoJEC84WcCNIz1VEEEP/0SsdrwJ66B4MfP5YNjqHYWm
+OTHR6Ovv2i10kc+NjOV/GN8sWPndnkLfIfJ4EqJ9BoQ9PDEYZilV2aleSQ4DrPm
H7uGwBXQkfd76tZKX9pMToK76mkhg6M7M2LR3Suv3OGfOEzuozAOt3Ez37lpksTN
2ByhHr/oGbhu99jC2ki5+k0ySH8PMqDBRxqrPbBzTD+FfB7bM11vAJbSNbSMQ21R
ZwX0acZBLqb9J2Vf7tDsW+fCfz0TFo8JHW8jdLRFm/y2dpquzxswkkBpODgA8+VM
0F5UbiUdkaIRug75I6N/OJ8+yLwdzuxm7ul+tbS3JrXGLAlK3850+dP2Pr5zQ2Ce
zaYGRUy+tD5xMXqOKgzpu+Ia8XnDRLhOlHabiRd5fG6ZC9nR8E9uK52g79voSN07
pADAJnVB03CGV/HdduDOI4C4UykUKubuArbQVkqWJcecV1Jic/tYI0gjeACmU1VF
v8FzXpBUe3U3A0jauOz8PBz8M+k5qky/GbIrnEvXreBtKdt999LN9fykTN7rBOpo
dk/6vTR1Jyv3aYc9EXHmRluktI6KmfWCqmRBOIgQveX1VhdRM+1w2LKC0+8co3dF
v/DBh19KDyfPI8eOvxKykhn164UeAt03EXqDa46wFGr2nVOm/JiShL/d+QuyYU4G
8xb/rET4JrhCG4gFMUZ7
=1Oee
-----END PGP SIGNATURE-----
Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into core/efi
Pull v4.4 EFI updates from Matt Fleming:
- Make the EFI System Resource Table (ESRT) driver explicitly
non-modular by ripping out the module_* code since Kconfig doesn't
allow it to be built as a module anyway. (Paul Gortmaker)
- Make the x86 efi=debug kernel parameter, which enables EFI debug
code and output, generic and usable by arm64. (Leif Lindholm)
- Add support to the x86 EFI boot stub for 64-bit Graphics Output
Protocol frame buffer addresses. (Matt Fleming)
- Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled
in the firmware and set an efi.flags bit so the kernel knows when
it can apply more strict runtime mapping attributes - Ard Biesheuvel
- Auto-load the efi-pstore module on EFI systems, just like we
currently do for the efivars module. (Ben Hutchings)
- Add "efi_fake_mem" kernel parameter which allows the system's EFI
memory map to be updated with additional attributes for specific
memory ranges. This is useful for testing the kernel code that handles
the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware
doesn't include support. (Taku Izumi)
Note: there is a semantic conflict between the following two commits:
8a53554e12 ("x86/efi: Fix multiple GOP device support")
ae2ee627dc ("efifb: Add support for 64-bit frame buffer addresses")
I fixed up the interaction in the merge commit, changing the type of
current_fb_base from u32 to u64.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
computations. But the bandwidth of the entire DMA engine is shared
among all channels. This patch re-configures operations availability
such that one can achieve maximum performance for XOR and PQ
computation by removing the memory offload operations.
Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Introduce __vmx_flush_tlb() to handle specific vpid.
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Adjust allocate/free_vid so that they can be reused for the nested vpid.
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
async_pf_execute() seems to be missing a memory barrier which might
cause the waker to not notice the waiter and miss sending a wake_up as
in the following figure.
async_pf_execute kvm_vcpu_block
------------------------------------------------------------------------
spin_lock(&vcpu->async_pf.lock);
if (waitqueue_active(&vcpu->wq))
/* The CPU might reorder the test for
the waitqueue up here, before
prior writes complete */
prepare_to_wait(&vcpu->wq, &wait,
TASK_INTERRUPTIBLE);
/*if (kvm_vcpu_check_block(vcpu) < 0) */
/*if (kvm_arch_vcpu_runnable(vcpu)) { */
...
return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
!vcpu->arch.apf.halted)
|| !list_empty_careful(&vcpu->async_pf.done)
...
return 0;
list_add_tail(&apf->link,
&vcpu->async_pf.done);
spin_unlock(&vcpu->async_pf.lock);
waited = true;
schedule();
------------------------------------------------------------------------
The attached patch adds the missing memory barrier.
I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On real hardware, edge-triggered interrupts don't set a bit in TMR,
which means that IOAPIC isn't notified on EOI. Do the same here.
Staying in guest/kernel mode after edge EOI is what we want for most
devices. If some bugs could be nicely worked around with edge EOI
notifications, we should invest in a better interface.
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM uses eoi_exit_bitmap to track vectors that need an action on EOI.
The problem is that IOAPIC can be reconfigured while an interrupt with
old configuration is pending and eoi_exit_bitmap only remembers the
newest configuration; thus EOI from the pending interrupt is not
recognized.
(Reconfiguration is not a problem for level interrupts, because IOAPIC
sends interrupt with the new configuration.)
For an edge interrupt with ACK notifiers, like i8254 timer; things can
happen in this order
1) IOAPIC inject a vector from i8254
2) guest reconfigures that vector's VCPU and therefore eoi_exit_bitmap
on original VCPU gets cleared
3) guest's handler for the vector does EOI
4) KVM's EOI handler doesn't pass that vector to IOAPIC because it is
not in that VCPU's eoi_exit_bitmap
5) i8254 stops working
A simple solution is to set the IOAPIC vector in eoi_exit_bitmap if the
vector is in PIR/IRR/ISR.
This creates an unwanted situation if the vector is reused by a
non-IOAPIC source, but I think it is so rare that we don't want to make
the solution more sophisticated. The simple solution also doesn't work
if we are reconfiguring the vector. (Shouldn't happen in the wild and
I'd rather fix users of ACK notifiers instead of working around that.)
The are no races because ioapic injection and reconfig are locked.
Fixes: b053b2aef2 ("KVM: x86: Add EOI exit bitmap inference")
[Before b053b2aef2, this bug happened only with APICv.]
Fixes: c7c9c56ca2 ("x86, apicv: add virtual interrupt delivery support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After moving PIR to IRR, the interrupt needs to be delivered manually.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In order to get into 64-bit protected mode, you need to enable
paging while EFER.LMA=1. For this to work, CS.L must be 0.
Currently, we load the segments before CR0 and CR4, which means
that if RSM returns into 64-bit protected mode CS.L is already 1
and everything breaks.
Luckily, CS.L=0 is always the case when executing RSM, because it
is forbidden to execute RSM from 64-bit protected mode. Hence it
is enough to load CR0 and CR4 first, and only then the segments.
Fixes: 660a5d517a
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If the eDMA3 has support for channel paRAM slot mapping we can utilize it
to allocate slots on demand and save precious slots for real transfers.
On am335x the eDMA has 64 channels which means we can unlock 64 paRAM
slots out from the available 256.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The names chosen for the bitfields were quite confusing and given no real
information on what they are used for...
edma_inuse -> slot_inuse: tracks the slot usage/availability
edma_unused -> channel_unused: tracks the channel usage/availability
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Instead of directly reading it from CCCFG register take the information out
once when we set up the configuration from the HW.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
No need to run through the bits in QEMR and CCERR events since they will
not trigger any action, so just clearing the errors there is fine.
In case of the missed event the loop can be optimized so we spend less time
to handle the event.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
In the ccerr interrupt handler the code checks for pending errors in the
error status registers in two different places.
Move the check out to a helper function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
With the merger of the arch/arm/common/edma.c code into the dmaengine
driver, there is no longer need to have per channel callback/data storage
for interrupt events.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Remove or rewrite the comments for the internal functions.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Warning message in case of linking between paRAM slots in different eDMA
controllers.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
edma_write_slot() is for writing an entire paRAM slot.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
We have access to dev, so it is better to use the dev_dbg for debug prints.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Be consistent and do not mix the use of dev, &pdev->dev, etc in the
functions.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
When allocating a memory for number of items it is better (looks better)
to use devm_kcalloc.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Instead of using defines to specify the size of different arrays and
bitmaps, allocate the memory for them based on the information we get from
the HW itself.
Since these defines are set based on the worst case, there are devices
where they are not valid.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal (if eny) functional change to the code
as possible to avoid introducing regression.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The upcoming change to merge the arch/arm/common/edma.c into
drivers/dma/edma.c will need this change when booting daVinci devices in
no DT mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
