This is a note to let you know that I've just added the patch titled
ath10k: fix fetching channel during potential radar detection
to the 4.9-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-fetching-channel-during-potential-radar-detection.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 8 Mar 2017 18:03:32 +0530
Subject: ath10k: fix fetching channel during potential radar detection
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit a28f6f27a88f047f03f04b9246ca260ebc91455e ]
Fetch target operating channel during potential radar detection when
the interface is just brought up, but no channel is assigned from
userspace. In this scenario rx_channel may not be having a valid pointer
hence fetch the target operating channel to avoid warnings as below
which can be triggered by the commands with DFS testing over longer run
comamnds:
iw wlan1 set type mesh
ifconfig wlan1 up (valid tgt_oper_chan only)
iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan)
iw wlan1 cac trigger freq 5280 HT20
iw wlan1 cac trigger freq 5300 HT20
Once the CAC expires, current channel context will be removed and
we are only left with the fallback option of using 'target operating
channel'
Firmware and driver log:
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6,
count_false=11
ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6,
count_false=4
ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
count_false=4
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar
ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
treating as radar
Call trace:
WARNING: CPU: 1 PID: 2145 at
backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265
cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]()
Workqueue: phy1 ieee80211_dfs_radar_detected_work
[mac80211]
[<c0320770>] (warn_slowpath_null) from [<bf79b90c>]
(cfg80211_set_dfs_state+0x3c/0x88 [cfg80211])
[<bf79b90c>] (cfg80211_set_dfs_state [cfg80211]) from
[<bf79697c>] (cfg80211_radar_event+0xc4/0x140 [cfg80211])
[<bf79697c>] (cfg80211_radar_event [cfg80211]) from
[<bf83c058>] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211])
[<bf83c058>] (ieee80211_dfs_radar_detected_work
[mac80211]) from [<c0339518>] (process_one_work+0x298/0x4a4)
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/wmi.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3638,6 +3638,11 @@ static void ath10k_dfs_radar_report(stru
spin_lock_bh(&ar->data_lock);
ch = ar->rx_channel;
+
+ /* fetch target operating channel during channel change */
+ if (!ch)
+ ch = ar->tgt_oper_chan;
+
spin_unlock_bh(&ar->data_lock);
if (!ch) {
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/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 compile time sanity check for CE4 buffer size
to the 4.9-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-compile-time-sanity-check-for-ce4-buffer-size.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Tue, 4 Apr 2017 22:22:56 +0530
Subject: ath10k: fix compile time sanity check for CE4 buffer size
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit 62ca0690cd495bb7c1414cdf0cf790c2922a1d79 ]
In 'ath10k_ce_alloc_pipe' the compile time sanity check to
ensure that there is sufficient buffers in CE4 for HTT Tx
MSDU descriptors, but this did not take into account of the
case with 'peer flow control' enabled, fix this.
Cc: Michal Kazior <michal.kazior(a)tieto.com>
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/ce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1059,7 +1059,7 @@ int ath10k_ce_alloc_pipe(struct ath10k *
*/
BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
- BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC >
+ BUILD_BUG_ON(2 * TARGET_10_4_NUM_MSDU_DESC_PFC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC >
(CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/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 a warning during channel switch with multiple vaps
to the 4.9-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.9 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 Sun Mar 18 16:55:33 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
@@ -7070,7 +7070,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.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/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: disallow DFS simulation if DFS channel is not enabled
to the 4.9-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.9 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 Sun Mar 18 16:55:33 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
@@ -1942,6 +1942,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.9/ath10k-fix-fetching-channel-during-potential-radar-detection.patch
queue-4.9/ath10k-fix-compile-time-sanity-check-for-ce4-buffer-size.patch
queue-4.9/ath10k-fix-a-warning-during-channel-switch-with-multiple-vaps.patch
queue-4.9/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: rt5677: Add OF device ID table
to the 4.9-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-rt5677-add-of-device-id-table.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
Date: Tue, 4 Apr 2017 15:26:30 -0400
Subject: ASoC: rt5677: Add OF device ID table
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
[ Upstream commit 7b87463edf3e2c16d72eeea3d1cf3c12bb5487c6 ]
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Before this patch:
$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias: i2c:RT5677CE:00
alias: i2c:rt5676
alias: i2c:rt5677
After this patch:
$ modinfo sound/soc/codecs/snd-soc-rt5677.ko | grep alias
alias: of:N*T*Crealtek,rt5677C*
alias: of:N*T*Crealtek,rt5677
alias: i2c:RT5677CE:00
alias: i2c:rt5676
alias: i2c:rt5677
Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.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/codecs/rt5677.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -5035,6 +5035,12 @@ static const struct i2c_device_id rt5677
};
MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);
+static const struct of_device_id rt5677_of_match[] = {
+ { .compatible = "realtek,rt5677", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rt5677_of_match);
+
static const struct acpi_gpio_params plug_det_gpio = { RT5677_GPIO_PLUG_DET, 0, false };
static const struct acpi_gpio_params mic_present_gpio = { RT5677_GPIO_MIC_PRESENT_L, 0, false };
static const struct acpi_gpio_params headphone_enable_gpio = { RT5677_GPIO_HP_AMP_SHDN_L, 0, false };
@@ -5294,6 +5300,7 @@ static int rt5677_i2c_remove(struct i2c_
static struct i2c_driver rt5677_i2c_driver = {
.driver = {
.name = "rt5677",
+ .of_match_table = rt5677_of_match,
},
.probe = rt5677_i2c_probe,
.remove = rt5677_i2c_remove,
Patches currently in stable-queue which might be from javier(a)osg.samsung.com are
queue-4.9/asoc-rt5677-add-of-device-id-table.patch
queue-4.9/regulator-core-limit-propagation-of-parent-voltage-count-and-list.patch
queue-4.9/input-qt1070-add-of-device-id-table.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.9-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.9 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 Sun Mar 18 16:55:33 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
@@ -233,6 +233,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 32bit x chan
* see rsnd_ssi_init()
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.9/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
ASoC: nuc900: Fix a loop timeout test
to the 4.9-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.9 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 Sun Mar 18 16:55:33 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.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: r8a7796: Remove unit-address and reg from integrated cache
to the 4.9-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:
arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Fri, 3 Mar 2017 14:18:17 +0100
Subject: arm64: dts: r8a7796: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 57a4fd420c6e8a04b6a87ff24d34250cd7c48f15 ]
The Cortex-A57 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 1561f20760ec96db ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support")
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/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -36,9 +36,8 @@
enable-method = "psci";
};
- L2_CA57: cache-controller@0 {
+ L2_CA57: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7796_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/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: silk: Correct clock of DU1
to the 4.9-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-silk-correct-clock-of-du1.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 28 Mar 2017 12:45:33 +0200
Subject: ARM: dts: silk: Correct clock of DU1
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 403fe77e22eb72c962c3889efc9d4fa62e454737 ]
The second channel of the display unit uses a different module clock
than the first channel.
Fixes: 84e734f497cd48f6 ("ARM: dts: silk: add DU DT support")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
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/r8a7794-silk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -425,7 +425,7 @@
status = "okay";
clocks = <&mstp7_clks R8A7794_CLK_DU0>,
- <&mstp7_clks R8A7794_CLK_DU0>,
+ <&mstp7_clks R8A7794_CLK_DU1>,
<&x2_clk>, <&x3_clk>;
clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/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: r8a7794: Remove unit-address and reg from integrated cache
to the 4.9-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-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
and it can be found in the queue-4.9 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 Sun Mar 18 16:55:33 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 6 Mar 2017 17:40:43 +0100
Subject: ARM: dts: r8a7794: Remove unit-address and reg from integrated cache
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 65d0b7ed40f8a3a41a0ac5ed5ca4d1874c6aaf2d ]
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: 34ea4b4a827b4ee7 ("ARM: dts: r8a7794: Fix W=1 dtc warnings")
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/r8a7794.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -56,9 +56,8 @@
next-level-cache = <&L2_CA7>;
};
- L2_CA7: cache-controller@0 {
+ L2_CA7: cache-controller-0 {
compatible = "cache";
- reg = <0>;
power-domains = <&sysc R8A7794_PD_CA7_SCU>;
cache-unified;
cache-level = <2>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch