Re: pull-request: iwlwifi 2018-11-15
Luca Coelho writes: > Hi Kalle, > > This is the first batch of fixes for v4.20. More details about the > contents in the tag description. > > I have sent this out before and kbuildbot reported success. > > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit b374e8686fc35ae124e62dc78725ea656ba1ef8a: > > mt76: fix building without CONFIG_LEDS_CLASS (2018-11-06 18:46:33 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-for-kalle-2018-11-15 > > for you to fetch changes up to 5d041c46ccb9b48acc110e214beff5e2789311df: > > iwlwifi: mvm: don't use SAR Geo if basic SAR is not used (2018-11-15 > 23:50:59 +0200) > > > First batch of iwlwifi fixes for 4.20 > > * New FW debugging infrastructure; > * Some more work on 802.11ax; > * Improve support for multiple RF modules with 22000 devices; > * Remove an unused FW parameter; > * Other debugging improvements; > > Pulled, thanks. -- Kalle Valo
[PATCH] uapi/nl80211: fix spelling errors
Spelling errors found by codespell
Signed-off-by: Stephen Hemminger
---
include/uapi/linux/nl80211.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6d610bae30a9..da3ea1f75006 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1706,7 +1706,7 @@ enum nl80211_commands {
* the values passed in @NL80211_ATTR_SCAN_SSIDS (eg. if an SSID
* is included in the probe request, but the match attributes
* will never let it go through), -EINVAL may be returned.
- * If ommited, no filtering is done.
+ * If omitted, no filtering is done.
*
* @NL80211_ATTR_INTERFACE_COMBINATIONS: Nested attribute listing the supported
* interface combinations. In each nested item, it contains attributes
@@ -1811,7 +1811,7 @@ enum nl80211_commands {
*
* @NL80211_ATTR_INACTIVITY_TIMEOUT: timeout value in seconds, this can be
* used by the drivers which has MLME in firmware and does not have support
- * to report per station tx/rx activity to free up the staion entry from
+ * to report per station tx/rx activity to free up the station entry from
* the list. This needs to be used when the driver advertises the
* capability to timeout the stations.
*
@@ -2172,7 +2172,7 @@ enum nl80211_commands {
*
* @NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST: When present the RSSI level for BSSs
in
* the specified band is to be adjusted before doing
- * %NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI based comparision to figure out
+ * %NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI based comparison to figure out
* better BSSs. The attribute value is a packed structure
* value as specified by nl80211_bss_select_rssi_adjust.
*
@@ -4859,7 +4859,7 @@ enum nl80211_iface_limit_attrs {
* numbers = [ #{STA} <= 1, #{P2P-client,P2P-GO} <= 3 ], max = 4
* => allows a STA plus three P2P interfaces
*
- * The list of these four possiblities could completely be contained
+ * The list of these four possibilities could completely be contained
* within the %NL80211_ATTR_INTERFACE_COMBINATIONS attribute to indicate
* that any of these groups must match.
*
@@ -4889,7 +4889,7 @@ enum nl80211_if_combination_attrs {
* enum nl80211_plink_state - state of a mesh peer link finite state machine
*
* @NL80211_PLINK_LISTEN: initial state, considered the implicit
- * state of non existant mesh peer links
+ * state of non existent mesh peer links
* @NL80211_PLINK_OPN_SNT: mesh plink open frame has been sent to
* this mesh peer
* @NL80211_PLINK_OPN_RCVD: mesh plink open frame has been received
@@ -5381,7 +5381,7 @@ enum nl80211_timeout_reason {
* request parameters IE in the probe request
* @NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP: accept broadcast probe responses
* @NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE: send probe request frames at
- * rate of at least 5.5M. In case non OCE AP is dicovered in the channel,
+ * rate of at least 5.5M. In case non OCE AP is discovered in the channel,
* only the first probe req in the channel will be sent in high rate.
* @NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION: allow probe request
* tx deferral (dot11FILSProbeDelay shall be set to 15ms)
--
2.17.1
pull-request: iwlwifi 2018-11-15
Hi Kalle, This is the first batch of fixes for v4.20. More details about the contents in the tag description. I have sent this out before and kbuildbot reported success. Please let me know if there are any issues. Cheers, Luca. The following changes since commit b374e8686fc35ae124e62dc78725ea656ba1ef8a: mt76: fix building without CONFIG_LEDS_CLASS (2018-11-06 18:46:33 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-for-kalle-2018-11-15 for you to fetch changes up to 5d041c46ccb9b48acc110e214beff5e2789311df: iwlwifi: mvm: don't use SAR Geo if basic SAR is not used (2018-11-15 23:50:59 +0200) First batch of iwlwifi fixes for 4.20 * New FW debugging infrastructure; * Some more work on 802.11ax; * Improve support for multiple RF modules with 22000 devices; * Remove an unused FW parameter; * Other debugging improvements; Emmanuel Grumbach (2): iwlwifi: mvm: support sta_statistics() even on older firmware iwlwifi: mvm: fix regulatory domain update when the firmware starts Luca Coelho (1): iwlwifi: mvm: don't use SAR Geo if basic SAR is not used Matt Chen (1): iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE Shahar S Matityahu (1): iwlwifi: fix D3 debug data buffer memory leak drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 4 +++- drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 6 +- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 38 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 12 ++-- drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 5 ++--- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 ++ 6 files changed, 47 insertions(+), 20 deletions(-) signature.asc Description: This is a digitally signed message part
Re: AP6335 with mainline kernel
Hi Arend, On Wed, Nov 14, 2018 at 9:41 AM Arend van Spriel wrote: > > + Cameron > > On 3/26/2018 3:34 PM, Vanessa Maegima wrote: > > On Seg, 2018-03-26 at 09:24 -0300, Vanessa Maegima wrote: > >> Hi Arend, > >> > >>> > >>> Here's the hexdump: http://code.bulix.org/trv3o7-306254 > >>> > >> The link above provides the hexdump from the html nvram, which makes > >> wifi work on pico-imx7d. > >> > >> I also got the hexdump of the nvram file provided by TechNexion for > >> comparison, which returns the error "brcmfmac: brcmf_sdio_htclk: HT > >> Avail timeout (100): clkctl 0x50": http://code.bulix.org/mw4x62-3 > >> 09 > >> 095 > > > > Fixing second URL: http://code.bulix.org/mw4x62-309095 > > Hi Vanessa, > > It has been a while, but recently I was contacted by Cameron who was > facing same/similar issue. After some email exchanges with him he > uncovered that the problem with the TechNexion nvram file is with the > boardflags3 entry. On my suggestion he change the value from 0x08101188 > to 0x101188. The dropped bit forces the clock hierarchy in the chip to > select external LPO. I found some schematics showing a 32kHz signal > hooked up to the LPO input coming from GPIO1_IO03. Could it be that it > is not properly setup? Devicetree maybe? > > Regards, > Arend > Thanks for the suggestion. I will investigate this on my side next week when I have my Pico board and I will let you know any feedback. Best Regards, Vanessa
Re: [RFC v4 08/13] rtw88: debug files
Joe Perches writes: > On Thu, 2018-11-15 at 16:15 +0200, Kalle Valo wrote: >> Joe Perches writes: >> >> > On Sat, 2018-10-13 at 13:28 -0700, Joe Perches wrote: >> > > On Sat, 2018-10-13 at 18:23 +0300, Kalle Valo wrote: >> > > > Joe Perches writes: >> > [] >> > > > > It's very unusual to have _all_ the logging under a >> > > > > CONFIG__DEBUG >> > > > > config guard flag. >> > > > >> > > > For wireless drivers that is actually quite typical. >> > > >> > > No, it isn't. >> > > >> > > > IIRC at least ath6kl, ath9k and ath10k do that, most likely also >> > > > others. >> > > >> > > No, they don't. Check again. > [] >> > Kalle, did I miss a reply here? >> >> I didn't bother to waste my time after reading comments like "check >> again" and "look harder". > > You are the maintainer here and you give advice that others are > likely to follow. > > I was a bit frustrated after your fairly assertive, but wrong > statement that the other drivers you maintain do the same thing. Yeah, I can understand that. But do note that I'm a non-native english speaker with an always full inbox, I don't have time nor skills to write in a way expected by a native speaker. So please don't assume that I'm assertive or other meanings from my style of text, just consider that my writings as "simple english". Also I do a lot of mistakes, and when I do please just clearly explain it to me. I'm always grateful about that, all constructive help is very welcome. -- Kalle Valo
Re: [RFC v4 08/13] rtw88: debug files
On Thu, 2018-11-15 at 16:15 +0200, Kalle Valo wrote: > Joe Perches writes: > > > On Sat, 2018-10-13 at 13:28 -0700, Joe Perches wrote: > > > On Sat, 2018-10-13 at 18:23 +0300, Kalle Valo wrote: > > > > Joe Perches writes: > > [] > > > > > It's very unusual to have _all_ the logging under a CONFIG__DEBUG > > > > > config guard flag. > > > > > > > > For wireless drivers that is actually quite typical. > > > > > > No, it isn't. > > > > > > > IIRC at least ath6kl, ath9k and ath10k do that, most likely also others. > > > > > > No, they don't. Check again. [] > > Kalle, did I miss a reply here? > > I didn't bother to waste my time after reading comments like "check > again" and "look harder". You are the maintainer here and you give advice that others are likely to follow. I was a bit frustrated after your fairly assertive, but wrong statement that the other drivers you maintain do the same thing.
Re: pull-request: iwlwifi-next 2018-11-11
Luca Coelho writes: > This is the first batch of patches intended for v4.21. This includes > only the last patchset I sent. Usual development work, new PCI IDs and > small fixes and cleanups. More details about the contents in the tag > description. > > I have sent this out before and kbuildbot reported success. > > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit bb38177cb6c6dc973ad8b88f219742b29f3002f1: > > Merge ath-next from > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-11-09 > 17:15:25 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-next-for-kalle-2018-11-11 > > for you to fetch changes up to 56b657f7f9c07421a4f910b7e2b382184f1ddbc8: > > iwlwifi: fw: use helper to determine whether to dump paging (2018-11-11 > 11:06:23 +0200) > > > First set of iwlwifi patches for 4.21 > > * PCI IDs for some new 9000-series cards; > * Improve antenna usage on connection problems; > * Some improvements in the debugging code; > * Other clean-ups and small fixes; > > Pulled, thanks. -- Kalle Valo
Re: [PATCH 08/16] iwlwifi: trans: parse and store debug ini TLVs
Luca Coelho writes: > From: Sara Sharon > > The new debug ini TLVs can be either packed into firmware > binary or written in external file. Support loading them > from both. Store the data per apply point. Apply point is > a point during driver runtime, where the TLV becomes active. > For example, a trigger of hardware error may be configured > to collect a subset of data pre-alive, as a opposed to HW > error that occurs after alive. > > Signed-off-by: Sara Sharon > Signed-off-by: Luca Coelho [...] > @@ -1749,6 +1762,10 @@ MODULE_PARM_DESC(lar_disable, "disable LAR > functionality (default: N)"); > module_param_named(uapsd_disable, iwlwifi_mod_params.uapsd_disable, uint, > 0644); > MODULE_PARM_DESC(uapsd_disable, >"disable U-APSD functionality bitmap 1: BSS 2: P2P Client > (default: 3)"); > +module_param_named(enable_ini, iwlwifi_mod_params.enable_ini, > +bool, S_IRUGO | S_IWUSR); > +MODULE_PARM_DESC(enable_ini, > + "Enable debug INI TLV FW debug infrastructure (default: 0"); The commit log doesn't mention anything about the module parameter and how/when it's supposed to be used, that would be nice to have. -- Kalle Valo
Re: [PATCH 1/6] brcmfmac: Remove firmware-loading code duplication
Hans de Goede writes: > Hi, > > On 05-11-18 16:05, Kalle Valo wrote: >> Arend van Spriel writes: >> >>> On 10/9/2018 2:47 PM, Hans de Goede wrote: brcmf_fw_request_next_item and brcmf_fw_request_done both have identical code to complete the fw-request depending on the item-type. This commit adds a new brcmf_fw_complete_request helper removing this code duplication. >>> >>> Reviewed-by: Arend van Spriel >> >> For some reason you commented on v1 but there was v2 posted already: >> >> https://patchwork.kernel.org/patch/10634355/ >> >> I guess I can take v2 still? > > Yes the only thing different in v2 was dropping the SPDX license header > for the new drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c > file and replacing it with the full ISC license text as seen in other > brcmfmac files. Nothing else was changed, so the review of v1 is > valid for v2 too. > > Arend had one very minor comment on the name of a variable in the fifth > patch, but that is not important so if you want to pick up v2 as is > go for it. > > Note the ISC license text is now in Torvald's tree as: > LICENSES/other/ISC > > So could even go with v1, but I guess you prefer to move all files of > a driver over to the SPDX headers in one go ... Correct, I really would prefer move to SPDX headers in one go. -- Kalle Valo
Re: [RFC v3 01/12] rtw88: main files
Tony Chuang writes:
>> -Original Message-
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Sunday, October 14, 2018 1:48 AM
>> To: Tony Chuang
>> Cc: Johannes Berg; larry.fin...@lwfinger.net; Pkshih; Andy Huang;
>> sgrus...@redhat.com; linux-wireless@vger.kernel.org
>> Subject: Re: [RFC v3 01/12] rtw88: main files
>>
>> Tony Chuang writes:
>>
>> >> > +static void rtw_watch_dog_work(struct work_struct *work)
>> >> > +{
>> >> > + struct rtw_dev *rtwdev = container_of(work, struct rtw_dev,
>> >> > + watch_dog_work.work);
>> >> > + struct rtw_vif *rtwvif;
>> >> > +
>> >> > + if (!rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
>> >> > + return;
>> >> > +
>> >> > + ieee80211_queue_delayed_work(rtwdev->hw,
>> >> >watch_dog_work,
>> >> > +RTW_WATCH_DOG_DELAY_TIME);
>> >>
>> >> You're aware of the power cost of waking up every 2 seconds? That's a
>> >> really bad idea, in general, at the very least you should use a more
>> >> power efficient scheduling here to combine with other wakeups
>> >> (round_jiffies_relative, or so).
>> >
>> > Yeah I knew it, but so far we can only work like this...
>> > Will use round_jiffies_relative to combine the CPU wakeups.
>>
>> Can you elaborate more why this horrible timer is needed? And it
>> definitely needs a comment in the code explaining the reason.
>>
>
>
> The watchdog timer is required for our devices to enhance the performance.
> It does a lot of tx/rx statistics processing for the hardware.
> Those information process routines help the devices to adapt to the
> environment.
>
> However, status polling every two seconds is not a good solution.
> But it makes drive simpler to be implemented.
>
> We will try to change it to interrupt mode.
> But it will take a lot of time to work on it.
> So, before it's done, I think we can leave the timer here.
Yeah, interrupt mode sounds like a much better idea. But if you have to
keep two second polling at least add a proper comment to the code
explaining what you said above.
--
Kalle Valo
Re: [RFC v4 08/13] rtw88: debug files
Joe Perches writes: > On Sat, 2018-10-13 at 13:28 -0700, Joe Perches wrote: >> On Sat, 2018-10-13 at 18:23 +0300, Kalle Valo wrote: >> > Joe Perches writes: > [] >> > > It's very unusual to have _all_ the logging under a CONFIG__DEBUG >> > > config guard flag. >> > >> > For wireless drivers that is actually quite typical. >> >> No, it isn't. >> >> > IIRC at least ath6kl, ath9k and ath10k do that, most likely also others. >> >> No, they don't. Check again. >> >> > > Typical debugging would dynamic debugging on a per-line instance andl >> > > this uses a single dev_dbg for all debugging. >> > >> > I don't recall seeing anyone using per-line dynamic debugging with >> > wireless drivers. The drivers are so complex that enabling one message >> > at a time doesn't really get you anywhere, that's why we mostly group >> > messages into similar groups (or levels) to make it easier to enable >> > certain debug messages. >> >> You should look harder. >> >> > > This seems unnecessarily complexity for a negative gain. >> > >> > I haven't reviewed the driver yet but from a quick look I don't see this >> > as a problem. >> >> It is unnecessarily complex. >> This saves one dereference per call, but is it really worth it? > > Kalle, did I miss a reply here? I didn't bother to waste my time after reading comments like "check again" and "look harder". -- Kalle Valo
Re: [RFC 00/19] wilc: added driver for wilc module
writes: > On 10/08/2018 12:38 AM, Kalle Valo wrote: >> Ajay Singh writes: >> >>> On Sat, 6 Oct 2018 15:45:41 +0300 >>> Kalle Valo wrote: >>> Ajay Singh writes: > This patch set contains the driver files from > 'driver/staging/wilc1000'. Renamed the driver from 'wilc1000' to > 'wilc' to have generic name, as the same driver will be used by > other wilc family members. I'm worried that the name 'wilc' is just too generic, I liked the original name wilc1000 much more. Quite often when we have a new generation of wireless devices there's also a new driver, so in the long run I'm worried that a generic name like 'wilc' could be a source of confusion. I think it's much smaller problem if 'wilc1000' (the driver) also supports wilc3000 (the device), people are already used to that. > >> If I'm understanding correctly you are worried that 'wilc1000-spi.ko' >> also supports wilc3000 devices, but I don't see that as a problem. I >> think it's very common (not just in wireless) that the marketing names >> don't always match with driver names. >> > > It's highly unlikely that microchip will have a new generation of wilc > devices other than wilc1000 and wilc3000, since a new family is > already in development. > And in case a new generation was developed, it will be best to support > it in the current driver because of the similarities between wilc > devices. > > I'm afraid that it might be more confusing for users to use wilc1000 > naming while they are using wilc3000 hardware. It's not only that the > name that is different from the marketing name, but it also refers to > another existing product. Well, I see it very differently. For example, if I google 'wilc1000' I get directly to the product page but with 'wilc' I get nothing useful. And I have been dealing with marketing for so long that "never say never" about what they will decide ;) So I'm still not convinced that renaming is a good idea. But actually my opinion doesn't matter here, as the rename should happen in the staging tree (when the driver is moved from staging to drivers/net/wireless it should be a simple rename, no other changes). So I'll leave this for Greg to decide if the rename is worthwhile or not. My vote would be a clear "no" :) -- Kalle Valo
Re: [EXTERNAL] [PATCH] ath9k_htc: add fw 1.4.1
(fixing quotation, PLEASE don't top post) Tom Psyborg writes: >> On 6 September 2018 at 17:32, Kalle Valo wrote: >> >> Tomislav Požega writes: >> >> > Add firmware v1.4.1 that supports up to 8 virtual APs and up >> > to 16 (current limit, at least on AR9271) client interfaces. >> > (1 AP + 15 STA, 4 AP + 12 STA etc) >> > >> > Signed-off-by: Tomislav Požega >> > --- >> > ath9k_htc/htc_7010-1.4.1.fw | Bin 0 -> 72812 bytes >> > ath9k_htc/htc_9271-1.4.1.fw | Bin 0 -> 51008 bytes >> > 2 files changed, 0 insertions(+), 0 deletions(-) >> > create mode 100644 ath9k_htc/htc_7010-1.4.1.fw >> > create mode 100644 ath9k_htc/htc_9271-1.4.1.fw >> >> Is this is an official release from the open-ath9k-htc-firmware >> project >> or just some custom build of yours? I'm asking because I don't see >> anything in the master branch since January: >> >> https://github.com/qca/open-ath9k-htc-firmware/commits/master >> >> IMHO Adrian Chadd (CCed) should be the one pushing the ath9k_htc >> firmware image to linux-firmware, unless the maintainer has >> changed of >> course. > > I was not sure if the fw images from open-ath9k-htc-firmware project > are still being pulled into linux-firmware tree, so I created this > build myself to meet the requirements for one of the patches I sent to > linux-wireless list. As ath9k_htc firmere is open it's easy to create backdoors etc and this is why I think that linux-firmware should not take ath9k_htc firmware binaries just from anyone, only from maintainers of open-ath9k-htc-firmware project. > Adrian, can you push the new fw version via official channel? Adrian, can you help here? -- Kalle Valo
Re: [PATCH] mac80211_hwsim: Timer should be initialized before device registered
(fixing top posting) Vasyl Vavrychuk writes: > On Thu, Oct 18, 2018 at 1:02 AM Vasyl Vavrychuk > wrote: >> >> From: Vasyl Vavrychuk >> >> Otherwise if network manager starts configuring Wi-Fi interface >> immidiatelly after getting notification of its creation, we will get >> NULL pointer dereference: >> >> BUG: unable to handle kernel NULL pointer dereference at (null) >> IP: [] hrtimer_active+0x28/0x50 >> ... >> Call Trace: >>[] ? hrtimer_try_to_cancel+0x27/0x110 >>[] ? hrtimer_cancel+0x15/0x20 >>[] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim] >> >> Signed-off-by: Vasyl Vavrychuk > > Does anyone have some feedback about this? Johannes has applied it six days ago: https://patchwork.kernel.org/patch/10646105/ https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=a1881c9b8a1edef0a5ae1d5c1b61406fe3402114 To help the maintainers you can check yourself the status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork -- Kalle Valo
Re: [PATCH] mac80211_hwsim: Timer should be initialized before device registered
Does anyone have some feedback about this?
On Thu, Oct 18, 2018 at 1:02 AM Vasyl Vavrychuk
wrote:
>
> From: Vasyl Vavrychuk
>
> Otherwise if network manager starts configuring Wi-Fi interface
> immidiatelly after getting notification of its creation, we will get
> NULL pointer dereference:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [] hrtimer_active+0x28/0x50
> ...
> Call Trace:
>[] ? hrtimer_try_to_cancel+0x27/0x110
>[] ? hrtimer_cancel+0x15/0x20
>[] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]
>
> Signed-off-by: Vasyl Vavrychuk
> ---
> drivers/net/wireless/mac80211_hwsim.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/mac80211_hwsim.c
> b/drivers/net/wireless/mac80211_hwsim.c
> index 1068757ec42e..d0e0a9f5bf98 100644
> --- a/drivers/net/wireless/mac80211_hwsim.c
> +++ b/drivers/net/wireless/mac80211_hwsim.c
> @@ -2890,6 +2890,10 @@ static int mac80211_hwsim_new_radio(struct genl_info
> *info,
>
> wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
>
> + tasklet_hrtimer_init(>beacon_timer,
> +mac80211_hwsim_beacon,
> +CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> +
> err = ieee80211_register_hw(hw);
> if (err < 0) {
> pr_debug("mac80211_hwsim: ieee80211_register_hw failed
> (%d)\n",
> @@ -2914,10 +2918,6 @@ static int mac80211_hwsim_new_radio(struct genl_info
> *info,
> data->debugfs,
> data, _simulate_radar);
>
> - tasklet_hrtimer_init(>beacon_timer,
> -mac80211_hwsim_beacon,
> -CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> -
> spin_lock_bh(_radio_lock);
> err = rhashtable_insert_fast(_radios_rht, >rht,
> hwsim_rht_params);
> --
> 2.19.1
>
--
Vasyl Vavrychuk | Software Engineer
GlobalLogic L'viv
Skype: vasyl.vavrychuk
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
Re: [PATCH V2 8/8] brcmfmac: disable command decode in sdio_aos
On 2018/11/12 下午 06:33, Arend van Spriel wrote: > On 11/12/2018 8:30 AM, Chi-Hsien Lin wrote: >> From: Wright Feng >> >> AOS is a part of the SDIOD core that becomes active when the rest of >> SDIOD is sleeping to keep SDIO bus alive responding to reduced set of >> commands. >> >> Transaction between AOS and SDIOD is not protected, and if cmd 52 is >> received in AOS and in the middle of response state changed from AOS to >> SDIOD, response is corrupted and it causes to SDIO Host controller to >> hang. > > Just one question. The above sound pretty generic so does it apply to > any SDIO chip with AOS logic? > We found this issue when verifying SR feature with some SDIO cards(what we had), not sure whether every SDIO card has same problem. So we only change those chip's wake-up mechanism to noCmdDecode mode and let SDIOD_AOS just generates a wake-up request without responding. -Wright > Regards, > Arend > > >
