<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/arch/arm, branch linux-5.6.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.6.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.6.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2020-06-17T14:42:09+00:00</updated>
<entry>
<title>KVM: arm64: Save the host's PtrAuth keys in non-preemptible context</title>
<updated>2020-06-17T14:42:09+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-06-03T17:24:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=91f304e6c83b4ad55ef6032f32111296febb40dd'/>
<id>urn:sha1:91f304e6c83b4ad55ef6032f32111296febb40dd</id>
<content type='text'>
commit ef3e40a7ea8dbe2abd0a345032cd7d5023b9684f upstream.

When using the PtrAuth feature in a guest, we need to save the host's
keys before allowing the guest to program them. For that, we dump
them in a per-CPU data structure (the so called host context).

But both call sites that do this are in preemptible context,
which may end up in disaster should the vcpu thread get preempted
before reentering the guest.

Instead, save the keys eagerly on each vcpu_load(). This has an
increased overhead, but is at least safe.

Cc: stable@vger.kernel.org
Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception</title>
<updated>2020-06-17T14:42:08+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-06-09T07:50:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e311a17d6a060bb650c8e4568e6a5588f37be25'/>
<id>urn:sha1:1e311a17d6a060bb650c8e4568e6a5588f37be25</id>
<content type='text'>
commit 0370964dd3ff7d3d406f292cb443a927952cbd05 upstream.

On a VHE system, the EL1 state is left in the CPU most of the time,
and only syncronized back to memory when vcpu_put() is called (most
of the time on preemption).

Which means that when injecting an exception, we'd better have a way
to either:
(1) write directly to the EL1 sysregs
(2) synchronize the state back to memory, and do the changes there

For an AArch64, we already do (1), so we are safe. Unfortunately,
doing the same thing for AArch32 would be pretty invasive. Instead,
we can easily implement (2) by calling the put/load architectural
backends, and keep preemption disabled. We can then reload the
state back into EL1.

Cc: stable@vger.kernel.org
Reported-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description</title>
<updated>2020-06-17T14:42:07+00:00</updated>
<author>
<name>Ludovic Desroches</name>
<email>ludovic.desroches@microchip.com</email>
</author>
<published>2020-04-01T22:15:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=380b60cd3c25d2f1db17ed66ca70ff6fc50baae4'/>
<id>urn:sha1:380b60cd3c25d2f1db17ed66ca70ff6fc50baae4</id>
<content type='text'>
commit a1af7f36c70369b971ee1cf679dd68368dad23f0 upstream.

Remove non-removable and mmc-ddr-1_8v properties from the sdmmc0
node which come probably from an unchecked copy/paste.

Signed-off-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Fixes:42ed535595ec "ARM: dts: at91: introduce the sama5d2 ptc ek board"
Cc: stable@vger.kernel.org # 4.19 and later
Link: https://lore.kernel.org/r/20200401221504.41196-1-ludovic.desroches@microchip.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook</title>
<updated>2020-06-17T14:41:49+00:00</updated>
<author>
<name>Fredrik Strupe</name>
<email>fredrik@strupe.net</email>
</author>
<published>2020-05-18T18:41:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f3f80283a0a86a6a25284ce2ed9748bb9d31d1d2'/>
<id>urn:sha1:f3f80283a0a86a6a25284ce2ed9748bb9d31d1d2</id>
<content type='text'>
[ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ]

call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
(0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
instructions will be masked out. This makes the function match 32-bit
thumb instructions where the second half-word is equal to instr_val,
regardless of the first half-word.

The result in this case is that all undefined 32-bit thumb instructions
with the second half-word equal to 0xde01 (udf #1) work as breakpoints
and will raise a SIGTRAP instead of a SIGILL, instead of just the one
intended 16-bit instruction. An example of such an instruction is
0xeaa0de01, which is unallocated according to Arm ARM and should raise a
SIGILL, but instead raises a SIGTRAP.

This patch fixes the issue by setting all the bits in instr_mask, which
will still match the intended 16-bit thumb instruction (where the
upper half is always 0), but not any 32-bit thumb instructions.

Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Fredrik Strupe &lt;fredrik@strupe.net&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: mmp3: Drop usb-nop-xceiv from HSIC phy</title>
<updated>2020-06-03T06:23:18+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-04-19T17:11:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a81254cb8f1b06bfe55953d013629b63bbd03c49'/>
<id>urn:sha1:a81254cb8f1b06bfe55953d013629b63bbd03c49</id>
<content type='text'>
[ Upstream commit 24cf6eef79a7e85cfd2ef9dea52f769c9192fc6e ]

"usb-nop-xceiv" is good enough if we don't lose the configuration done
by the firmware, but we'd really prefer a real driver.

Unfortunately, the PHY core is odd in that when the node is compatible
with "usb-nop-xceiv", it ignores the other compatible strings. Let's
just remove it.

Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: mmp3-dell-ariel: Fix the SPI devices</title>
<updated>2020-06-03T06:23:18+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-04-19T17:11:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c513b67835f36c964f09935145cc4a249daf1b4c'/>
<id>urn:sha1:c513b67835f36c964f09935145cc4a249daf1b4c</id>
<content type='text'>
[ Upstream commit 233cbffaa0b9ca874731efee67a11f005da1f87c ]

I've managed to get about everything wrong while digging these out of
OEM's board file.

Correct the bus numbers, the exact model of the NOR flash, polarity of
the chip selects and align the SPI frequency with the data sheet.

Tested that it works now, with a slight fix to the PXA SSP driver.

Link: https://lore.kernel.org/r/20200419171157.672999-16-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: mmp3: Use the MMP3 compatible string for /clocks</title>
<updated>2020-06-03T06:23:17+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-04-19T17:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=da8faa3a9851fb16e808a374ff702202d52e21e3'/>
<id>urn:sha1:da8faa3a9851fb16e808a374ff702202d52e21e3</id>
<content type='text'>
[ Upstream commit ec7d12faf81de983efce8ff23f41c5d1bff14c41 ]

Clocks are in fact slightly different on MMP3. In particular, PLL2 is
fixed to a different frequency, there's an extra PLL3, and the GPU
clocks are configured differently.

Link: https://lore.kernel.org/r/20200419171157.672999-15-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: bcm: HR2: Fix PPI interrupt types</title>
<updated>2020-06-03T06:23:17+00:00</updated>
<author>
<name>Hamish Martin</name>
<email>hamish.martin@alliedtelesis.co.nz</email>
</author>
<published>2020-05-20T04:30:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2a1339a2afb8457eea356b3e85fddf82d72adcd5'/>
<id>urn:sha1:2a1339a2afb8457eea356b3e85fddf82d72adcd5</id>
<content type='text'>
[ Upstream commit be0ec060b54f0481fb95d59086c1484a949c903c ]

These error messages are output when booting on a BCM HR2 system:
    GIC: PPI11 is secure or misconfigured
    GIC: PPI13 is secure or misconfigured

Per ARM documentation these interrupts are triggered on a rising edge.
See ARM Cortex A-9 MPCore Technical Reference Manual, Revision r4p1,
Section 3.3.8 Interrupt Configuration Registers.

The same issue was resolved for NSP systems in commit 5f1aa51c7a1e
("ARM: dts: NSP: Fix PPI interrupt types").

Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")
Signed-off-by: Hamish Martin &lt;hamish.martin@alliedtelesis.co.nz&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: bcm2835-rpi-zero-w: Fix led polarity</title>
<updated>2020-06-03T06:23:17+00:00</updated>
<author>
<name>Vincent Stehlé</name>
<email>vincent.stehle@laposte.net</email>
</author>
<published>2020-04-18T12:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d2777a5c1cd196ace1f70c4b9fe0828fb7888deb'/>
<id>urn:sha1:d2777a5c1cd196ace1f70c4b9fe0828fb7888deb</id>
<content type='text'>
[ Upstream commit 58bb90ab415562eededb932455046924e65df342 ]

The status "ACT" led on the Raspberry Pi Zero W is on when GPIO 47 is low.

This has been verified on a board and somewhat confirmed by both the GPIO
name ("STATUS_LED_N") and the reduced schematics [1].

[1]: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_ZeroW_1p1_reduced.pdf

Fixes: 2c7c040c73e9 ("ARM: dts: bcm2835: Add Raspberry Pi Zero W")
Signed-off-by: Vincent Stehlé &lt;vincent.stehle@laposte.net&gt;
Cc: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts/imx6q-bx50v3: Set display interface clock parents</title>
<updated>2020-06-03T06:23:16+00:00</updated>
<author>
<name>Robert Beckett</name>
<email>bob.beckett@collabora.com</email>
</author>
<published>2020-05-14T17:02:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2bb219c431a7114d6fb641c14c1a0ae8e8ab1126'/>
<id>urn:sha1:2bb219c431a7114d6fb641c14c1a0ae8e8ab1126</id>
<content type='text'>
[ Upstream commit 665e7c73a7724a393b4ec92d1ae1e029925ef2b7 ]

Avoid LDB and IPU DI clocks both using the same parent. LDB requires
pasthrough clock to avoid breaking timing while IPU DI does not.

Force IPU DI clocks to use IMX6QDL_CLK_PLL2_PFD0_352M as parent
and LDB to use IMX6QDL_CLK_PLL5_VIDEO_DIV.

This fixes an issue where attempting atomic modeset while using
HDMI and display port at the same time causes LDB clock programming
to destroy the programming of HDMI that was done during the same
modeset.

Cc: stable@vger.kernel.org
Signed-off-by: Robert Beckett &lt;bob.beckett@collabora.com&gt;
[Use IMX6QDL_CLK_PLL2_PFD0_352M instead of IMX6QDL_CLK_PLL2_PFD2_396M
 originally chosen by Robert Beckett to avoid affecting eMMC clock
 by DRM atomic updates]
Signed-off-by: Ian Ray &lt;ian.ray@ge.com&gt;
[Squash Robert's and Ian's commits for bisectability, update patch
 description and add stable tag]
Signed-off-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
