<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/arm, branch v4.2.5</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ARM: ux500: simplify secondary CPU boot</title>
<updated>2015-10-27T00:53:38+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2015-08-03T07:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f245eaa43ccd64e51a8e40a93d8a2e3b28a13b33'/>
<id>f245eaa43ccd64e51a8e40a93d8a2e3b28a13b33</id>
<content type='text'>
commit c00def71efd919e8ae835a25f4f4c80a4b2d36d3 upstream.

This removes a lot of ancient cruft from the Ux500 SMP boot.
Instead of the pen grab/release, just point the ROM to
secondary_boot() and start the second CPU there, then send
the IPI.

Use our own SMP enable method. This enables us to remove the
last static mapping and get both CPUs booting properly.

Tested this and it just works.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Kevin Hilman &lt;khilman@linaro.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 c00def71efd919e8ae835a25f4f4c80a4b2d36d3 upstream.

This removes a lot of ancient cruft from the Ux500 SMP boot.
Instead of the pen grab/release, just point the ROM to
secondary_boot() and start the second CPU there, then send
the IPI.

Use our own SMP enable method. This enables us to remove the
last static mapping and get both CPUs booting properly.

Tested this and it just works.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: fix usb pin control for imx-rex dts</title>
<updated>2015-10-22T21:49:17+00:00</updated>
<author>
<name>Felipe F. Tonello</name>
<email>eu@felipetonello.com</email>
</author>
<published>2015-09-16T17:40:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=47365d694f3bc4da33923aca12836b378caf4017'/>
<id>47365d694f3bc4da33923aca12836b378caf4017</id>
<content type='text'>
commit 0af822110871400908d5b6f83a8908c45f881d8f upstream.

This fixes a duplicated pin control causing this error:

imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
requested by regulators:regulator@2; cannot claim for 2184000.usb
imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
(MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e0000.iomuxc
imx_usb 2184000.usb: Error applying setting, reverse things
back
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
requested by regulators:regulator@1; cannot claim for 2184200.usb
imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
from group usbh1grp  on device 20e0000.iomuxc
imx_usb 2184200.usb: Error applying setting, reverse things
back

Signed-off-by: Felipe F. Tonello &lt;eu@felipetonello.com&gt;
Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support")
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 0af822110871400908d5b6f83a8908c45f881d8f upstream.

This fixes a duplicated pin control causing this error:

imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
requested by regulators:regulator@2; cannot claim for 2184000.usb
imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
(MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e0000.iomuxc
imx_usb 2184000.usb: Error applying setting, reverse things
back
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
requested by regulators:regulator@1; cannot claim for 2184200.usb
imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
from group usbh1grp  on device 20e0000.iomuxc
imx_usb 2184200.usb: Error applying setting, reverse things
back

Signed-off-by: Felipe F. Tonello &lt;eu@felipetonello.com&gt;
Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support")
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: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420</title>
<updated>2015-10-22T21:49:17+00:00</updated>
<author>
<name>Joonyoung Shim</name>
<email>jy0922.shim@samsung.com</email>
</author>
<published>2015-09-23T07:41:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c6c5b607f5c297cdd48fc45415895f55459944af'/>
<id>c6c5b607f5c297cdd48fc45415895f55459944af</id>
<content type='text'>
commit c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8 upstream.

The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock
CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0.

This wrong clock binding causes the problem that is blocked in iommu_map
function when IOMMU is enabled and exynos-drm driver tries to allocate
buffer via DMA mapping API on Odroid-XU3 board.

Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420")
Signed-off-by: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.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 c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8 upstream.

The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock
CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0.

This wrong clock binding causes the problem that is blocked in iommu_map
function when IOMMU is enabled and exynos-drm driver tries to allocate
buffer via DMA mapping API on Odroid-XU3 board.

Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420")
Signed-off-by: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Acked-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications</title>
<updated>2015-10-22T21:49:17+00:00</updated>
<author>
<name>Timo Sigurdsson</name>
<email>public_timo.s@silentcreek.de</email>
</author>
<published>2015-08-04T21:08:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7bff4cf150f415aaa5587c1f0d9b8b6f9b3011e2'/>
<id>7bff4cf150f415aaa5587c1f0d9b8b6f9b3011e2</id>
<content type='text'>
commit eaeef1ad9b6ea6df1d1220c254d9563da60cb9d1 upstream.

sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum
CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise
the voltage for the lowest operating point to 1.0 volts in order to stay
within the SoC specifications. It is an undervolted setting that isn't
stable across all SoCs and boards out there.

Fixes: d96b7161916f ("ARM: dts: sun7i: Add cpu clock reference and operating points to dtsi")
Signed-off-by: Timo Sigurdsson &lt;public_timo.s@silentcreek.de&gt;
Acked-by: Iain Paton &lt;ipaton0@gmail.com&gt;
Signed-off-by: Maxime Ripard &lt;maxime.ripard@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 eaeef1ad9b6ea6df1d1220c254d9563da60cb9d1 upstream.

sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum
CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise
the voltage for the lowest operating point to 1.0 volts in order to stay
within the SoC specifications. It is an undervolted setting that isn't
stable across all SoCs and boards out there.

Fixes: d96b7161916f ("ARM: dts: sun7i: Add cpu clock reference and operating points to dtsi")
Signed-off-by: Timo Sigurdsson &lt;public_timo.s@silentcreek.de&gt;
Acked-by: Iain Paton &lt;ipaton0@gmail.com&gt;
Signed-off-by: Maxime Ripard &lt;maxime.ripard@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: EXYNOS: reset Little cores when cpu is up</title>
<updated>2015-10-22T21:49:17+00:00</updated>
<author>
<name>Chanho Park</name>
<email>parkch98@gmail.com</email>
</author>
<published>2015-09-01T14:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0a6184931aeffe6fea5842fca8b06fd64105ee72'/>
<id>0a6184931aeffe6fea5842fca8b06fd64105ee72</id>
<content type='text'>
commit 833b5794e3303cc97a0d2d4ba97f26cc9d9b4b79 upstream.

The cpu booting of exynos5422 has been still broken since we discussed
it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird
reset code was founded exynos5420 octa cores series SoCs and only
required for the first boot core is the Little core (Cortex A7).
Some of the exynos5420 boards and all of the exynos5422 boards will require
this code.

There is two ways to check the little core is the first cpu. One is
checking GPG2CON[1] GPIO value and the other is checking the cluster
number of the first cpu. I selected the latter because it's more easier
than the former.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
[2] https://patchwork.kernel.org/patch/6782891/

Cc: Kevin Hilman &lt;khilman@kernel.org&gt;
Cc: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Cc: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Tested-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Chanho Park &lt;parkch98@gmail.com&gt;
[k.kozlowski: Adding stable for v4.1+, reformat comment]
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.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 833b5794e3303cc97a0d2d4ba97f26cc9d9b4b79 upstream.

The cpu booting of exynos5422 has been still broken since we discussed
it in last year[1]. This patch is inspired from Odroid XU3
code (Actually, it was from samsung exynos vendor kernel)[2]. This weird
reset code was founded exynos5420 octa cores series SoCs and only
required for the first boot core is the Little core (Cortex A7).
Some of the exynos5420 boards and all of the exynos5422 boards will require
this code.

There is two ways to check the little core is the first cpu. One is
checking GPG2CON[1] GPIO value and the other is checking the cluster
number of the first cpu. I selected the latter because it's more easier
than the former.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
[2] https://patchwork.kernel.org/patch/6782891/

Cc: Kevin Hilman &lt;khilman@kernel.org&gt;
Cc: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Cc: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Tested-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Chanho Park &lt;parkch98@gmail.com&gt;
[k.kozlowski: Adding stable for v4.1+, reformat comment]
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: pxa: ssp: Fix build error by removing originally incorrect DT binding</title>
<updated>2015-10-22T21:49:16+00:00</updated>
<author>
<name>Jarkko Nikula</name>
<email>jarkko.nikula@linux.intel.com</email>
</author>
<published>2015-09-07T07:23:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5903d8e4008f6c0d9b4dd2cce8c5debf0a31c1b2'/>
<id>5903d8e4008f6c0d9b4dd2cce8c5debf0a31c1b2</id>
<content type='text'>
commit b692cb83b14d2f741f513221f5f78042c674c2a9 upstream.

Commit 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") caused
build error here because it removed the type LPSS_SSP and I didn't notice
the type was used here too.

I believe commit a6e56c28a178 ("ARM: pxa: ssp: add DT bindings") added it
accidentally by copying all enum pxa_ssp_type types from
include/linux/pxa2xx_ssp.h even LPSS_SSP was for Intel LPSS SPI devices.

Fix the build error by removing this incorrect binding.

Fixes: 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types")
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Reported-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Signed-off-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&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 b692cb83b14d2f741f513221f5f78042c674c2a9 upstream.

Commit 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") caused
build error here because it removed the type LPSS_SSP and I didn't notice
the type was used here too.

I believe commit a6e56c28a178 ("ARM: pxa: ssp: add DT bindings") added it
accidentally by copying all enum pxa_ssp_type types from
include/linux/pxa2xx_ssp.h even LPSS_SSP was for Intel LPSS SPI devices.

Fix the build error by removing this incorrect binding.

Fixes: 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types")
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Reported-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Signed-off-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again</title>
<updated>2015-10-22T21:49:16+00:00</updated>
<author>
<name>Carl Frederik Werner</name>
<email>frederik@cfbw.eu</email>
</author>
<published>2015-09-02T01:07:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bb12eb239fcc1167735fb124a6778a4c15384682'/>
<id>bb12eb239fcc1167735fb124a6778a4c15384682</id>
<content type='text'>
commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 upstream.

Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.

According to the OMAP35x Technical Reference Manual
  CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
  CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
the pinmux address of gpio 170 must be 0x480021C6.

The former wrong address broke i2c3 (used by hdmi ddc), resulting in
kernel message:
  omap_i2c 48060000.i2c: controller timed out

Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information")
Signed-off-by: Carl Frederik Werner &lt;frederik@cfbw.eu&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 3a2fa775bd1d0579113666c1a2e37654a34018a0 upstream.

Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.

According to the OMAP35x Technical Reference Manual
  CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
  CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
the pinmux address of gpio 170 must be 0x480021C6.

The former wrong address broke i2c3 (used by hdmi ddc), resulting in
kernel message:
  omap_i2c 48060000.i2c: controller timed out

Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information")
Signed-off-by: Carl Frederik Werner &lt;frederik@cfbw.eu&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: omap5-uevm.dts: fix i2c5 pinctrl offsets</title>
<updated>2015-10-22T21:49:16+00:00</updated>
<author>
<name>Grazvydas Ignotas</name>
<email>notasas@gmail.com</email>
</author>
<published>2015-09-15T22:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=49107849eb0f2b98570a781ef537d415fcb130fc'/>
<id>49107849eb0f2b98570a781ef537d415fcb130fc</id>
<content type='text'>
commit 1dbdad75074d16c3e3005180f81a01cdc04a7872 upstream.

The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&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 1dbdad75074d16c3e3005180f81a01cdc04a7872 upstream.

The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&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: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints</title>
<updated>2015-10-22T21:49:16+00:00</updated>
<author>
<name>Doug Anderson</name>
<email>armlinux@m.disordat.com</email>
</author>
<published>2015-08-26T17:26:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d05cc8b34fc73e40ef9df0dfa9924e33990daaa2'/>
<id>d05cc8b34fc73e40ef9df0dfa9924e33990daaa2</id>
<content type='text'>
commit 7ae85dc7687c7e7119053d83d02c560ea217b772 upstream.

In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [&lt;c00133d4&gt;] (show_stack+0x20/0x24)
  (show_stack) from [&lt;c05400e8&gt;] (dump_stack+0x84/0xb8)
  (dump_stack) from [&lt;c004913c&gt;] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [&lt;c054065c&gt;] (__schedule+0x80/0x668)
  (__schedule) from [&lt;c0540cfc&gt;] (schedule+0xb8/0xd4)
  (schedule) from [&lt;c0543a3c&gt;] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [&lt;c05417c0&gt;] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [&lt;c0541874&gt;] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [&lt;c00a0104&gt;] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [&lt;c00a0580&gt;] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [&lt;c00a06c4&gt;] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [&lt;c00a0714&gt;] (stop_machine+0x34/0x44)
  (stop_machine) from [&lt;c00173e8&gt;] (patch_text+0x28/0x34)
  (patch_text) from [&lt;c001733c&gt;] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [&lt;c00a0d68&gt;] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [&lt;c00a0e90&gt;] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [&lt;c00a2e88&gt;] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [&lt;c00a11cc&gt;] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [&lt;c00a18cc&gt;] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [&lt;c0016f7c&gt;] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [&lt;c00091a4&gt;] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [&lt;c001400c&gt;] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e4050ba9 ("arm: kgdb: Handle read-only text / modules")
Reported-by: Aapo Vienamo &lt;avienamo@nvidia.com&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 7ae85dc7687c7e7119053d83d02c560ea217b772 upstream.

In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [&lt;c00133d4&gt;] (show_stack+0x20/0x24)
  (show_stack) from [&lt;c05400e8&gt;] (dump_stack+0x84/0xb8)
  (dump_stack) from [&lt;c004913c&gt;] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [&lt;c054065c&gt;] (__schedule+0x80/0x668)
  (__schedule) from [&lt;c0540cfc&gt;] (schedule+0xb8/0xd4)
  (schedule) from [&lt;c0543a3c&gt;] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [&lt;c05417c0&gt;] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [&lt;c0541874&gt;] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [&lt;c00a0104&gt;] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [&lt;c00a0580&gt;] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [&lt;c00a06c4&gt;] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [&lt;c00a0714&gt;] (stop_machine+0x34/0x44)
  (stop_machine) from [&lt;c00173e8&gt;] (patch_text+0x28/0x34)
  (patch_text) from [&lt;c001733c&gt;] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [&lt;c00a0d68&gt;] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [&lt;c00a0e90&gt;] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [&lt;c00a2e88&gt;] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [&lt;c00a11cc&gt;] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [&lt;c00a18cc&gt;] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [&lt;c0016f7c&gt;] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [&lt;c00091a4&gt;] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [&lt;c001400c&gt;] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e4050ba9 ("arm: kgdb: Handle read-only text / modules")
Reported-by: Aapo Vienamo &lt;avienamo@nvidia.com&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8429/1: disable GCC SRA optimization</title>
<updated>2015-10-22T21:49:16+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2015-09-03T12:24:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a9170ad82024cdc1798406537bafe46754d70c5d'/>
<id>a9170ad82024cdc1798406537bafe46754d70c5d</id>
<content type='text'>
commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream.

While working on the 32-bit ARM port of UEFI, I noticed a strange
corruption in the kernel log. The following snprintf() statement
(in drivers/firmware/efi/efi.c:efi_md_typeattr_format())

	snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",

was producing the following output in the log:

	|    |   |   |   |    |WB|WT|WC|UC]
	|    |   |   |   |    |WB|WT|WC|UC]
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |   |   |   |UC]
	|RUN|   |   |   |    |   |   |   |UC]

As it turns out, this is caused by incorrect code being emitted for
the string() function in lib/vsprintf.c. The following code

	if (!(spec.flags &amp; LEFT)) {
		while (len &lt; spec.field_width--) {
			if (buf &lt; end)
				*buf = ' ';
			++buf;
		}
	}
	for (i = 0; i &lt; len; ++i) {
		if (buf &lt; end)
			*buf = *s;
		++buf; ++s;
	}
	while (len &lt; spec.field_width--) {
		if (buf &lt; end)
			*buf = ' ';
		++buf;
	}

when called with len == 0, triggers an issue in the GCC SRA optimization
pass (Scalar Replacement of Aggregates), which handles promotion of signed
struct members incorrectly. This is a known but as yet unresolved issue.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
case, it is causing the second while loop to be executed erroneously a
single time, causing the additional space characters to be printed.

So disable the optimization by passing -fno-ipa-sra.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream.

While working on the 32-bit ARM port of UEFI, I noticed a strange
corruption in the kernel log. The following snprintf() statement
(in drivers/firmware/efi/efi.c:efi_md_typeattr_format())

	snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",

was producing the following output in the log:

	|    |   |   |   |    |WB|WT|WC|UC]
	|    |   |   |   |    |WB|WT|WC|UC]
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |WB|WT|WC|UC]*
	|    |   |   |   |    |WB|WT|WC|UC]
	|RUN|   |   |   |    |   |   |   |UC]
	|RUN|   |   |   |    |   |   |   |UC]

As it turns out, this is caused by incorrect code being emitted for
the string() function in lib/vsprintf.c. The following code

	if (!(spec.flags &amp; LEFT)) {
		while (len &lt; spec.field_width--) {
			if (buf &lt; end)
				*buf = ' ';
			++buf;
		}
	}
	for (i = 0; i &lt; len; ++i) {
		if (buf &lt; end)
			*buf = *s;
		++buf; ++s;
	}
	while (len &lt; spec.field_width--) {
		if (buf &lt; end)
			*buf = ' ';
		++buf;
	}

when called with len == 0, triggers an issue in the GCC SRA optimization
pass (Scalar Replacement of Aggregates), which handles promotion of signed
struct members incorrectly. This is a known but as yet unresolved issue.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
case, it is causing the second while loop to be executed erroneously a
single time, causing the additional space characters to be printed.

So disable the optimization by passing -fno-ipa-sra.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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