- Linux-stable-mirror - lists.linaro.org

Patch "blk-throttle: make sure expire time isn't too big" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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 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: blk-throttle-make-sure-expire-time-isn-t-too-big.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: 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 @@ -499,6 +499,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-4.9/md.c-didn-t-unlock-the-mddev-before-return-einval-in-array_size_store.patch queue-4.9/md-raid6-fix-anomily-when-recovering-a-single-device-in-raid6.patch queue-4.9/blk-throttle-make-sure-expire-time-isn-t-too-big.patch

7 years, 7 months

1
0
0 0

Patch "batman-adv: handle race condition for claims between gateways" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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 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: batman-adv-handle-race-condition-for-claims-between-gateways.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: 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 @@ -1964,10 +1964,22 @@ bool batadv_bla_tx(struct batadv_priv *b /* 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-4.9/batman-adv-handle-race-condition-for-claims-between-gateways.patch

7 years, 7 months

1
0
0 0

Patch "ath10k: update tdls teardown state to target" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: update tdls teardown state to target 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-update-tdls-teardown-state-to-target.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: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com> Date: Mon, 6 Nov 2017 13:39:31 +0530 Subject: ath10k: update tdls teardown state to target From: Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com> [ Upstream commit 424ea0d174e82365f85c6770225dba098b8f1d5f ] It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer. Without proper cleanup, target assumes that the peer is connected and blocks future connection requests, updating the teardown state of the peer addresses the problem. Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version. Signed-off-by: Manikanta Pubbisetty <mpubbise(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 | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6054,6 +6054,16 @@ static int ath10k_sta_state(struct ieee8 "mac vdev %d peer delete %pM sta %pK (sta gone)\n", arvif->vdev_id, sta->addr, sta); + if (sta->tdls) { + ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id, + sta, + WMI_TDLS_PEER_STATE_TEARDOWN); + if (ret) + ath10k_warn(ar, "failed to update tdls peer state for %pM state %d: %i\n", + sta->addr, + WMI_TDLS_PEER_STATE_TEARDOWN, ret); + } + ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr); if (ret) ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n", Patches currently in stable-queue which might be from mpubbise(a)qti.qualcomm.com are queue-4.9/ath10k-update-tdls-teardown-state-to-target.patch

7 years, 7 months

1
0
0 0

Patch "ath10k: fix invalid STS_CAP_OFFSET_MASK" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.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-invalid-sts_cap_offset_mask.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: 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 @@ -5017,7 +5017,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.9/ath10k-fix-invalid-sts_cap_offset_mask.patch

7 years, 7 months

1
0
0 0

Patch "ath10k: fix fetching channel during potential radar detection" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

Patch "ath10k: fix compile time sanity check for CE4 buffer size" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

Patch "ath10k: fix a warning during channel switch with multiple vaps" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

Patch "ath10k: disallow DFS simulation if DFS channel is not enabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

Patch "ASoC: rt5677: Add OF device ID table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

Patch "ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror