This is a note to let you know that I've just added the patch titled
drivers: net: xgene: Fix hardware checksum setting
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-xgene-fix-hardware-checksum-setting.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:16 -0700
Subject: drivers: net: xgene: Fix hardware checksum setting
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ]
This patch fixes the hardware checksum settings by properly program
the classifier. Otherwise, packet may be received with checksum error
on X-Gene1 SoC.
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -535,6 +535,7 @@ static void xgene_enet_cle_bypass(struct
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb);
cb |= CFG_CLE_BYPASS_EN0;
CFG_CLE_IP_PROTOCOL0_SET(&cb, 3);
+ CFG_CLE_IP_HDR_LEN_SET(&cb, 0);
xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb);
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb);
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -143,6 +143,7 @@ enum xgene_enet_rm {
#define CFG_TXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 29, 3)
#define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
+#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5)
#define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12)
#define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4)
#define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2)
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-3.18/drivers-net-xgene-fix-hardware-checksum-setting.patch
This is a note to let you know that I've just added the patch titled
braille-console: Fix value returned by _braille_console_setup
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
braille-console-fix-value-returned-by-_braille_console_setup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
Date: Sun, 26 Mar 2017 22:47:36 +0200
Subject: braille-console: Fix value returned by _braille_console_setup
From: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
[ Upstream commit 2ed2b8621be2708c0f6d61fe9841e9ad8b9753f0 ]
commit bbeddf52adc1 ("printk: move braille console support into
separate braille.[ch] files") introduced _braille_console_setup()
to outline the braille initialization code. There was however some
confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
("printk: Fix return of braille_register_console()") tried to fix it
but failed to.
This fixes and documents the returned value according to the use
in printk.c: non-zero return means a parsing error, and thus this
console configuration should be ignored.
Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org>
Cc: Aleksey Makarov <aleksey.makarov(a)linaro.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Ming Lei <ming.lei(a)canonical.com>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Acked-by: Petr Mladek <pmladek(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/printk/braille.c | 15 ++++++++-------
kernel/printk/braille.h | 13 ++++++++++---
2 files changed, 18 insertions(+), 10 deletions(-)
--- a/kernel/printk/braille.c
+++ b/kernel/printk/braille.c
@@ -2,12 +2,13 @@
#include <linux/kernel.h>
#include <linux/console.h>
+#include <linux/errno.h>
#include <linux/string.h>
#include "console_cmdline.h"
#include "braille.h"
-char *_braille_console_setup(char **str, char **brl_options)
+int _braille_console_setup(char **str, char **brl_options)
{
if (!memcmp(*str, "brl,", 4)) {
*brl_options = "";
@@ -15,14 +16,14 @@ char *_braille_console_setup(char **str,
} else if (!memcmp(str, "brl=", 4)) {
*brl_options = *str + 4;
*str = strchr(*brl_options, ',');
- if (!*str)
+ if (!*str) {
pr_err("need port name after brl=\n");
- else
- *((*str)++) = 0;
- } else
- return NULL;
+ return -EINVAL;
+ }
+ *((*str)++) = 0;
+ }
- return *str;
+ return 0;
}
int
--- a/kernel/printk/braille.h
+++ b/kernel/printk/braille.h
@@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli
c->brl_options = brl_options;
}
-char *
+/*
+ * Setup console according to braille options.
+ * Return -EINVAL on syntax error, 0 on success (or no braille option was
+ * actually given).
+ * Modifies str to point to the serial options
+ * Sets brl_options to the parsed braille options.
+ */
+int
_braille_console_setup(char **str, char **brl_options);
int
@@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli
{
}
-static inline char *
+static inline int
_braille_console_setup(char **str, char **brl_options)
{
- return NULL;
+ return 0;
}
static inline int
Patches currently in stable-queue which might be from samuel.thibault(a)ens-lyon.org are
queue-3.18/braille-console-fix-value-returned-by-_braille_console_setup.patch
This is a note to let you know that I've just added the patch titled
blk-throttle: make sure expire time isn't too big
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blk-throttle-make-sure-expire-time-isn-t-too-big.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Shaohua Li <shli(a)fb.com>
Date: Mon, 27 Mar 2017 10:51:36 -0700
Subject: blk-throttle: make sure expire time isn't too big
From: Shaohua Li <shli(a)fb.com>
[ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ]
cgroup could be throttled to a limit but when all cgroups cross high
limit, queue enters a higher state and so the group should be throttled
to a higher limit. It's possible the cgroup is sleeping because of
throttle and other cgroups don't dispatch IO any more. In this case,
nobody can trigger current downgrade/upgrade logic. To fix this issue,
we could either set up a timer to wakeup the cgroup if other cgroups are
idle or make sure this cgroup doesn't sleep too long. Setting up a timer
means we must change the timer very frequently. This patch chooses the
latter. Making cgroup sleep time not too big wouldn't change cgroup
bps/iops, but could make it wakeup more frequently, which isn't a big
issue because throtl_slice * 8 is already quite big.
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-throttle.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -648,6 +648,17 @@ static void throtl_dequeue_tg(struct thr
static void throtl_schedule_pending_timer(struct throtl_service_queue *sq,
unsigned long expires)
{
+ unsigned long max_expire = jiffies + 8 * throtl_slice;
+
+ /*
+ * Since we are adjusting the throttle limit dynamically, the sleep
+ * time calculated according to previous limit might be invalid. It's
+ * possible the cgroup sleep time is very long and no other cgroups
+ * have IO running so notify the limit changes. Make sure the cgroup
+ * doesn't sleep too long to avoid the missed notification.
+ */
+ if (time_after(expires, max_expire))
+ expires = max_expire;
mod_timer(&sq->pending_timer, expires);
throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu",
expires - jiffies, jiffies);
Patches currently in stable-queue which might be from shli(a)fb.com are
queue-3.18/blk-throttle-make-sure-expire-time-isn-t-too-big.patch
This is a note to let you know that I've just added the patch titled
batman-adv: handle race condition for claims between gateways
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
batman-adv-handle-race-condition-for-claims-between-gateways.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Andreas Pape <APape(a)phoenixcontact.com>
Date: Mon, 5 Sep 2016 13:20:29 +0200
Subject: batman-adv: handle race condition for claims between gateways
From: Andreas Pape <APape(a)phoenixcontact.com>
[ Upstream commit a3a5129e122709306cfa6409781716c2933df99b ]
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.
Acked-by: Simon Wunderlich <sw(a)simonwunderlich.de>
Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com>
[sven(a)narfation.org: fix conflicts with current version]
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/batman-adv/bridge_loop_avoidance.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1596,10 +1596,22 @@ int batadv_bla_tx(struct batadv_priv *ba
/* if yes, the client has roamed and we have
* to unclaim it.
*/
- batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
- goto allow;
+ if (batadv_has_timed_out(claim->lasttime, 100)) {
+ /* only unclaim if the last claim entry is
+ * older than 100 ms to make sure we really
+ * have a roaming client here.
+ */
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming client %pM detected. Unclaim it.\n",
+ ethhdr->h_source);
+ batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+ goto allow;
+ } else {
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race for claim %pM detected. Drop packet.\n",
+ ethhdr->h_source);
+ goto handled;
+ }
}
/* check if it is a multicast/broadcast frame */
Patches currently in stable-queue which might be from APape(a)phoenixcontact.com are
queue-3.18/batman-adv-handle-race-condition-for-claims-between-gateways.patch
This is a note to let you know that I've just added the patch titled
ath10k: disallow DFS simulation if DFS channel is not enabled
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 22 Feb 2017 21:03:11 +0530
Subject: ath10k: disallow DFS simulation if DFS channel is not enabled
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit ca07baab0b1e627ae1d4a55d190fb1c9d32a3445 ]
If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
not be available for use even though the hardware may have the capability
to support DFS. With this configuration (DFS disabled in hostapd) trying to
bring up ath10k device in DFS channel for AP mode fails and trying to
simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
invalid channel and this should be avoided in the driver itself rather than
false propogating RADAR detection to mac80211/cfg80211. Fix this by
checking for the first vif 'is_started' state(should work for client mode
as well) as all the vifs shall be configured for the same channel
sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar
WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)
WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/debug.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1079,6 +1079,15 @@ static ssize_t ath10k_write_simulate_rad
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
+ struct ath10k_vif *arvif;
+
+ /* Just check for for the first vif alone, as all the vifs will be
+ * sharing the same channel and if the channel is disabled, all the
+ * vifs will share the same 'is_started' state.
+ */
+ arvif = list_first_entry(&ar->arvifs, typeof(*arvif), list);
+ if (!arvif->is_started)
+ return -EINVAL;
ieee80211_radar_detected(ar->hw);
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-3.18/ath10k-disallow-dfs-simulation-if-dfs-channel-is-not-enabled.patch
This is a note to let you know that I've just added the patch titled
ASoC: nuc900: Fix a loop timeout test
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-nuc900-fix-a-loop-timeout-test.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 9 Dec 2017 14:52:28 +0300
Subject: ASoC: nuc900: Fix a loop timeout test
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]
We should be finishing the loop with timeout set to zero but because
this is a post-op we finish with timeout == -1.
Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/nuc900/nuc900-ac97.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/nuc900/nuc900-ac97.c
+++ b/sound/soc/nuc900/nuc900-ac97.c
@@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s
/* polling the AC_R_FINISH */
while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout) {
@@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd
/* polling the AC_W_FINISH */
while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);
if (!timeout)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-3.18/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-3.18/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:45:41 +0200
Subject: ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit d13d4e063d4a08eb1686e890e9183dde709871bf ]
The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.
Fixes: bcde372254386872 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7790.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -978,8 +978,11 @@
compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-3.18/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-3.18/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:45:42 +0200
Subject: ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 16fe68dcab5702a024d85229ff7e98979cb701a5 ]
The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.
Fixes: ee9141522dcf13f8 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1001,8 +1001,11 @@
compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-3.18/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-3.18/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 10:11:52 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:56 -0600
Subject: ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
Signed-off-by: Andrew F. Davis <afd(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -138,7 +138,7 @@
&audio_codec {
status = "okay";
- gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-3.18/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-3.18/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch