<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/arch/arm, branch v4.4.183</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.183</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.183'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-06-22T06:18:22Z</updated>
<entry>
<title>ARM: exynos: Fix undefined instruction during Exynos5422 resume</title>
<updated>2019-06-22T06:18:22Z</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2019-02-18T14:34:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=38fbd5c2d5721f6f0a40d8bf6e58e9a05df56c7e'/>
<id>urn:sha1:38fbd5c2d5721f6f0a40d8bf6e58e9a05df56c7e</id>
<content type='text'>
[ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]

During early system resume on Exynos5422 with performance counters enabled
the following kernel oops happens:

    Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 0 PID: 1433 Comm: bash Tainted: G        W         5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
    Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    ...
    Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
    Control: 10c5387d  Table: 4451006a  DAC: 00000051
    Process bash (pid: 1433, stack limit = 0xb7e0e22f)
    ...
    (reset_ctrl_regs) from [&lt;c0112ad0&gt;] (dbg_cpu_pm_notify+0x1c/0x24)
    (dbg_cpu_pm_notify) from [&lt;c014c840&gt;] (notifier_call_chain+0x44/0x84)
    (notifier_call_chain) from [&lt;c014cbc0&gt;] (__atomic_notifier_call_chain+0x7c/0x128)
    (__atomic_notifier_call_chain) from [&lt;c01ffaac&gt;] (cpu_pm_notify+0x30/0x54)
    (cpu_pm_notify) from [&lt;c055116c&gt;] (syscore_resume+0x98/0x3f4)
    (syscore_resume) from [&lt;c0189350&gt;] (suspend_devices_and_enter+0x97c/0xe74)
    (suspend_devices_and_enter) from [&lt;c0189fb8&gt;] (pm_suspend+0x770/0xc04)
    (pm_suspend) from [&lt;c0187740&gt;] (state_store+0x6c/0xcc)
    (state_store) from [&lt;c09fa698&gt;] (kobj_attr_store+0x14/0x20)
    (kobj_attr_store) from [&lt;c030159c&gt;] (sysfs_kf_write+0x4c/0x50)
    (sysfs_kf_write) from [&lt;c0300620&gt;] (kernfs_fop_write+0xfc/0x1e0)
    (kernfs_fop_write) from [&lt;c0282be8&gt;] (__vfs_write+0x2c/0x160)
    (__vfs_write) from [&lt;c0282ea4&gt;] (vfs_write+0xa4/0x16c)
    (vfs_write) from [&lt;c0283080&gt;] (ksys_write+0x40/0x8c)
    (ksys_write) from [&lt;c0101000&gt;] (ret_fast_syscall+0x0/0x28)

Undefined instruction is triggered during CP14 reset, because bits: #16
(Secure privileged invasive debug disabled) and #17 (Secure privileged
noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN
and SPIDEN lines, which are provided by Secure JTAG hardware block. That
block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422
boots on cluster 1 (LITTLE/KFC).

To fix this issue it is enough to turn on the power on the cluster 0 for
a while. This lets the Secure JTAG block to propagate the needed signals
to LITTLE/KFC cores and change their DSCR.

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa</title>
<updated>2019-06-22T06:18:21Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzk@kernel.org</email>
</author>
<published>2019-03-14T20:02:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=113a78a0a537889f7353d8afe4c0978209425252'/>
<id>urn:sha1:113a78a0a537889f7353d8afe4c0978209425252</id>
<content type='text'>
[ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]

The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
off by Linux kernel as unused.  However they supply critical parts of
SoC so they should be always on:

1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
   RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
   lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
   It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
   VDDQ_GPIO (gpm7, gpy7).
   The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
   marking it "always-on" only reflects its real status.

2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
   memory and Mali (G3D).

Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA</title>
<updated>2019-06-22T06:18:21Z</updated>
<author>
<name>Andrey Smirnov</name>
<email>andrew.smirnov@gmail.com</email>
</author>
<published>2019-03-29T06:49:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=100468652e5a1bc642c7c4e06f2e29701417387e'/>
<id>urn:sha1:100468652e5a1bc642c7c4e06f2e29701417387e</id>
<content type='text'>
[ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]

Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
clock to determine if it needs to configure the IP block as operating
at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
ratio is 1:1 which results in broken SDMA funtionality(this at least
breaks RAVE SP serdev driver on RDU2). Fix the code to specify
IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
clock ratio.

Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Reviewed-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Angus Ainslie (Purism) &lt;angus@akkea.ca&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Adam Ford &lt;aford173@gmail.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA</title>
<updated>2019-06-22T06:18:20Z</updated>
<author>
<name>Andrey Smirnov</name>
<email>andrew.smirnov@gmail.com</email>
</author>
<published>2019-03-29T06:49:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=927d2be77e6c1f682dc451382035a23afffefb98'/>
<id>urn:sha1:927d2be77e6c1f682dc451382035a23afffefb98</id>
<content type='text'>
[ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]

Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
clock to determine if it needs to configure the IP block as operating
at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that
ratio is 1:1 which results in broken SDMA funtionality. Fix the code
to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
incorrect clock ratio.

Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Cc: Angus Ainslie (Purism) &lt;angus@akkea.ca&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA</title>
<updated>2019-06-22T06:18:20Z</updated>
<author>
<name>Andrey Smirnov</name>
<email>andrew.smirnov@gmail.com</email>
</author>
<published>2019-03-29T06:49:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8aee025af2802333e24cc7d193e49fb60db422aa'/>
<id>urn:sha1:8aee025af2802333e24cc7d193e49fb60db422aa</id>
<content type='text'>
[ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]

Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
clock to determine if it needs to configure the IP block as operating
at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
ratio is 1:1 which results in broken SDMA funtionality. Fix the code
to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
incorrect clock ratio.

Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Cc: Angus Ainslie (Purism) &lt;angus@akkea.ca&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: Ensure vcpu target is unset on reset failure</title>
<updated>2019-06-11T10:23:49Z</updated>
<author>
<name>Andrew Jones</name>
<email>drjones@redhat.com</email>
</author>
<published>2019-04-04T17:42:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dd37fa44dffa441984c46c285d817018c4d28814'/>
<id>urn:sha1:dd37fa44dffa441984c46c285d817018c4d28814</id>
<content type='text'>
[ Upstream commit 811328fc3222f7b55846de0cd0404339e2e1e6d7 ]

A failed KVM_ARM_VCPU_INIT should not set the vcpu target,
as the vcpu target is used by kvm_vcpu_initialized() to
determine if other vcpu ioctls may proceed. We need to set
the target before calling kvm_reset_vcpu(), but if that call
fails, we should then unset it and clear the feature bitmap
while we're at it.

Signed-off-by: Andrew Jones &lt;drjones@redhat.com&gt;
[maz: Simplified patch, completed commit message]
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: arm/aes-neonbs - don't access already-freed walk.iv</title>
<updated>2019-06-11T10:23:41Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-04-10T06:46:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cd042379c6ad4a9420dcea73036c16bbd37f82ca'/>
<id>urn:sha1:cd042379c6ad4a9420dcea73036c16bbd37f82ca</id>
<content type='text'>
commit 767f015ea0b7ab9d60432ff6cd06b664fd71f50f upstream.

If the user-provided IV needs to be aligned to the algorithm's
alignmask, then skcipher_walk_virt() copies the IV into a new aligned
buffer walk.iv.  But skcipher_walk_virt() can fail afterwards, and then
if the caller unconditionally accesses walk.iv, it's a use-after-free.

arm32 xts-aes-neonbs doesn't set an alignmask, so currently it isn't
affected by this despite unconditionally accessing walk.iv.  However
this is more subtle than desired, and it was actually broken prior to
the alignmask being removed by commit cc477bf64573 ("crypto: arm/aes -
replace bit-sliced OpenSSL NEON code").  Thus, update xts-aes-neonbs to
start checking the return value of skcipher_walk_virt().

Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
Cc: &lt;stable@vger.kernel.org&gt; # v3.13+
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>ARM: exynos: Fix a leaked reference by adding missing of_node_put</title>
<updated>2019-06-11T10:23:35Z</updated>
<author>
<name>Wen Yang</name>
<email>wen.yang99@zte.com.cn</email>
</author>
<published>2019-03-05T11:33:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f7dee0816e5d71cfdf924e21f4a21f51fd109b89'/>
<id>urn:sha1:f7dee0816e5d71cfdf924e21f4a21f51fd109b89</id>
<content type='text'>
commit 629266bf7229cd6a550075f5961f95607b823b59 upstream.

The call to of_get_next_child returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with warnings like:
    arch/arm/mach-exynos/firmware.c:201:2-8: ERROR: missing of_node_put;
        acquired a node pointer with refcount incremented on line 193,
        but without a corresponding object release within this function.

Cc: stable@vger.kernel.org
Signed-off-by: Wen Yang &lt;wen.yang99@zte.com.cn&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: iop: don't use using 64-bit DMA masks</title>
<updated>2019-05-16T17:45:02Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2019-03-25T15:50:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3401512b7831b32e720c945d924062a8c50bfdcb'/>
<id>urn:sha1:3401512b7831b32e720c945d924062a8c50bfdcb</id>
<content type='text'>
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]

clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:

 arch/arm/mach-iop13xx/setup.c:303:35: error: shift count &gt;= width of type [-Werror,-Wshift-count-overflow]
 static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64);
                                  ^~~~~~~~~~~~~~~~
 include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
 #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL&lt;&lt;(n))-1))
                                                      ^ ~~~

The ones in iop shouldn't really be 64 bit masks, so changing them
to what the driver can support avoids the warning.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: orion: don't use using 64-bit DMA masks</title>
<updated>2019-05-16T17:45:02Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2019-03-25T15:50:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=03fd6e162398092db840bb8cf0647e3348225fed'/>
<id>urn:sha1:03fd6e162398092db840bb8cf0647e3348225fed</id>
<content type='text'>
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]

clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:

arch/arm/plat-orion/common.c:625:29: error: shift count &gt;= width of type [-Werror,-Wshift-count-overflow]
                .coherent_dma_mask      = DMA_BIT_MASK(64),
                                          ^~~~~~~~~~~~~~~~
include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
 #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL&lt;&lt;(n))-1))

The ones in orion shouldn't really be 64 bit masks, so changing them
to what the driver can support avoids the warning.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
