<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm/boot, branch v5.3.17</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity</title>
<updated>2019-12-17T19:08:08+00:00</updated>
<author>
<name>Jarkko Nikula</name>
<email>jarkko.nikula@bitmer.com</email>
</author>
<published>2019-11-16T15:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=32b9e6e1c5d36f6cc246a8220ffef2b30c5d5912'/>
<id>32b9e6e1c5d36f6cc246a8220ffef2b30c5d5912</id>
<content type='text'>
commit 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream.

The MMC card detection GPIO polarity is active low on TAO3530, like in many
other similar boards. Now the card is not detected and it is unable to
mount rootfs from an SD card.

Fix this by using the correct polarity.

This incorrect polarity was defined already in the commit 30d95c6d7092
("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18
kernel and later changed to use defined GPIO constants in v4.4 kernel by
the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags
cell for OMAP2+ boards").

While the latter commit did not introduce the issue I'm marking it with
Fixes tag due the v4.4 kernels still being maintained.

Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards")
Cc: linux-stable &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@bitmer.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 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream.

The MMC card detection GPIO polarity is active low on TAO3530, like in many
other similar boards. Now the card is not detected and it is unable to
mount rootfs from an SD card.

Fix this by using the correct polarity.

This incorrect polarity was defined already in the commit 30d95c6d7092
("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18
kernel and later changed to use defined GPIO constants in v4.4 kernel by
the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags
cell for OMAP2+ boards").

While the latter commit did not introduce the issue I'm marking it with
Fixes tag due the v4.4 kernels still being maintained.

Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards")
Cc: linux-stable &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@bitmer.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: dts: pandora-common: define wl1251 as child node of mmc3</title>
<updated>2019-12-17T19:07:08+00:00</updated>
<author>
<name>H. Nikolaus Schaller</name>
<email>hns@goldelico.com</email>
</author>
<published>2019-11-07T10:30:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6b2a08f142062ca15311f2d7180902609e42ad08'/>
<id>6b2a08f142062ca15311f2d7180902609e42ad08</id>
<content type='text'>
commit 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream.

Since v4.7 the dma initialization requires that there is a
device tree property for "rx" and "tx" channels which is
not provided by the pdata-quirks initialization.

By conversion of the mmc3 setup to device tree this will
finally allows to remove the OpenPandora wlan specific omap3
data-quirks.

Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
Signed-off-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.7+
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@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 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream.

Since v4.7 the dma initialization requires that there is a
device tree property for "rx" and "tx" channels which is
not provided by the pdata-quirks initialization.

By conversion of the mmc3 setup to device tree this will
finally allows to remove the OpenPandora wlan specific omap3
data-quirks.

Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
Signed-off-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.7+
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: stm32: Fix CAN RAM mapping on stm32mp157c</title>
<updated>2019-12-04T21:33:48+00:00</updated>
<author>
<name>Christophe Roullier</name>
<email>christophe.roullier@st.com</email>
</author>
<published>2019-11-04T14:31:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=904c854284168fe507b688d4d0d91550e60d9d48'/>
<id>904c854284168fe507b688d4d0d91550e60d9d48</id>
<content type='text'>
[ Upstream commit 9df50c2e16de7fd739d11d37303afec9e573b46f ]

Split the 10Kbytes CAN message RAM to be able to use simultaneously
FDCAN1 and FDCAN2 instances.
First 5Kbytes are allocated to FDCAN1 and last 5Kbytes are used for
FDCAN2. To do so, set the offset to 0x1400 in mram-cfg for FDCAN2.

Fixes: d44d6e021301 ("ARM: dts: stm32: change CAN RAM mapping on stm32mp157c")
Signed-off-by: Christophe Roullier &lt;christophe.roullier@st.com&gt;
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9df50c2e16de7fd739d11d37303afec9e573b46f ]

Split the 10Kbytes CAN message RAM to be able to use simultaneously
FDCAN1 and FDCAN2 instances.
First 5Kbytes are allocated to FDCAN1 and last 5Kbytes are used for
FDCAN2. To do so, set the offset to 0x1400 in mram-cfg for FDCAN2.

Fixes: d44d6e021301 ("ARM: dts: stm32: change CAN RAM mapping on stm32mp157c")
Signed-off-by: Christophe Roullier &lt;christophe.roullier@st.com&gt;
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: sun8i-a83t-tbs-a711: Fix WiFi resume from suspend</title>
<updated>2019-12-04T21:33:17+00:00</updated>
<author>
<name>Ondrej Jirman</name>
<email>megous@megous.com</email>
</author>
<published>2019-10-28T21:58:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=83e0b5fb2766fabdb52c03bf90acb8029da9a18f'/>
<id>83e0b5fb2766fabdb52c03bf90acb8029da9a18f</id>
<content type='text'>
[ Upstream commit e614f341253f8541baf0230a8dc6a016b544b1e2 ]

Without enabling keep-power-in-suspend, we can't wake the device
up using WOL packet, and the log is flooded with these messages
on resume:

sunxi-mmc 1c10000.mmc: send stop command failed
sunxi-mmc 1c10000.mmc: data error, sending stop command
sunxi-mmc 1c10000.mmc: send stop command failed
sunxi-mmc 1c10000.mmc: data error, sending stop command

So to make the WiFi really a wakeup-source, we need to keep it powered
during suspend.

Fixes: 0e23372080def7 ("arm: dts: sun8i: Add the TBS A711 tablet devicetree")
Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e614f341253f8541baf0230a8dc6a016b544b1e2 ]

Without enabling keep-power-in-suspend, we can't wake the device
up using WOL packet, and the log is flooded with these messages
on resume:

sunxi-mmc 1c10000.mmc: send stop command failed
sunxi-mmc 1c10000.mmc: data error, sending stop command
sunxi-mmc 1c10000.mmc: send stop command failed
sunxi-mmc 1c10000.mmc: data error, sending stop command

So to make the WiFi really a wakeup-source, we need to keep it powered
during suspend.

Fixes: 0e23372080def7 ("arm: dts: sun8i: Add the TBS A711 tablet devicetree")
Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: imx6qdl-sabreauto: Fix storm of accelerometer interrupts</title>
<updated>2019-12-04T21:33:11+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>festevam@gmail.com</email>
</author>
<published>2019-10-09T20:43:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=46a19e3541702857c38296b42101c9dea36a7fd7'/>
<id>46a19e3541702857c38296b42101c9dea36a7fd7</id>
<content type='text'>
[ Upstream commit 7e5d0bf6afcc7bd72f78e7f33570e2e0945624f0 ]

Since commit a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors")
a storm of accelerometer interrupts is seen:

[  114.211283] irq 260: nobody cared (try booting with the "irqpoll" option)
[  114.218108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.4 #1
[  114.223960] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  114.230531] [&lt;c0112858&gt;] (unwind_backtrace) from [&lt;c010cdc8&gt;] (show_stack+0x10/0x14)
[  114.238301] [&lt;c010cdc8&gt;] (show_stack) from [&lt;c0c1aa1c&gt;] (dump_stack+0xd8/0x110)
[  114.245644] [&lt;c0c1aa1c&gt;] (dump_stack) from [&lt;c0193594&gt;] (__report_bad_irq+0x30/0xc0)
[  114.253417] [&lt;c0193594&gt;] (__report_bad_irq) from [&lt;c01933ac&gt;] (note_interrupt+0x108/0x298)
[  114.261707] [&lt;c01933ac&gt;] (note_interrupt) from [&lt;c018ffe4&gt;] (handle_irq_event_percpu+0x70/0x80)
[  114.270433] [&lt;c018ffe4&gt;] (handle_irq_event_percpu) from [&lt;c019002c&gt;] (handle_irq_event+0x38/0x5c)
[  114.279326] [&lt;c019002c&gt;] (handle_irq_event) from [&lt;c019438c&gt;] (handle_level_irq+0xc8/0x154)
[  114.287701] [&lt;c019438c&gt;] (handle_level_irq) from [&lt;c018eda0&gt;] (generic_handle_irq+0x20/0x34)
[  114.296166] [&lt;c018eda0&gt;] (generic_handle_irq) from [&lt;c0534214&gt;] (mxc_gpio_irq_handler+0x30/0xf0)
[  114.304975] [&lt;c0534214&gt;] (mxc_gpio_irq_handler) from [&lt;c0534334&gt;] (mx3_gpio_irq_handler+0x60/0xb0)
[  114.313955] [&lt;c0534334&gt;] (mx3_gpio_irq_handler) from [&lt;c018eda0&gt;] (generic_handle_irq+0x20/0x34)
[  114.322762] [&lt;c018eda0&gt;] (generic_handle_irq) from [&lt;c018f3ac&gt;] (__handle_domain_irq+0x64/0xe0)
[  114.331485] [&lt;c018f3ac&gt;] (__handle_domain_irq) from [&lt;c05215a8&gt;] (gic_handle_irq+0x4c/0xa8)
[  114.339862] [&lt;c05215a8&gt;] (gic_handle_irq) from [&lt;c0101a70&gt;] (__irq_svc+0x70/0x98)
[  114.347361] Exception stack(0xc1301ec0 to 0xc1301f08)
[  114.352435] 1ec0: 00000001 00000006 00000000 c130c340 00000001 c130f688 9785636d c13ea2e8
[  114.360635] 1ee0: 9784907d 0000001a eaf99d78 0000001a 00000000 c1301f10 c0182b00 c0878de4
[  114.368830] 1f00: 20000013 ffffffff
[  114.372349] [&lt;c0101a70&gt;] (__irq_svc) from [&lt;c0878de4&gt;] (cpuidle_enter_state+0x168/0x5f4)
[  114.380464] [&lt;c0878de4&gt;] (cpuidle_enter_state) from [&lt;c08792ac&gt;] (cpuidle_enter+0x28/0x38)
[  114.388751] [&lt;c08792ac&gt;] (cpuidle_enter) from [&lt;c015ef9c&gt;] (do_idle+0x224/0x2a8)
[  114.396168] [&lt;c015ef9c&gt;] (do_idle) from [&lt;c015f3b8&gt;] (cpu_startup_entry+0x18/0x20)
[  114.403765] [&lt;c015f3b8&gt;] (cpu_startup_entry) from [&lt;c1200e54&gt;] (start_kernel+0x43c/0x500)
[  114.411958] handlers:
[  114.414302] [&lt;a01028b8&gt;] irq_default_primary_handler threaded [&lt;fd7a3b08&gt;] mma8452_interrupt
[  114.422974] Disabling IRQ #260

           CPU0       CPU1
....
260:     100001          0  gpio-mxc  31 Level     mma8451

The MMA8451 interrupt triggers as low level, so the GPIO6_IO31 pin
needs to activate its pull up, otherwise it will stay always at low level
generating multiple interrupts.

The current device tree does not configure the IOMUX for this pin, so
it uses whathever comes configured from the bootloader.

The IOMUXC_SW_PAD_CTL_PAD_EIM_BCLK register value comes as 0x8000 from
the bootloader, which has PKE bit cleared, hence disabling the
pull-up.

Instead of relying on a previous configuration from the bootloader,
configure the GPIO6_IO31 pin with pull-up enabled in order to fix
this problem.

Fixes: a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors")
Signed-off-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Reviewed-By: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7e5d0bf6afcc7bd72f78e7f33570e2e0945624f0 ]

Since commit a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors")
a storm of accelerometer interrupts is seen:

[  114.211283] irq 260: nobody cared (try booting with the "irqpoll" option)
[  114.218108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.4 #1
[  114.223960] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  114.230531] [&lt;c0112858&gt;] (unwind_backtrace) from [&lt;c010cdc8&gt;] (show_stack+0x10/0x14)
[  114.238301] [&lt;c010cdc8&gt;] (show_stack) from [&lt;c0c1aa1c&gt;] (dump_stack+0xd8/0x110)
[  114.245644] [&lt;c0c1aa1c&gt;] (dump_stack) from [&lt;c0193594&gt;] (__report_bad_irq+0x30/0xc0)
[  114.253417] [&lt;c0193594&gt;] (__report_bad_irq) from [&lt;c01933ac&gt;] (note_interrupt+0x108/0x298)
[  114.261707] [&lt;c01933ac&gt;] (note_interrupt) from [&lt;c018ffe4&gt;] (handle_irq_event_percpu+0x70/0x80)
[  114.270433] [&lt;c018ffe4&gt;] (handle_irq_event_percpu) from [&lt;c019002c&gt;] (handle_irq_event+0x38/0x5c)
[  114.279326] [&lt;c019002c&gt;] (handle_irq_event) from [&lt;c019438c&gt;] (handle_level_irq+0xc8/0x154)
[  114.287701] [&lt;c019438c&gt;] (handle_level_irq) from [&lt;c018eda0&gt;] (generic_handle_irq+0x20/0x34)
[  114.296166] [&lt;c018eda0&gt;] (generic_handle_irq) from [&lt;c0534214&gt;] (mxc_gpio_irq_handler+0x30/0xf0)
[  114.304975] [&lt;c0534214&gt;] (mxc_gpio_irq_handler) from [&lt;c0534334&gt;] (mx3_gpio_irq_handler+0x60/0xb0)
[  114.313955] [&lt;c0534334&gt;] (mx3_gpio_irq_handler) from [&lt;c018eda0&gt;] (generic_handle_irq+0x20/0x34)
[  114.322762] [&lt;c018eda0&gt;] (generic_handle_irq) from [&lt;c018f3ac&gt;] (__handle_domain_irq+0x64/0xe0)
[  114.331485] [&lt;c018f3ac&gt;] (__handle_domain_irq) from [&lt;c05215a8&gt;] (gic_handle_irq+0x4c/0xa8)
[  114.339862] [&lt;c05215a8&gt;] (gic_handle_irq) from [&lt;c0101a70&gt;] (__irq_svc+0x70/0x98)
[  114.347361] Exception stack(0xc1301ec0 to 0xc1301f08)
[  114.352435] 1ec0: 00000001 00000006 00000000 c130c340 00000001 c130f688 9785636d c13ea2e8
[  114.360635] 1ee0: 9784907d 0000001a eaf99d78 0000001a 00000000 c1301f10 c0182b00 c0878de4
[  114.368830] 1f00: 20000013 ffffffff
[  114.372349] [&lt;c0101a70&gt;] (__irq_svc) from [&lt;c0878de4&gt;] (cpuidle_enter_state+0x168/0x5f4)
[  114.380464] [&lt;c0878de4&gt;] (cpuidle_enter_state) from [&lt;c08792ac&gt;] (cpuidle_enter+0x28/0x38)
[  114.388751] [&lt;c08792ac&gt;] (cpuidle_enter) from [&lt;c015ef9c&gt;] (do_idle+0x224/0x2a8)
[  114.396168] [&lt;c015ef9c&gt;] (do_idle) from [&lt;c015f3b8&gt;] (cpu_startup_entry+0x18/0x20)
[  114.403765] [&lt;c015f3b8&gt;] (cpu_startup_entry) from [&lt;c1200e54&gt;] (start_kernel+0x43c/0x500)
[  114.411958] handlers:
[  114.414302] [&lt;a01028b8&gt;] irq_default_primary_handler threaded [&lt;fd7a3b08&gt;] mma8452_interrupt
[  114.422974] Disabling IRQ #260

           CPU0       CPU1
....
260:     100001          0  gpio-mxc  31 Level     mma8451

The MMA8451 interrupt triggers as low level, so the GPIO6_IO31 pin
needs to activate its pull up, otherwise it will stay always at low level
generating multiple interrupts.

The current device tree does not configure the IOMUX for this pin, so
it uses whathever comes configured from the bootloader.

The IOMUXC_SW_PAD_CTL_PAD_EIM_BCLK register value comes as 0x8000 from
the bootloader, which has PKE bit cleared, hence disabling the
pull-up.

Instead of relying on a previous configuration from the bootloader,
configure the GPIO6_IO31 pin with pull-up enabled in order to fix
this problem.

Fixes: a211b8c55f3c ("ARM: dts: imx6qdl-sabreauto: Add sensors")
Signed-off-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Reviewed-By: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: stm32: change joystick pinctrl definition on stm32mp157c-ev1</title>
<updated>2019-11-12T18:28:21+00:00</updated>
<author>
<name>Amelie Delaunay</name>
<email>amelie.delaunay@st.com</email>
</author>
<published>2019-11-04T10:55:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e74a78cf2f699385ca043f781f50ec0e8e69fed5'/>
<id>e74a78cf2f699385ca043f781f50ec0e8e69fed5</id>
<content type='text'>
[ Upstream commit f4d6e0f79bcde7810890563bac8e0f3479fe6d03 ]

Pins used for joystick are all configured as input. "push-pull" is not a
valid setting for an input pin.

Fixes: a502b343ebd0 ("pinctrl: stmfx: update pinconf settings")
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Amelie Delaunay &lt;amelie.delaunay@st.com&gt;
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f4d6e0f79bcde7810890563bac8e0f3479fe6d03 ]

Pins used for joystick are all configured as input. "push-pull" is not a
valid setting for an input pin.

Fixes: a502b343ebd0 ("pinctrl: stmfx: update pinconf settings")
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Amelie Delaunay &lt;amelie.delaunay@st.com&gt;
Signed-off-by: Alexandre Torgue &lt;alexandre.torgue@st.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: imx6-logicpd: Re-enable SNVS power key</title>
<updated>2019-11-12T18:27:10+00:00</updated>
<author>
<name>Adam Ford</name>
<email>aford173@gmail.com</email>
</author>
<published>2019-10-16T14:40:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6972f6cdf9b4d1367df7e45e4471d9e1124a0b85'/>
<id>6972f6cdf9b4d1367df7e45e4471d9e1124a0b85</id>
<content type='text'>
commit cabe5f85e63626c00f3b879a670ec27325056a2d upstream.

The baseboard of the Logic PD i.MX6 development kit has a power
button routed which can both power down and power up the board.
It can also wake the board from sleep.  This functionality was
marked as disabled by default in imx6qdl.dtsi, so it needs to
be explicitly enabled for each board.

This patch enables the snvs power key again.

Signed-off-by: Adam Ford &lt;aford173@gmail.com&gt;
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to board design")
Cc: stable &lt;stable@vger.kernel.org&gt; #5.3+
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 cabe5f85e63626c00f3b879a670ec27325056a2d upstream.

The baseboard of the Logic PD i.MX6 development kit has a power
button routed which can both power down and power up the board.
It can also wake the board from sleep.  This functionality was
marked as disabled by default in imx6qdl.dtsi, so it needs to
be explicitly enabled for each board.

This patch enables the snvs power key again.

Signed-off-by: Adam Ford &lt;aford173@gmail.com&gt;
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to board design")
Cc: stable &lt;stable@vger.kernel.org&gt; #5.3+
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: bcm2837-rpi-cm3: Avoid leds-gpio probing issue</title>
<updated>2019-11-10T10:34:16+00:00</updated>
<author>
<name>Stefan Wahren</name>
<email>wahrenst@gmx.net</email>
</author>
<published>2019-10-13T10:53:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b649bffa248785e70f3a2890c683260032df3667'/>
<id>b649bffa248785e70f3a2890c683260032df3667</id>
<content type='text'>
[ Upstream commit 626c45d223e22090511acbfb481e0ece1de1356d ]

bcm2835-rpi.dtsi defines the behavior of the ACT LED, which is available
on all Raspberry Pi boards. But there is no driver for this particual
GPIO on CM3 in mainline yet, so this node was left incomplete without
the actual GPIO definition. Since commit 025bf37725f1 ("gpio: Fix return
value mismatch of function gpiod_get_from_of_node()") this causing probe
issues of the leds-gpio driver for users of the CM3 dtsi file.

  leds-gpio: probe of leds failed with error -2

Until we have the necessary GPIO driver hide the ACT node for CM3
to avoid this.

Reported-by: Fredrik Yhlen &lt;fredrik.yhlen@endian.se&gt;
Signed-off-by: Stefan Wahren &lt;wahrenst@gmx.net&gt;
Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board")
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 626c45d223e22090511acbfb481e0ece1de1356d ]

bcm2835-rpi.dtsi defines the behavior of the ACT LED, which is available
on all Raspberry Pi boards. But there is no driver for this particual
GPIO on CM3 in mainline yet, so this node was left incomplete without
the actual GPIO definition. Since commit 025bf37725f1 ("gpio: Fix return
value mismatch of function gpiod_get_from_of_node()") this causing probe
issues of the leds-gpio driver for users of the CM3 dtsi file.

  leds-gpio: probe of leds failed with error -2

Until we have the necessary GPIO driver hide the ACT node for CM3
to avoid this.

Reported-by: Fredrik Yhlen &lt;fredrik.yhlen@endian.se&gt;
Signed-off-by: Stefan Wahren &lt;wahrenst@gmx.net&gt;
Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board")
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: imx7s: Correct GPT's ipg clock source</title>
<updated>2019-11-10T10:34:08+00:00</updated>
<author>
<name>Anson Huang</name>
<email>Anson.Huang@nxp.com</email>
</author>
<published>2019-10-07T00:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ccb67164c295b5e9219444ef079c6ee9ca3ecb68'/>
<id>ccb67164c295b5e9219444ef079c6ee9ca3ecb68</id>
<content type='text'>
[ Upstream commit 252b9e21bcf46b0d16f733f2e42b21fdc60addee ]

i.MX7S/D's GPT ipg clock should be from GPT clock root and
controlled by CCM's GPT CCGR, using correct clock source for
GPT ipg clock instead of IMX7D_CLK_DUMMY.

Fixes: 3ef79ca6bd1d ("ARM: dts: imx7d: use imx7s.dtsi as base device tree")
Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 252b9e21bcf46b0d16f733f2e42b21fdc60addee ]

i.MX7S/D's GPT ipg clock should be from GPT clock root and
controlled by CCM's GPT CCGR, using correct clock source for
GPT ipg clock instead of IMX7D_CLK_DUMMY.

Fixes: 3ef79ca6bd1d ("ARM: dts: imx7d: use imx7s.dtsi as base device tree")
Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect'</title>
<updated>2019-11-10T10:34:08+00:00</updated>
<author>
<name>Andrey Smirnov</name>
<email>andrew.smirnov@gmail.com</email>
</author>
<published>2019-10-04T05:41:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4525ea414490b8d043c212d4cf49590cba28dba1'/>
<id>4525ea414490b8d043c212d4cf49590cba28dba1</id>
<content type='text'>
[ Upstream commit 71936a6d18c33c63b4e9e0359fb987306cbe9fae ]

Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
board, since both are connected to the same parent bus and all of
their children have the same I2C address.

Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board")
Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Cory Tusar &lt;cory.tusar@zii.aero&gt;
Cc: Jeff White &lt;jeff.white@zii.aero&gt;
Cc: Rick Ramstetter &lt;rick@anteaterllc.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Chris Healy &lt;cphealy@gmail.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 71936a6d18c33c63b4e9e0359fb987306cbe9fae ]

Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
board, since both are connected to the same parent bus and all of
their children have the same I2C address.

Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board")
Signed-off-by: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Chris Healy &lt;cphealy@gmail.com&gt;
Cc: Cory Tusar &lt;cory.tusar@zii.aero&gt;
Cc: Jeff White &lt;jeff.white@zii.aero&gt;
Cc: Rick Ramstetter &lt;rick@anteaterllc.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Chris Healy &lt;cphealy@gmail.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
