This is a note to let you know that I've just added the patch titled
ath10k: fix a warning during channel switch with multiple vaps
to the 4.4-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-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 8 Mar 2017 13:52:06 +0200
Subject: ath10k: fix a warning during channel switch with multiple vaps
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit c73f8c00330f59ce9b1ace9ff698aca83390d358 ]
Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch
hostapd_cli -i wlan0 chan_switch 5 5200
OK
ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0
Call Trace:
WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>]
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[<bf7f150c>] (ath10k_reconfig_complete [ath10k_core])
[<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211])
[<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])
Fixes: d7bf4b4aba05 ("ath10k: fix ar->rx_channel updating logic")
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/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6427,7 +6427,7 @@ ath10k_mac_update_rx_channel(struct ath1
lockdep_assert_held(&ar->data_lock);
WARN_ON(ctx && vifs);
- WARN_ON(vifs && n_vifs != 1);
+ WARN_ON(vifs && !n_vifs);
/* FIXME: Sort of an optimization and a workaround. Peers and vifs are
* on a linked list now. Doing a lookup peer -> vif -> chanctx for each
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.4/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.4/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
ath10k: fix invalid STS_CAP_OFFSET_MASK
to the 4.4-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-fix-invalid-sts_cap_offset_mask.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: Ben Greear <greearb(a)candelatech.com>
Date: Sat, 2 Dec 2017 16:50:49 +0200
Subject: ath10k: fix invalid STS_CAP_OFFSET_MASK
From: Ben Greear <greearb(a)candelatech.com>
[ Upstream commit 8cec57f5277ef0e354e37a0bf909dc71bc1f865b ]
The 10.4 firmware defines this as a 3-bit field, as does the
mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF
at least in the firmware header I have seen. This patch
fixes the ath10k wmi header to match the firmware.
Signed-off-by: Ben Greear <greearb(a)candelatech.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/wmi.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4826,7 +4826,8 @@ enum wmi_10_4_vdev_param {
#define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)
#define WMI_TXBF_STS_CAP_OFFSET_LSB 4
-#define WMI_TXBF_STS_CAP_OFFSET_MASK 0xf0
+#define WMI_TXBF_STS_CAP_OFFSET_MASK 0x70
+#define WMI_TXBF_CONF_IMPLICIT_BF BIT(7)
#define WMI_BF_SOUND_DIM_OFFSET_LSB 8
#define WMI_BF_SOUND_DIM_OFFSET_MASK 0xf00
Patches currently in stable-queue which might be from greearb(a)candelatech.com are
queue-4.4/ath10k-fix-invalid-sts_cap_offset_mask.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 4.4-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-4.4 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 09:58:12 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
@@ -1892,6 +1892,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-4.4/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.4/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 4.4-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-4.4 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 09:58:12 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-4.4/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.4/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.4/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT
to the 4.4-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-rcar-ssi-don-t-set-ssicr.ckdv-000-with-ssiwsr.cont.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 22 Mar 2017 04:02:43 +0000
Subject: ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit 6b8530cc056efd4a11b034ca5b1e9f7e9563f553 ]
R-Car Datasheet is indicating "SSICR.CKDV = 000 is invalid when
SSIWSR.WS_MODE = 1 or SSIWSR.CONT = 1".
Current driver will set CONT, thus, we shouldn't use CKDV = 000.
This patch fixup it.
Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.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/sh/rcar/ssi.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -143,6 +143,15 @@ static int rsnd_ssi_master_clk_start(str
for (j = 0; j < ARRAY_SIZE(ssi_clk_mul_table); j++) {
/*
+ * It will set SSIWSR.CONT here, but SSICR.CKDV = 000
+ * with it is not allowed. (SSIWSR.WS_MODE with
+ * SSICR.CKDV = 000 is not allowed either).
+ * Skip it. See SSICR.CKDV
+ */
+ if (j == 0)
+ continue;
+
+ /*
* this driver is assuming that
* system word is 64fs (= 2 x 32bit)
* see rsnd_ssi_init()
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.4/asoc-rcar-ssi-don-t-set-ssicr.ckdv-000-with-ssiwsr.cont.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 4.4-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-4.4 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 09:58:12 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
@@ -1360,8 +1360,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-4.4/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.4/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.4/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 4.4-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-4.4 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 09:58:12 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
@@ -1374,8 +1374,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-4.4/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.4/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.4/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: omap3-n900: Fix the audio CODEC's reset pin
to the 4.4-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-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: "Andrew F. Davis" <afd(a)ti.com>
Date: Wed, 29 Nov 2017 11:13:59 -0600
Subject: ARM: dts: omap3-n900: Fix the audio CODEC's reset pin
From: "Andrew F. Davis" <afd(a)ti.com>
[ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")
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/omap3-n900.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -488,7 +488,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -505,7 +505,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
Patches currently in stable-queue which might be from afd(a)ti.com are
queue-4.4/arm-dts-omap3-n900-fix-the-audio-codec-s-reset-pin.patch
queue-4.4/arm-dts-am335x-pepper-fix-the-audio-codec-s-reset-pin.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: Correct Trats2 panel reset line
to the 4.4-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-exynos-correct-trats2-panel-reset-line.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: Simon Shields <simon(a)lineageos.org>
Date: Tue, 21 Nov 2017 22:24:24 +1100
Subject: ARM: dts: exynos: Correct Trats2 panel reset line
From: Simon Shields <simon(a)lineageos.org>
[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]
Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.
Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields <simon(a)lineageos.org>
Acked-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -359,7 +359,7 @@
reg = <0>;
vdd3-supply = <&lcd_vdd3_reg>;
vci-supply = <&ldo25_reg>;
- reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
Patches currently in stable-queue which might be from simon(a)lineageos.org are
queue-4.4/arm-dts-exynos-correct-trats2-panel-reset-line.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: koelsch: Correct clock frequency of X2 DU clock input
to the 4.4-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-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
and it can be found in the queue-4.4 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 09:58:12 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 3 Apr 2017 11:55:19 +0200
Subject: ARM: dts: koelsch: Correct clock frequency of X2 DU clock input
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit ebf06af55c7594ed1fc18469a5cddf911c40e687 ]
The X2 crystal oscillator on the Koelsch development board provides a
74.25 MHz clock, not a 148.5 MHz clock.
Fixes: cd21cb46e14aae3a ("ARM: shmobile: koelsch: Add DU external pixel clocks to DT")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se>
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-koelsch.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -280,7 +280,7 @@
x2_clk: x2-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <148500000>;
+ clock-frequency = <74250000>;
};
x13_clk: x13-clock {
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.4/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.4/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.4/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch