<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm, branch v4.4.23</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: smc91x: fix SMC accesses</title>
<updated>2016-09-30T08:18:37+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2016-08-27T16:33:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8c945f5aac28a81f20f6a5208a6ccab43b8e7a89'/>
<id>8c945f5aac28a81f20f6a5208a6ccab43b8e7a89</id>
<content type='text'>
[ Upstream commit 2fb04fdf30192ff1e2b5834e9b7745889ea8bbcb ]

Commit b70661c70830 ("net: smc91x: use run-time configuration on all ARM
machines") broke some ARM platforms through several mistakes.  Firstly,
the access size must correspond to the following rule:

(a) at least one of 16-bit or 8-bit access size must be supported
(b) 32-bit accesses are optional, and may be enabled in addition to
    the above.

Secondly, it provides no emulation of 16-bit accesses, instead blindly
making 16-bit accesses even when the platform specifies that only 8-bit
is supported.

Reorganise smc91x.h so we can make use of the existing 16-bit access
emulation already provided - if 16-bit accesses are supported, use
16-bit accesses directly, otherwise if 8-bit accesses are supported,
use the provided 16-bit access emulation.  If neither, BUG().  This
exactly reflects the driver behaviour prior to the commit being fixed.

Since the conversion incorrectly cut down the available access sizes on
several platforms, we also need to go through every platform and fix up
the overly-restrictive access size: Arnd assumed that if a platform can
perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
size needed to be specified - not so, all available access sizes must
be specified.

This likely fixes some performance regressions in doing this: if a
platform does not support 8-bit accesses, 8-bit accesses have been
emulated by performing a 16-bit read-modify-write access.

Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
accesses, which was broken by the original commit.

Fixes: b70661c70830 ("net: smc91x: use run-time configuration on all ARM machines")
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Tested-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2fb04fdf30192ff1e2b5834e9b7745889ea8bbcb ]

Commit b70661c70830 ("net: smc91x: use run-time configuration on all ARM
machines") broke some ARM platforms through several mistakes.  Firstly,
the access size must correspond to the following rule:

(a) at least one of 16-bit or 8-bit access size must be supported
(b) 32-bit accesses are optional, and may be enabled in addition to
    the above.

Secondly, it provides no emulation of 16-bit accesses, instead blindly
making 16-bit accesses even when the platform specifies that only 8-bit
is supported.

Reorganise smc91x.h so we can make use of the existing 16-bit access
emulation already provided - if 16-bit accesses are supported, use
16-bit accesses directly, otherwise if 8-bit accesses are supported,
use the provided 16-bit access emulation.  If neither, BUG().  This
exactly reflects the driver behaviour prior to the commit being fixed.

Since the conversion incorrectly cut down the available access sizes on
several platforms, we also need to go through every platform and fix up
the overly-restrictive access size: Arnd assumed that if a platform can
perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
size needed to be specified - not so, all available access sizes must
be specified.

This likely fixes some performance regressions in doing this: if a
platform does not support 8-bit accesses, 8-bit accesses have been
emulated by performing a 16-bit read-modify-write access.

Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
accesses, which was broken by the original commit.

Fixes: b70661c70830 ("net: smc91x: use run-time configuration on all ARM machines")
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Tested-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: arm/aes-ctr - fix NULL dereference in tail processing</title>
<updated>2016-09-30T08:18:34+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2016-09-13T08:48:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9246fd26f99d70c81d3ec90a4b8dece0c2d7b930'/>
<id>9246fd26f99d70c81d3ec90a4b8dece0c2d7b930</id>
<content type='text'>
commit f82e90b28654804ab72881d577d87c3d5c65e2bc upstream.

The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.

However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes &gt; 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.

Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Reported-by: xiakaixu &lt;xiakaixu@huawei.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f82e90b28654804ab72881d577d87c3d5c65e2bc upstream.

The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.

However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes &gt; 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.

Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Reported-by: xiakaixu &lt;xiakaixu@huawei.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: STiH407-family: Provide interconnect clock for consumption in ST SDHCI</title>
<updated>2016-09-24T08:07:40+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee.jones@linaro.org</email>
</author>
<published>2016-09-08T09:11:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e33981e6101298649fc47b9a554435c1ee96be09'/>
<id>e33981e6101298649fc47b9a554435c1ee96be09</id>
<content type='text'>
commit 78567f135d9bbbaf4538f63656d3e4d957c35fe9 upstream.

The STiH4{07,10} platform contains some interconnect clocks which are used
by various IPs.  If these clocks aren't handled correctly by ST's SDHCI
driver MMC will break and the following output can be observed:

[   13.916949] mmc0: Timeout waiting for hardware interrupt.
[   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
[   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
[   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
[   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
[   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
[   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
[   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
[   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
[   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
[   13.992252] sdhci: Host ctl2: 0x00000000
[   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
[   14.001990] sdhci: ===========================================
[   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.

Tested-by: Peter Griffin &lt;peter.griffin@linaro.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Acked-by: Patrice Chotard &lt;patrice.chotard@st.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 78567f135d9bbbaf4538f63656d3e4d957c35fe9 upstream.

The STiH4{07,10} platform contains some interconnect clocks which are used
by various IPs.  If these clocks aren't handled correctly by ST's SDHCI
driver MMC will break and the following output can be observed:

[   13.916949] mmc0: Timeout waiting for hardware interrupt.
[   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
[   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
[   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
[   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
[   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
[   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
[   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
[   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
[   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
[   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
[   13.992252] sdhci: Host ctl2: 0x00000000
[   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
[   14.001990] sdhci: ===========================================
[   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.

Tested-by: Peter Griffin &lt;peter.griffin@linaro.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Acked-by: Patrice Chotard &lt;patrice.chotard@st.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: overo: fix gpmc nand on boards with ethernet</title>
<updated>2016-09-24T08:07:40+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2016-08-15T16:10:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ead4f548131fec903b4b2e704bc3149275415e79'/>
<id>ead4f548131fec903b4b2e704bc3149275415e79</id>
<content type='text'>
commit 153b58ea932b2d0642fa5cd41c93bb0555f3f09b upstream.

The gpmc ranges property for NAND at CS0 was being overridden by later
includes that defined gpmc ethernet nodes, effectively breaking NAND on
these systems:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

Instead of redefining the NAND range in every such dtsi, define all
currently used ranges in omap3-overo-base.dtsi.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 153b58ea932b2d0642fa5cd41c93bb0555f3f09b upstream.

The gpmc ranges property for NAND at CS0 was being overridden by later
includes that defined gpmc ethernet nodes, effectively breaking NAND on
these systems:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

Instead of redefining the NAND range in every such dtsi, define all
currently used ranges in omap3-overo-base.dtsi.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: overo: fix gpmc nand cs0 range</title>
<updated>2016-09-24T08:07:40+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2016-08-15T16:10:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e2b1bd8508276be1e53be235f6f50d7591c593cb'/>
<id>e2b1bd8508276be1e53be235f6f50d7591c593cb</id>
<content type='text'>
commit 5e0568dfbfb8c13cdb69c9fd06d600593ad4b430 upstream.

The gpmc ranges property for NAND at CS0 has been broken since it was
first added.

This currently prevents the nand gpmc child node from being probed:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

and consequently the NAND device from being registered.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5e0568dfbfb8c13cdb69c9fd06d600593ad4b430 upstream.

The gpmc ranges property for NAND at CS0 has been broken since it was
first added.

This currently prevents the nand gpmc child node from being probed:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

and consequently the NAND device from being registered.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: imx6qdl: Fix SPDIF regression</title>
<updated>2016-09-24T08:07:40+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@nxp.com</email>
</author>
<published>2016-08-31T13:56:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c89714b57dce6312d2d7af36d6c4fc0954b9c0d'/>
<id>9c89714b57dce6312d2d7af36d6c4fc0954b9c0d</id>
<content type='text'>
commit f065e9e4addd75c21bb976bb2558648bf4f61de6 upstream.

Commit 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
changed many more clocks than only the SPDIF core clock as stated in
the commit message.

The MLB clock has been added and this causes SPDIF regression as
reported by Xavi Drudis Ferran and also in this forum post:
https://forum.digikey.com/thread/34240

The MX6Q Reference Manual does not mention that MLB is a clock related
to SPDIF, so change it back to a dummy clock to restore SPDIF
functionality.

Thanks to Ambika for providing the fix at:
https://community.nxp.com/thread/387131

Fixes: 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
Reported-by: Xavi Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Tested-by:  Xavi Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f065e9e4addd75c21bb976bb2558648bf4f61de6 upstream.

Commit 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
changed many more clocks than only the SPDIF core clock as stated in
the commit message.

The MLB clock has been added and this causes SPDIF regression as
reported by Xavi Drudis Ferran and also in this forum post:
https://forum.digikey.com/thread/34240

The MX6Q Reference Manual does not mention that MLB is a clock related
to SPDIF, so change it back to a dummy clock to restore SPDIF
functionality.

Thanks to Ambika for providing the fix at:
https://community.nxp.com/thread/387131

Fixes: 833f2cbf7091 ("ARM: dts: imx6: change the core clock of spdif")
Reported-by: Xavi Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Tested-by:  Xavi Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP3: hwmod data: Add sysc information for DSI</title>
<updated>2016-09-24T08:07:40+00:00</updated>
<author>
<name>Sebastian Reichel</name>
<email>sre@kernel.org</email>
</author>
<published>2016-06-24T01:59:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=26dc6acdd70bbe1b3c901d4aa6ff54badcf3a94b'/>
<id>26dc6acdd70bbe1b3c901d4aa6ff54badcf3a94b</id>
<content type='text'>
commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream.

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.

Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream.

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.

Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: kirkwood: ib62x0: fix size of u-boot environment partition</title>
<updated>2016-09-24T08:07:39+00:00</updated>
<author>
<name>Simon Baatz</name>
<email>gmbnomis@gmail.com</email>
</author>
<published>2016-08-12T17:12:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5d04f50920f834a3761bd8cde8afaaffcfe5548'/>
<id>d5d04f50920f834a3761bd8cde8afaaffcfe5548</id>
<content type='text'>
commit a778937888867aac17a33887d1c429120790fbc2 upstream.

Commit 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment
partition") split the "u-boot" partition into "u-boot" and "u-boot
environment".  However, instead of the size of the environment, an offset
was given, resulting in overlapping partitions.

Signed-off-by: Simon Baatz &lt;gmbnomis@gmail.com&gt;
Fixes: 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition")
Cc: Jason Cooper &lt;jason@lakedaemon.net&gt;
Cc: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: Gregory Clement &lt;gregory.clement@free-electrons.com&gt;
Cc: Sebastian Hesselbarth &lt;sebastian.hesselbarth@gmail.com&gt;
Cc: Luka Perkov &lt;luka@openwrt.org&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a778937888867aac17a33887d1c429120790fbc2 upstream.

Commit 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment
partition") split the "u-boot" partition into "u-boot" and "u-boot
environment".  However, instead of the size of the environment, an offset
was given, resulting in overlapping partitions.

Signed-off-by: Simon Baatz &lt;gmbnomis@gmail.com&gt;
Fixes: 148c274ea644 ("ARM: kirkwood: ib62x0: add u-boot environment partition")
Cc: Jason Cooper &lt;jason@lakedaemon.net&gt;
Cc: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: Gregory Clement &lt;gregory.clement@free-electrons.com&gt;
Cc: Sebastian Hesselbarth &lt;sebastian.hesselbarth@gmail.com&gt;
Cc: Luka Perkov &lt;luka@openwrt.org&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx</title>
<updated>2016-09-24T08:07:39+00:00</updated>
<author>
<name>Anson Huang</name>
<email>Anson.Huang@nxp.com</email>
</author>
<published>2016-08-22T15:53:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c3aea8b87aff8c1a8677fa4993c672c262fa7a3c'/>
<id>c3aea8b87aff8c1a8677fa4993c672c262fa7a3c</id>
<content type='text'>
commit 8aade778f787305fdbfd3c1d54e6b583601b5902 upstream.

i.MX6SX has bypass PMIC ready function, as this function
is normally NOT enabled on the board design, so we need
to bypass the PMIC ready pin check during DSM mode resume
flow, otherwise, the internal DSM resume logic will be
waiting for this signal to be ready forever and cause
resume fail.

Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Fixes: ff843d621bfc ("ARM: imx: add suspend support for i.mx6sx")
Tested-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8aade778f787305fdbfd3c1d54e6b583601b5902 upstream.

i.MX6SX has bypass PMIC ready function, as this function
is normally NOT enabled on the board design, so we need
to bypass the PMIC ready pin check during DSM mode resume
flow, otherwise, the internal DSM resume logic will be
waiting for this signal to be ready forever and cause
resume fail.

Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Fixes: ff843d621bfc ("ARM: imx: add suspend support for i.mx6sx")
Tested-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: imx6: add missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul</title>
<updated>2016-09-24T08:07:39+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@nxp.com</email>
</author>
<published>2016-08-09T08:24:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11ba8bf8a0fc5df60520bf2f1011550e7cc2ef2e'/>
<id>11ba8bf8a0fc5df60520bf2f1011550e7cc2ef2e</id>
<content type='text'>
commit f5a49057c71433e35a4712ab8d8f00641b3e1ec0 upstream.

There is a missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul,
without it, the "standby" mode can't work well, the system can't be
resumed.

With this commit, the "standby" mode works well.

Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Cc: Anson Huang &lt;anson.huang@nxp.com&gt;
Fixes: ee4a5f838c84 ("ARM: imx: add suspend/resume support for i.mx6ul")
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f5a49057c71433e35a4712ab8d8f00641b3e1ec0 upstream.

There is a missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul,
without it, the "standby" mode can't work well, the system can't be
resumed.

With this commit, the "standby" mode works well.

Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Cc: Anson Huang &lt;anson.huang@nxp.com&gt;
Fixes: ee4a5f838c84 ("ARM: imx: add suspend/resume support for i.mx6ul")
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
