<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/arch/arm64, branch linux-5.8.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.8.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.8.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2020-11-01T11:45:37+00:00</updated>
<entry>
<title>arm64: link with -z norelro regardless of CONFIG_RELOCATABLE</title>
<updated>2020-11-01T11:45:37+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2020-10-16T17:53:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4b0a9591dd78125550a158c300da0e470e41629f'/>
<id>urn:sha1:4b0a9591dd78125550a158c300da0e470e41629f</id>
<content type='text'>
commit 3b92fa7485eba16b05166fddf38ab42f2ff6ab95 upstream.

With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n,
CONFIG_RELOCATABLE=n, we observe the following failure when trying to
link the kernel image with LD=ld.lld:

error: section: .exit.data is not contiguous with other relro sections

ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This
was previously fixed, but only for CONFIG_RELOCATABLE=y.

Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201016175339.2429280-1-ndesaulniers@google.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: Run ARCH_WORKAROUND_2 enabling code on all CPUs</title>
<updated>2020-11-01T11:45:37+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-07-16T16:11:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dfaa0f7d0832fdfd915f1bab5887323401d9b021'/>
<id>urn:sha1:dfaa0f7d0832fdfd915f1bab5887323401d9b021</id>
<content type='text'>
commit 39533e12063be7f55e3d6ae21ffe067799d542a4 upstream.

Commit 606f8e7b27bf ("arm64: capabilities: Use linear array for
detection and verification") changed the way we deal with per-CPU errata
by only calling the .matches() callback until one CPU is found to be
affected. At this point, .matches() stop being called, and .cpu_enable()
will be called on all CPUs.

This breaks the ARCH_WORKAROUND_2 handling, as only a single CPU will be
mitigated.

In order to address this, forcefully call the .matches() callback from a
.cpu_enable() callback, which brings us back to the original behaviour.

Fixes: 606f8e7b27bf ("arm64: capabilities: Use linear array for detection and verification")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: Run ARCH_WORKAROUND_1 enabling code on all CPUs</title>
<updated>2020-11-01T11:45:37+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-07-16T16:11:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0ccd5c2c60e0eba3f9cf624fb6b4d28c4aa8c84a'/>
<id>urn:sha1:0ccd5c2c60e0eba3f9cf624fb6b4d28c4aa8c84a</id>
<content type='text'>
commit 18fce56134c987e5b4eceddafdbe4b00c07e2ae1 upstream.

Commit 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack
thereof") changed the way we deal with ARCH_WORKAROUND_1, by moving most
of the enabling code to the .matches() callback.

This has the unfortunate effect that the workaround gets only enabled on
the first affected CPU, and no other.

In order to address this, forcefully call the .matches() callback from a
.cpu_enable() callback, which brings us back to the original behaviour.

Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: dts: zynqmp: Remove additional compatible string for i2c IPs</title>
<updated>2020-10-29T09:08:15+00:00</updated>
<author>
<name>Michal Simek</name>
<email>michal.simek@xilinx.com</email>
</author>
<published>2020-08-24T08:59:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=68d2900fc0c82cf92aab1057c1c022c15d5008a9'/>
<id>urn:sha1:68d2900fc0c82cf92aab1057c1c022c15d5008a9</id>
<content type='text'>
[ Upstream commit 35292518cb0a626fcdcabf739aed75060a018ab5 ]

DT binding permits only one compatible string which was decribed in past by
commit 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq
Ultrascale+ MPSoC").
The commit aea37006e183 ("dt-bindings: i2c: cadence: Migrate i2c-cadence
documentation to YAML") has converted binding to yaml and the following
issues is reported:
...: i2c@ff030000: compatible: Additional items are not allowed
('cdns,i2c-r1p10' was unexpected)
	From schema:
.../Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml fds
...: i2c@ff030000: compatible: ['cdns,i2c-r1p14', 'cdns,i2c-r1p10'] is too
long

The commit c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string")
has added the second compatible string but without removing origin one.
The patch is only keeping one compatible string "cdns,i2c-r1p14".

Fixes: c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string")
Signed-off-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Link: https://lore.kernel.org/r/cc294ae1a79ef845af6809ddb4049f0c0f5bb87a.1598259551.git.michal.simek@xilinx.com
Reviewed-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: actions: limit address range for pinctrl node</title>
<updated>2020-10-29T09:08:14+00:00</updated>
<author>
<name>Amit Singh Tomar</name>
<email>amittomer25@gmail.com</email>
</author>
<published>2020-07-19T17:42:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52c37b7f0e04c84a6ab2b703c1d42408c5f2a81f'/>
<id>urn:sha1:52c37b7f0e04c84a6ab2b703c1d42408c5f2a81f</id>
<content type='text'>
[ Upstream commit 4bb1eb3cd4bd6241d5e5f99bbfd801ea5a007b6c ]

After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for
Actions Semi S700") following error has been observed while booting
Linux on Cubieboard7-lite(based on S700 SoC).

[    0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for
resource [mem 0xe01b0000-0xe01b0fff]
[    0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16

This is due to the fact that memory range for "sps" power domain controller
clashes with pinctrl.

One way to fix it, is to limit pinctrl address range which is safe
to do as current pinctrl driver uses address range only up to 0x100.

This commit limits the pinctrl address range to 0x100 so that it doesn't
conflict with sps range.

Fixes: 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions
Semi S700")

Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Suggested-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Amit Singh Tomar &lt;amittomer25@gmail.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: mt8173: elm: Fix nor_flash node property</title>
<updated>2020-10-29T09:08:14+00:00</updated>
<author>
<name>Hsin-Yi Wang</name>
<email>hsinyi@chromium.org</email>
</author>
<published>2020-07-27T07:41:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=251ab5b1f8e86908388860c0bee4b6357b870ce7'/>
<id>urn:sha1:251ab5b1f8e86908388860c0bee4b6357b870ce7</id>
<content type='text'>
[ Upstream commit 1276be23fd53e1c4e752966d0eab42aa54a343da ]

bus-width and non-removable is not used by the driver.
max-frequency should be spi-max-frequency for flash node.

Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board")
Reported-by: Nicolas Boichat &lt;drinkcat@chromium.org&gt;
Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Reviewed-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Link: https://lore.kernel.org/r/20200727074124.3779237-1-hsinyi@chromium.org
Signed-off-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels</title>
<updated>2020-10-29T09:08:13+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2020-09-17T13:21:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6e4cd77c02356fbe7d0e87bed95114b8588a5086'/>
<id>urn:sha1:6e4cd77c02356fbe7d0e87bed95114b8588a5086</id>
<content type='text'>
[ Upstream commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 ]

According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be
used with SYS-DMAC0 on R-Car E3.

Fixes: 62c0056f1c3eb15d ("arm64: dts: renesas: r8a774c0: Add MSIOF nodes")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/20200917132117.8515-3-geert+renesas@glider.be
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: renesas: r8a77990: Fix MSIOF1 DMA channels</title>
<updated>2020-10-29T09:08:13+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2020-09-17T13:21:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5c91fc9a6d163d7a6c6a4411fe3f847156f68bfe'/>
<id>urn:sha1:5c91fc9a6d163d7a6c6a4411fe3f847156f68bfe</id>
<content type='text'>
[ Upstream commit 453802c463abd003a7c38ffbc90b67ba162335b6 ]

According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be
used with SYS-DMAC0 on R-Car E3.

Fixes: 8517042060b55a37 ("arm64: dts: renesas: r8a77990: Add DMA properties to MSIOF nodes")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/20200917132117.8515-2-geert+renesas@glider.be
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: qcom: msm8916: Fix MDP/DSI interrupts</title>
<updated>2020-10-29T09:08:13+00:00</updated>
<author>
<name>Stephan Gerhold</name>
<email>stephan@gerhold.net</email>
</author>
<published>2020-09-15T07:12: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=e8bd4ce4e8779bf9de1c41c93abf0f9f37798dfb'/>
<id>urn:sha1:e8bd4ce4e8779bf9de1c41c93abf0f9f37798dfb</id>
<content type='text'>
[ Upstream commit 027cca9eb5b450c3f6bb916ba999144c2ec23cb7 ]

The mdss node sets #interrupt-cells = &lt;1&gt;, so its interrupts
should be referenced using a single cell (in this case: only the
interrupt number).

However, right now the mdp/dsi node both have two interrupt cells
set, e.g. interrupts = &lt;4 0&gt;. The 0 is probably meant to say
IRQ_TYPE_NONE (= 0), but with #interrupt-cells = &lt;1&gt; this is
actually interpreted as a second interrupt line.

Remove the IRQ flags from both interrupts to fix this.

Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Link: https://lore.kernel.org/r/20200915071221.72895-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: qcom: pm8916: Remove invalid reg size from wcd_codec</title>
<updated>2020-10-29T09:08:13+00:00</updated>
<author>
<name>Stephan Gerhold</name>
<email>stephan@gerhold.net</email>
</author>
<published>2020-09-15T07:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=26a8ac2d65121cbf1f0c838ca1a5b14423e67d76'/>
<id>urn:sha1:26a8ac2d65121cbf1f0c838ca1a5b14423e67d76</id>
<content type='text'>
[ Upstream commit c2f0cbb57dbac6da3d38b47b5b96de0fe4e23884 ]

Tha parent node of "wcd_codec" specifies #address-cells = &lt;1&gt;
and #size-cells = &lt;0&gt;, which means that each resource should be
described by one cell for the address and size omitted.

However, wcd_codec currently lists 0x200 as second cell (probably
the size of the resource). When parsing this would be treated like
another memory resource - which is entirely wrong.

To quote the device tree specification [1]:
  "If the parent node specifies a value of 0 for #size-cells,
   the length field in the value of reg shall be omitted."

[1]: https://www.devicetree.org/specifications/

Fixes: 5582fcb3829f ("arm64: dts: apq8016-sbc: add analog audio support with multicodec")
Signed-off-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Link: https://lore.kernel.org/r/20200915071221.72895-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
