<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/arch/arm64, branch linux-5.5.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.5.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.5.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2020-04-21T07:06:40+00:00</updated>
<entry>
<title>arm64: vdso: don't free unallocated pages</title>
<updated>2020-04-21T07:06:40+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2020-04-14T10:42:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ec7bcad7708246af1c2695b1974c7c396a7f46af'/>
<id>urn:sha1:ec7bcad7708246af1c2695b1974c7c396a7f46af</id>
<content type='text'>
commit 9cc3d0c6915aee5140f8335d41bbc3ff1b79aa4e upstream.

The aarch32_vdso_pages[] array never has entries allocated in the C_VVAR
or C_VDSO slots, and as the array is zero initialized these contain
NULL.

However in __aarch32_alloc_vdso_pages() when
aarch32_alloc_kuser_vdso_page() fails we attempt to free the page whose
struct page is at NULL, which is obviously nonsensical.

This patch removes the erroneous page freeing.

Fixes: 7c1deeeb0130 ("arm64: compat: VDSO setup for compat layer")
Cc: &lt;stable@vger.kernel.org&gt; # 5.3.x-
Cc: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: librem5-devkit: add a vbus supply to usb0</title>
<updated>2020-04-21T07:06:37+00:00</updated>
<author>
<name>Angus Ainslie (Purism)</name>
<email>angus@akkea.ca</email>
</author>
<published>2020-02-27T13:17:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e82a848ac443fde8a2f8d218d3adffd934ca104d'/>
<id>urn:sha1:e82a848ac443fde8a2f8d218d3adffd934ca104d</id>
<content type='text'>
commit dde061b865598ad91f50140760e1d224e5045db9 upstream.

Without a VBUS supply the dwc3 driver won't go into otg mode.

Fixes: eb4ea0857c83 ("arm64: dts: fsl: librem5: Add a device tree for the Librem5 devkit")
Signed-off-by: Angus Ainslie (Purism) &lt;angus@akkea.ca&gt;
Signed-off-by: Martin Kepplinger &lt;martin.kepplinger@puri.sm&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: Always force a branch protection mode when the compiler has one</title>
<updated>2020-04-17T14:12:18+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2020-03-31T19:44:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f9b20037a768e1d16863e18ed14457fce304009f'/>
<id>urn:sha1:f9b20037a768e1d16863e18ed14457fce304009f</id>
<content type='text'>
commit b8fdef311a0bd9223f10754f94fdcf1a594a3457 upstream.

Compilers with branch protection support can be configured to enable it by
default, it is likely that distributions will do this as part of deploying
branch protection system wide. As well as the slight overhead from having
some extra NOPs for unused branch protection features this can cause more
serious problems when the kernel is providing pointer authentication to
userspace but not built for pointer authentication itself. In that case our
switching of keys for userspace can affect the kernel unexpectedly, causing
pointer authentication instructions in the kernel to corrupt addresses.

To ensure that we get consistent and reliable behaviour always explicitly
initialise the branch protection mode, ensuring that the kernel is built
the same way regardless of the compiler defaults.

[This is a reworked version of b8fdef311a0bd9223f1075 ("arm64: Always
force a branch protection mode when the compiler has one") for backport.
Kernels prior to 74afda4016a7 ("arm64: compile the kernel with ptrauth
return address signing") don't have any Makefile machinery for forcing
on pointer auth but still have issues if the compiler defaults it on so
need this reworked version. -- broonie]

Fixes: 7503197562567 (arm64: add basic pointer authentication support)
Reported-by: Szabolcs Nagy &lt;szabolcs.nagy@arm.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Cc: stable@vger.kernel.org
[catalin.marinas@arm.com: remove Kconfig option in favour of Makefile check]
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: armv8_deprecated: Fix undef_hook mask for thumb setend</title>
<updated>2020-04-17T14:12:13+00:00</updated>
<author>
<name>Fredrik Strupe</name>
<email>fredrik@strupe.net</email>
</author>
<published>2020-04-08T11:29:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0a467c4db7a7262bcae8e391faf89880d7c7f0c'/>
<id>urn:sha1:e0a467c4db7a7262bcae8e391faf89880d7c7f0c</id>
<content type='text'>
commit fc2266011accd5aeb8ebc335c381991f20e26e33 upstream.

For thumb instructions, call_undef_hook() in traps.c first reads a u16,
and if the u16 indicates a T32 instruction (u16 &gt;= 0xe800), a second
u16 is read, which then makes up the the lower half-word of a T32
instruction. For T16 instructions, the second u16 is not read,
which makes the resulting u32 opcode always have the upper half set to
0.

However, having the upper half of instr_mask in the undef_hook set to 0
masks out the upper half of all thumb instructions - both T16 and T32.
This results in trapped T32 instructions with the lower half-word equal
to the T16 encoding of setend (b650) being matched, even though the upper
half-word is not 0000 and thus indicates a T32 opcode.

An example of such a T32 instruction is eaa0b650, which should raise a
SIGILL since T32 instructions with an eaa prefix are unallocated as per
Arm ARM, but instead works as a SETEND because the second half-word is set
to b650.

This patch fixes the issue by extending instr_mask to include the
upper u32 half, which will still match T16 instructions where the upper
half is 0, but not T32 instructions.

Fixes: 2d888f48e056 ("arm64: Emulate SETEND for AArch32 tasks")
Cc: &lt;stable@vger.kernel.org&gt; # 4.0.x-
Reviewed-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Signed-off-by: Fredrik Strupe &lt;fredrik@strupe.net&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: ti: k3-am65: Add clocks to dwc3 nodes</title>
<updated>2020-04-17T14:12:13+00:00</updated>
<author>
<name>Dave Gerlach</name>
<email>d-gerlach@ti.com</email>
</author>
<published>2020-03-11T14: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=0e648482b91d6880531e83dac7f7fc97e3c7d060'/>
<id>urn:sha1:0e648482b91d6880531e83dac7f7fc97e3c7d060</id>
<content type='text'>
commit a81e5442d796ccfa2cc97d205a5477053264d978 upstream.

The TI sci-clk driver can scan the DT for all clocks provided by system
firmware and does this by checking the clocks property of all nodes, so
we must add this to the dwc3 nodes so USB clocks are available.

Without this USB does not work with latest system firmware i.e.
[    1.714662] clk: couldn't get parent clock 0 for /interconnect@100000/dwc3@4020000

Fixes: cc54a99464ccd ("arm64: dts: ti: k3-am6: add USB suppor")
Signed-off-by: Dave Gerlach &lt;d-gerlach@ti.com&gt;
Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Cc: stable@kernel.org
Signed-off-by: Tero Kristo &lt;t-kristo@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: allwinner: h5: Fix PMU compatible</title>
<updated>2020-04-17T14:12:10+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2020-02-10T09:55:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4b865c9b31522c9e264f90dc287736da3652eb18'/>
<id>urn:sha1:4b865c9b31522c9e264f90dc287736da3652eb18</id>
<content type='text'>
commit 4ae7a3c3d7d31260f690d8d658f0365f3eca67a2 upstream.

The commit c35a516a4618 ("arm64: dts: allwinner: H5: Add PMU node")
introduced support for the PMU found on the Allwinner H5. However, the
binding only allows for a single compatible, while the patch was adding
two.

Make sure we follow the binding.

Fixes: c35a516a4618 ("arm64: dts: allwinner: H5: Add PMU node")
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: allwinner: h6: Fix PMU compatible</title>
<updated>2020-04-17T14:12:10+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2020-02-10T09:56: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=7e0bf74c0d74d5092ed430c156420259540b1001'/>
<id>urn:sha1:7e0bf74c0d74d5092ed430c156420259540b1001</id>
<content type='text'>
commit 4c7eeb9af3e41ae7d840977119c58f3bbb3f4f59 upstream.

The commit 7aa9b9eb7d6a ("arm64: dts: allwinner: H6: Add PMU mode")
introduced support for the PMU found on the Allwinner H6. However, the
binding only allows for a single compatible, while the patch was adding
two.

Make sure we follow the binding.

Fixes: 7aa9b9eb7d6a ("arm64: dts: allwinner: H6: Add PMU mode")
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: ls1046ardb: set RGMII interfaces to RGMII_ID mode</title>
<updated>2020-04-02T13:09:55+00:00</updated>
<author>
<name>Madalin Bucur</name>
<email>madalin.bucur@oss.nxp.com</email>
</author>
<published>2020-03-16T12:05:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f500e8136e67161eb133c33a14c41918e20aa978'/>
<id>urn:sha1:f500e8136e67161eb133c33a14c41918e20aa978</id>
<content type='text'>
commit d79e9d7c1e4ba5f95f2ff3541880c40ea9722212 upstream.

The correct setting for the RGMII ports on LS1046ARDB is to
enable delay on both Rx and Tx so the interface mode used must
be PHY_INTERFACE_MODE_RGMII_ID.

Since commit 1b3047b5208a80 ("net: phy: realtek: add support for
configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver
has control over the RGMII RX delay and it is disabling it for
RGMII_TXID. The LS1046ARDB uses two such PHYs in RGMII_ID mode but
in the device tree the mode was described as "rgmii".

Changing the phy-connection-type to "rgmii-id" to address the issue.

Fixes: 3fa395d2c48a ("arm64: dts: add LS1046A DPAA FMan nodes")
Signed-off-by: Madalin Bucur &lt;madalin.bucur@oss.nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: ls1043a-rdb: correct RGMII delay mode to rgmii-id</title>
<updated>2020-04-02T13:09:55+00:00</updated>
<author>
<name>Madalin Bucur</name>
<email>madalin.bucur@oss.nxp.com</email>
</author>
<published>2020-03-16T12:05: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=36514a23f1bb6d1b02dc7a15e7a8cb2f4b3401ca'/>
<id>urn:sha1:36514a23f1bb6d1b02dc7a15e7a8cb2f4b3401ca</id>
<content type='text'>
commit 4022d808c45277693ea86478fab1f081ebf997e8 upstream.

The correct setting for the RGMII ports on LS1043ARDB is to
enable delay on both Rx and Tx so the interface mode used must
be PHY_INTERFACE_MODE_RGMII_ID.

Since commit 1b3047b5208a80 ("net: phy: realtek: add support for
configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver
has control over the RGMII RX delay and it is disabling it for
RGMII_TXID. The LS1043ARDB uses two such PHYs in RGMII_ID mode but
in the device tree the mode was described as "rgmii_txid".
This issue was not apparent at the time as the PHY driver took the
same action for RGMII_TXID and RGMII_ID back then but it became
visible (RX no longer working) after the above patch.

Changing the phy-connection-type to "rgmii-id" to address the issue.

Fixes: bf02f2ffe59c ("arm64: dts: add LS1043A DPAA FMan support")
Signed-off-by: Madalin Bucur &lt;madalin.bucur@oss.nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: alternative: fix build with clang integrated assembler</title>
<updated>2020-04-02T13:09:53+00:00</updated>
<author>
<name>Ilie Halip</name>
<email>ilie.halip@gmail.com</email>
</author>
<published>2020-03-19T21:45:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4fba4e808c0b357fd011fa0e84a81bf9af4b97cf'/>
<id>urn:sha1:4fba4e808c0b357fd011fa0e84a81bf9af4b97cf</id>
<content type='text'>
commit 6f5459da2b8736720afdbd67c4bd2d1edba7d0e3 upstream.

Building an arm64 defconfig with clang's integrated assembler, this error
occurs:
    &lt;instantiation&gt;:2:2: error: unrecognized instruction mnemonic
     _ASM_EXTABLE 9999b, 9f
     ^
    arch/arm64/mm/cache.S:50:1: note: while in macro instantiation
    user_alt 9f, "dc cvau, x4", "dc civac, x4", 0
    ^

While GNU as seems fine with case-sensitive macro instantiations, clang
doesn't, so use the actual macro name (_asm_extable) as in the rest of
the file.

Also checked that the generated assembly matches the GCC output.

Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Tested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Fixes: 290622efc76e ("arm64: fix "dc cvau" cache operation on errata-affected core")
Link: https://github.com/ClangBuiltLinux/linux/issues/924
Signed-off-by: Ilie Halip &lt;ilie.halip@gmail.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
