Re: [PATCH] wlcore: Fix BUG with clear completion on timeout
Hi,
* Adam Ford [181130 13:16]:
> On Fri, Oct 5, 2018 at 3:33 AM Kalle Valo wrote:
> >
> > Tony Lindgren wrote:
> >
> > > We do not currently clear wl->elp_compl on ELP timeout and we have bogus
> > > lingering pointer that wlcore_irq then will try to access after recovery
> > > is done:
> > >
> > > BUG: spinlock bad magic on CPU#1, irq/255-wl12xx/580
> > > ...
> > > (spin_dump) from [] (do_raw_spin_lock+0xc8/0x124)
> > > (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x68/0x74)
> > > (_raw_spin_lock_irqsave) from [] (complete+0x24/0x58)
> > > (complete) from [] (wlcore_irq+0x48/0x17c [wlcore])
> > > (wlcore_irq [wlcore]) from [] (irq_thread_fn+0x2c/0x64)
> > > (irq_thread_fn) from [] (irq_thread+0x148/0x290)
> > > (irq_thread) from [] (kthread+0x160/0x17c)
> > > (kthread) from [] (ret_from_fork+0x14/0x20)
> > > ...
> > >
> > > After that the system will hang. Let's fix this by adding a flag for
> > > recovery and moving the recovery work call to to the error handling
> > > section.
> > >
> > > And we want to set WL1271_FLAG_INTENDED_FW_RECOVERY and actually clear
> > > it too in wl1271_recovery_work() and just downgrade the error to a
> > > warning to prevent overly verbose output.
> > >
>
> Do we know how far back this bug goes and which versions need this
> patch applied to it? I have seen something similar on 4.19, but I
> haven't tried this patch to fix it. It wasn't clear to me if this is
> linux-next or 4.19 or something different.
I'm not sure if this is needed for v4.19 as the wakeirq patch
is not there. Maybe give it a try and see if it helps with
the issue you're seeing, then request inclusion for stable if
it helps?
BTW any wlcore issues with earlier kernels should be separately
debugged and tested. Fixes done after changing wlcore to use
PM runtime and wakeirq may be incomple for earlier kernels,
that's the two commits and below and any changes related to them.
And in general there seems to be two categories of common issues
with wlcore that I've seen: GPIO interrupt not behaving with the
SoC or old firmware being used for wlcore.
Regards,
Tony
8< -
3c83dd577c7f ("wlcore: Add support for optional wakeirq")
fa2648a34e73 ("wlcore: Add support for runtime PM")
Any interest in more details for radar events?
Hello, I notice that ath10k can report PRI and some other details for radar events. Any interest in being able to propagate that up to the netlink radar event so that 'iw event' and similar could report the details? In addition, how about allowing an 'ignored' flag so we can pass up a radar event that will propagate to user-space, but should be ignored by the kernel as far as making any changes to the regulatory logic. User-space could ignore it as desired. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] wlcore: Fix BUG with clear completion on timeout
On Fri, Oct 5, 2018 at 3:33 AM Kalle Valo wrote: > > Tony Lindgren wrote: > > > We do not currently clear wl->elp_compl on ELP timeout and we have bogus > > lingering pointer that wlcore_irq then will try to access after recovery > > is done: > > > > BUG: spinlock bad magic on CPU#1, irq/255-wl12xx/580 > > ... > > (spin_dump) from [] (do_raw_spin_lock+0xc8/0x124) > > (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x68/0x74) > > (_raw_spin_lock_irqsave) from [] (complete+0x24/0x58) > > (complete) from [] (wlcore_irq+0x48/0x17c [wlcore]) > > (wlcore_irq [wlcore]) from [] (irq_thread_fn+0x2c/0x64) > > (irq_thread_fn) from [] (irq_thread+0x148/0x290) > > (irq_thread) from [] (kthread+0x160/0x17c) > > (kthread) from [] (ret_from_fork+0x14/0x20) > > ... > > > > After that the system will hang. Let's fix this by adding a flag for > > recovery and moving the recovery work call to to the error handling > > section. > > > > And we want to set WL1271_FLAG_INTENDED_FW_RECOVERY and actually clear > > it too in wl1271_recovery_work() and just downgrade the error to a > > warning to prevent overly verbose output. > > Do we know how far back this bug goes and which versions need this patch applied to it? I have seen something similar on 4.19, but I haven't tried this patch to fix it. It wasn't clear to me if this is linux-next or 4.19 or something different. thanks adam > > Cc: Eyal Reizer > > Signed-off-by: Tony Lindgren > > Patch applied to wireless-drivers-next.git, thanks. > > 4e651bad8489 wlcore: Fix BUG with clear completion on timeout > > -- > https://patchwork.kernel.org/patch/10622767/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches >
pull request: mt76 2018-11-30
Hi Kalle, here's my first pull request for 4.21 - Felix The following changes since commit b72c51a58e6d63ef673ac96b8ab5bc98799c5f7b: brcmfmac: Fix out of bounds memory access during fw load (2018-11-29 17:33:10 +0200) are available in the Git repository at: https://github.com/nbd168/wireless tags/mt76-for-kvalo-2018-11-30 for you to fetch changes up to e28487ea84a9c081c6d8d7da319427f7fcc32ff5: mt76: replace sta_add/remove ops with common sta_state function (2018-11-30 12:30:37 +0100) first batch of mt76 patches for 4.21 * use the same firmware for mt76x2e and mt76x2u * mt76x2 fixes * mt76x0 fixes * mt76x0e survey support * more unification between mt76x2 and mt76x0 * mt76x0e AP mode support * mt76x0e DFS support * rework and fix tx status handling for mt76x0 and mt76x2 Felix Fietkau (13): mt76: clean up unused leftover EXPORT_SYMBOLs mt76: mt76x0: handle chip specific initval differences mt76: clean up more unused EXPORT_SYMBOLs mt76: mt76x02: skip station tx status for non-sta wcid entries mt76: mt76x02: only override control->sta on sw-encrypted tx mt76: add support for reporting tx status with skb mt76: avoid queue/status spinlocks while passing tx status to mac80211 mt76: do not wake tx queues during flush mt76: fix race condition in station removal mt76: add mt76_sta_remove helper mt76: mt76x02: make group_wcid the first member in struct mt76x02_vif mt76: mt76x02: remove mt76x02_txq_init mt76: replace sta_add/remove ops with common sta_state function Lorenzo Bianconi (49): mt76x2: align mt76x2 and mt76x2u firmware mt76x2u: align channel gain logic to mt76x2 one mt76x0: phy: use proper name convention mt76x0: phy: simplify rf configuration routines mt76x0: phy: improve code readability in initvals_phy.h mt76x0: pci: add get_survey support mt76: move mt76x02_mac_work routine in mt76x02-lib module mt76: move mt76x02_debugfs in mt76x02-lib module mt76x0: use shared debugfs implementation mt76x0: use mt76x02_mac_work as stats handler mt76x2u: introduce mac workqueue support mt76x0: phy: unify calibration between mt76x0u and mt76x0e mt76: usb: fix static tracepoints mt76x0: init: simplify mt76x0_init_mac_registers mt76x0: pci: add missing MODULE_FIRMWARE macro mt76x0: mac: remove mt76x0_mac_set_ampdu_factor mt76x0: align mt76x0u and mt76x0e fw version mt76: move mt76x02_mac_set_short_preamble in mt76x02_mac.c mt76: move mt76x02_init_device in mt76x02-lib module mt76: move mac beacon routines in mt76x02-lib module mt76: move tx beacon routines in mt76x02-lib module mt76x0: pci: add pre_tbtt_tasklet support mt76: move mt76x02_sw_scan and mt76x02_sw_scan_complete in mt76x02-lib module mt76: move mt76x02_get_txpower in mt76x02_util.c mt76: move mt76x02_sta_ps in mt76x02-lib module mt76: introduce mt76x02_init_beacon_config routine mt76x0: pci: enable AP support mt76: move mt76x02_set_tx_ackto in mt76x02-lib module mt76x0: update init vals for MT_TX_PROT registers mt76: move tx protection routines in mt76x02-lib module mt76: move mt76x02_bss_info_changed in mt76x02-lib module mt76: move dfs support in mt76x02-lib module mt76x0: pci: add DFS support mt76x0: phy: use mt76_poll_msec in mt76x0_phy_temp_sensor mt76x0: init: use mt76x02_mac_shared_key_setup in mt76x0_init_hardware mt76x2: move wcid_tx_rate conf at bootstrap mt76x0: init: use mt76x02_mac_wcid_setup for wcid configuration mt76x2u: init: remove not useful configuration mt76x2u: init: use common routines for wcid/key initialization mt76: move mt76x02_eeprom_copy in mt76x02-lib module mt76x0: phy: introduce tssi calibration support mt76x0: phy: use tssi reported value to configure tx power if available mt76x0: dfs: fix IBI_R11 configuration on non-radar channels mt76: introduce mt76x02_config_mac_addr_list routine mt76x0: pci: enable VHT rates in IBSS mode mt76x2u: phy: add TX_SHAPING calibration mt76x2u: phy: run phy_channel_calibrate after channel switch mt76x2u: main: use mt76x02_bss_info_changed utility routine mt76x2u: init: remove mt76x2u_init_beacon_offsets routine Stanislaw Gruszka (10): mt76x0: do not perform MCU calibration for MT7630 mt76x0: antenna select corrections mt76x0: do not overwrite other MT_BBP(AGC, 8) fields mt76x0: use band parameter for LC calibration mt76: remove mcu_msg_alloc mt76: remove wait argument from mt76x02_mcu_function_select mt76: remove wait argument from mt76x02_mcu_set_radio_state mt76x02: run calibration after scanning mt76x02: assure we update
Re: [PATCH v2 00/13] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips
On Fri, Nov 16, 2018 at 07:31:06PM +0800, yhchu...@realtek.com wrote: > From: Yan-Hsuan Chuang > > This is a new mac80211 driver for Realtek 802.11ac wireless network chips. > rtw88 supports 8822BE and 8822CE chips, and will be able to support > multi-vif combinations in run-time. > > For now, only PCI bus is supported, but rtw88 was originally designed > to optionally support three buses includes USB & SDIO. USB & SDIO modules > will soon be supported by rtw88, with configurable core module to fit > with different bus modules in the same time. > > For example, if we choose 8822BE and 8822CU, only PCI & USB modules will > be selected, built, loaded into kernel. This is one of the major > difference from rtlwifi, which can only support specific combinations. > > Another difference from rtlwifi is that rtw88 is designed to support > the latest Realtek 802.11ac wireless network chips like 8822B and > 8822C series. Compared to the earlier chips supported by rtlwifi like > the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs > have different MAC & PHY settings, such as new multi-port feature for the > MAC layer design and Jaguar2/Jaguar3 PHY layer IPs. > > Multi-Port feature is also supported under rtw88's software architecture. > rtlwifi can only support one vif in the same time, most because of the > hardware limitations for early chips, hence the original design of it > also restricts the usage of multi-vif support, so latest chipset seems not > take advantages from its new MAC engine. > > However, rtw88 can run multiple vifs concurrently by holding them on > hardware ports provided by MAC engine, hence can easily start different > roles on a single device. > > Based on the reasons mentioned before, we implemented rtw88. It had many > authors, they are listed here alphabetically: > > Ping-Ke Shih > Tzu-En Huang > Yan-Hsuan Chuang For the series: Reviewed-by: Stanislaw Gruszka
[PATCH] nl80211/cfg80211: Add support to specify band specific min rssi thresholds with sched scan
Earlier, we have provision to specify a single minimum rssi threshold
min_rssi_thold to drivers which is band agnostic. Add support to configure
drivers with different minimum rssi thresholds for different bands used for
scan results filtering. User space tools shall use NL80211_BAND_* variables
defined in enum nl80211_band as attribute types and the rssi thresholds as
values to form each of the band specific attributes. Such attributes shall
be nested in NL80211_ATTR_SCHED_SCAN_MIN_RSSI attribute.
Also, use new attributes and variables to move away from the earlier design
which has the confusion created by match_set with
NL80211_SCHED_SCAN_MATCH_ATTR_RSSI attribute alone to
be considered as minimum rssi threshold for all matchsets that doesn't have
NL80211_SCHED_SCAN_MATCH_ATTR_RSSI attribute. With this commit, for the
matchsets which doesn't have NL80211_SCHED_SCAN_MATCH_ATTR_RSSI attribute
alone to will use @band_specific_min_rssi_thold as minimum rssi threshold.
For the matchsets that user space configures with some rssi threshold, the
rssi threshold that is configured within matchset will have higher
precedence compared to the band specific rssi thresholds configured with
%NL80211_ATTR_SCHED_SCAN_MIN_RSSI attribute. In other words, if the rssi
value configured with a specific match set(match_set[x].rssi_thold) is not
equal to %NL80211_SCAN_RSSI_THOLD_OFF then match_set[x].rssi_thold value
shall be used scan results filtering that belong to the match set.
Otherwise, if match_set[x].rssi_thold is equals to
%NL80211_SCAN_RSSI_THOLD_OFF then the rssi threshold values configured with
@band_specific_min_rssi_thold shall be used for filtering scan results that
belong to such match set.
The drivers with capability to filter scan results with different rssi
thresholds for different bands shall indicate the support to user space by
setting %NL80211_EXT_FEATURE_SCHED_SCAN_BAND_SPECIFIC_RSSI_THOLD in
wiphy->ext_features. The drivers that support this feature shall use rssi
values from @band_specific_min_rssi_thold for scan results filtering and
shall not use min_rssi_thold anymore.
This commit adds support to specify band specific minimum rssi thresholds
applicable for all scan results but not different band specific rssi
thresholds for individual matchsets. This support can be added later when
needed.
Signed-off-by: vamsi krishna
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1fa41b7..c032375 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1848,7 +1848,10 @@ struct cfg80211_bss_select_adjust {
* @scan_start: start time of the scheduled scan
* @channels: channels to scan
* @min_rssi_thold: for drivers only supporting a single threshold, this
- * contains the minimum over all matchsets
+ * contains the minimum over all matchsets. This parameter is obsolete for
+ * the drivers that support scan results filtering with band specific rssi
+ * thresholds feature associated with
+ * %NL80211_EXT_FEATURE_SCHED_SCAN_BAND_SPECIFIC_RSSI_THOLD capability.
* @mac_addr: MAC address used with randomisation
* @mac_addr_mask: MAC address mask used with randomisation, bits that
* are 0 in the mask should be randomised, bits that are 1 should
@@ -1875,6 +1878,12 @@ struct cfg80211_bss_select_adjust {
* using @relative_rssi. If delta is a negative number, the BSSs that
* belong to the specified band will be penalized by delta dB in relative
* comparisions.
+ * @band_specific_min_rssi_thold: Minimum rssi threshold for each band to be
+ * applied to filter out scan results received. Drivers that support band
+ * specific rssi based filtering and sets the corresponding capability bit
+ * %NL80211_EXT_FEATURE_SCHED_SCAN_BAND_SPECIFIC_RSSI_THOLD will use these
+ * rssi thresholds for filtering scan results and will ignore rssi value
+ * provided in @min_rssi_thold.
*/
struct cfg80211_sched_scan_request {
u64 reqid;
@@ -1908,6 +1917,7 @@ struct cfg80211_sched_scan_request {
u32 owner_nlportid;
bool nl_owner_dead;
struct list_head list;
+ s32 band_specific_min_rssi_thold[NUM_NL80211_BANDS];
/* keep last */
struct ieee80211_channel *channels[0];
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6d610ba..0d4dd14 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2254,6 +2254,22 @@ enum nl80211_commands {
* @NL80211_ATTR_FTM_RESPONDER_STATS: Nested attribute with FTM responder
* statistics, see nl80211_ftm_responder_stats.
*
+ * @NL80211_ATTR_SCHED_SCAN_MIN_RSSI: Nested attribute that carries the band
+ * specific minimum rssi thresholds for the bands defined in enum
+ * nl80211_band. The minimum rssi threshold value(s32) specific to a band
+ * shall be encapsulated in attribute with type value equals to one of the
+ * NL80211_BAND_* defined in enum nl80211_band. For example, the
