Re: feedback on mainlining wilc1000 staging driver
On Thu, 16 Aug 2018 13:53:50 +0300 Kalle Valo wrote: > Kalle Valo writes: > > > Ajay Singh writes: > > > >> Hi Greg, > >> > >> We all are working on submitting and reviewing patches for > >> wilc1000 in staging driver for quite some time. > >> > >> We would like to have feedback on the next steps to bring wilc1000 > >> driver closer to move into the wireless subsystem tree. > >> > >> In summary, the following major things from TODO have been > >> addressed in staging: > >> -remove the defined feature as kernel versions > >> -remove OS wrapper functions > >> -remove custom debug and tracing functions > >> -rework comments and function headers(also coding style) > >> -remove build warnings > >> -replace all semaphores with mutexes or completions > >> -make spi and sdio components coexist in one build > >> -turn compile-time platform configuration (BEAGLE_BOARD, > >> PANDA_BOARD, PLAT_WMS8304, PLAT_RK, CUSTOMER_PLATFORM, ...) > >> into run-time options that are read from DT > >> -replace SIOCDEVPRIVATE commands with generic API functions > >> -use wext-core handling instead of private SIOCSIWPRIV > >> implementation > > > > From wireless point of view: if I see wext mentioned anywhere in the > > driver I stop right there. cfg80211 is a hard requirement for us > > nowadays. > > Clarification: Depending on the hardware design either cfg80211 or > mac80211 is a hard requirement. I haven't checked wilc1000 at all so I > don't know what design it has but if it's a "softmac" design then it > has to use mac80211, we do not want to support multiple 802.11 UMAC > stacks. > The TODO item to make use of wext-core is obsolete. Previously wilc1000 driver also had few wext ioctl use but now it’s completely removed and cfg80211 operation callbacks are used. wilc1000 driver make use of cfg80211 and isn’t a "softmac". We need help to review and identify if there are any pending items for wilc1000 driver, so we can address those issues and make it ready to move to the wireless subsystem. Regards, Ajay
Re: [PATCH v6 2/3] mac80211: Define new driver callback replace_key
Hi Alexander, Just minor nitpicks: + * @replace_key: Replace an exiting in use key with a new one while guaranteeing + * to not leak clear text packets. Implementing this callback will enable + * mac80211 to announce NL80211_EXT_FEATURE_ATOMIC_KEY_REPLACE. + * Packets already queued must not be send out encrypted with the new key send out -> sent out + * and packets decoded with the old key must not be handed over to mac80211 + * when the driver is not checking IV/ICV itself once the callback has been + * completed. + * Mac80211 will log an error when asked to use replace a PTK key + * without replace_key but will still perform the then potentially + * insecure action via set_key for backward compatibility for now. + * Not sure this part really belongs in the driver method description? * @update_tkip_key: See the section "Hardware crypto acceleration" *This callback will be called in the context of Rx. Called for drivers *which set IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY. diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 4fb2709cb527..84cc8005c19a 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -572,9 +572,14 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t priv_data_len, NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT); } + if (ops->replace_key) + wiphy_ext_feature_set(wiphy, + NL80211_EXT_FEATURE_ATOMIC_KEY_REPLACE); + if (!ops->set_key) wiphy->flags |= WIPHY_FLAG_IBSS_RSN; + Stray whitespace? if (ops->wake_tx_queue) wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_TXQS); Regards, -Denis
Re: [PATCH v6 1/3] nl80211: Add ATOMIC_KEY_REPLACE API
Hi Alexander, On 08/14/2018 05:42 AM, Alexander Wetzel wrote: Drivers able to correctly replace a in-use key should set NL80211_EXT_FEATURE_ATOMIC_KEY_REPLACE to allow the userspace (e.g. hostapd or wpa_supplicant) to rekey PTK keys. The userspace must detect a PTK rekey attempt and only go ahead with the rekey when the driver has set this flag. If the driver is not supporting the feature the userspace either must not replace the PTK key or perform a full re-association. Ignoring this flag and continuing to rekey the connection can still work but has to be considered insecure and broken. It can leak cleartext packets or freeze the connection and is only supported to allow the userspace to be updated. Signed-off-by: Alexander Wetzel --- include/uapi/linux/nl80211.h | 6 ++ 1 file changed, 6 insertions(+) This looks good to me from a userspace perspective. I will try to implement support for this in iwd soon to give you a prototype to play with. Reviewed-by: Denis Kenzior Regards, -Denis
[PATCH] mac80211: WFA Multi-AP backhaul STA Rx requirement
The current mac80211 WDS (4-address mode) can be used to cover most of the Multi-AP requirements for Data frames per the WFA Multi-AP Specification v1.0. When configuring AP/STA interfaces in 4-address mode, they are able to function as fronthaul AP/backhaul STA of Multi-AP device complying below Tx, Rx requirements except one STA Rx requirement. Multi-AP specification section 14.1 describes the following requirements: Transmitter requirements 1. Fronthaul AP i) When DA!=RA of backhaul STA, must use 4-address format ii) When DA==RA of backhaul STA, shall use either 3-address or 4-address format with RA updated with STA MAC (mac80211 support 4-address format via AP/VLAN interface) 2. Backhaul STA i) When SA!=TA of backhaul STA, must use 4-address format ii) When SA==TA of backhaul STA, shall use either 3-address or 4-address format with RA updated with AP MAC (mac80211 support 4-address format via use_4addr) Receiver requirements - 1. Fronthaul AP i) When SA!=TA of backhaul STA, must support receiving 4-address format frames ii) When SA==TA of backhaul STA, must support receiving both 3-address and 4-address format frames (mac80211 support both 3-addr & 4-addr via AP/VLAN interface) 2. Backhaul STA i) When DA!=RA of backhaul STA, must support receiving 4-address format frames ii) When DA==RA of backhaul STA, must support receiving both 3-address and 4-address format frames (mac80211 support only receiving 4-address format via use_4addr) This patch addresses the above Rx requirement (ii) for backhaul STA. The current design doesn't accept 3-address frames when configured in 4-address mode (use_4addr). Hence add a check to allow 3-address frames when DA==RA of backhaul STA (adhering to Table 9-26 of IEEE Std 802.11™-2016). This case was tested with a bridged station interface when associated with a non-mac80211 based vendor AP implementation using 3-address frames for WDS. STA was able to support the Multi-AP Rx requirement when DA==RA. No issues, no loops seen when tested with mac80211 based AP as well. Verified and confirmed all other Tx and Rx requirements of AP and STA for Multi-AP respectively. They all work using the current mac80211-WDS design. Signed-off-by: Sathishkumar Muruganandam --- net/mac80211/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index a16ba568e2a3..686e5586e1f4 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -2313,7 +2313,7 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, bool *port_control) if (!sdata->u.mgd.use_4addr) return -1; - else + else if (!ether_addr_equal(hdr->addr1, sdata->vif.addr)) check_port_control = true; } -- 2.7.4
Re: [DEBUG PATCH] brcmfmac: add firmware watchdog running on host machine
On 8/15/2018 8:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
It may happen for FullMAC firmware to crash. It should be detected and
ideally somehow handled by a driver.
Since commit ff4445a8502c ("brcmfmac: expose device memory to
devcoredump subsystem") brcmfmac has BRCMF_E_PSM_WATCHDOG event handler
but it wasn't enough to detect all kind of crashes. E.g. Netgear R8000
(BCM4709A0 + 3 x BCM43602) user was exepriencing firmware crashes that
never resulted in passing BRCMF_E_PSM_WATCHDOG to the host driver.
Thanks, Rafał
The PSM watchdog is actually not a firmware crash. It means the lower
part of the stack, which runs in the d11 core aka PSM, did not complete
its work in the required timing budget.
That made me implement this trivial software watchdog that simply checks
periodically if firmware still replies to the commands.
Luckily this patch DOES NOT seem to be needed anymore since the commit
8a3ab2f38f16 ("brcmfmac: trigger memory dump upon firmware halt
signal"). That change allows brcmfmac to detect firmware crashes
successfully.
It can still miss a firmware crash if it happens really soon. Those
crashes mostly happens when trying to load firmware for chip revision A
on chip with revision B due to differences in code contained in ROM.
Regards,
Arend
This patch is being posted for research/debugging purposes only. It
SHOULD NOT be applied until someone notices a firmware crash that
doesn't trigger the BRCMF_D2H_DEV_FWHALT signal.
Signed-off-by: Rafał Miłecki
---
Re: wireless dongle causing entire machine to hang
On Thu, Aug 16, 2018 at 12:31:07PM +0200, Stanislaw Gruszka wrote:
> I prepared a patch that count EPROTO errors and if it's bigger
> than 10 mark device as gone. It should not make a problem
> when we will get one time random error. I'm attaching it,
> please test.
Forgot to compile the patch, here is one that compiles.
Cheers
Stanislaw
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 086aad2..60b8bcc 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -31,6 +31,22 @@
#include "rt2x00.h"
#include "rt2x00usb.h"
+static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
+{
+ if (status == -ENODEV || status == -ENOENT)
+ return true;
+
+ if (status == -EPROTO)
+ rt2x00dev->num_proto_errs++;
+ else
+ rt2x00dev->num_proto_errs = 0;
+
+ if (rt2x00dev->num_proto_errs > 10)
+ return true;
+
+ return false;
+}
+
/*
* Interfacing with the HW.
*/
@@ -57,7 +73,7 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
if (status >= 0)
return 0;
- if (status == -ENODEV || status == -ENOENT) {
+ if (rt2x00usb_check_usb_error(rt2x00dev, status)) {
/* Device has disappeared. */
clear_bit(DEVICE_STATE_PRESENT, >flags);
break;
@@ -321,7 +337,7 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry
*entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV || status == -ENOENT)
+ if (rt2x00usb_check_usb_error(rt2x00dev, status))
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
@@ -410,7 +426,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry
*entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV || status == -ENOENT)
+ if (rt2x00usb_check_usb_error(rt2x00dev, status))
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
Hello
On Thu, Aug 16, 2018 at 12:35:29AM +0200, Daniel Golle wrote:
> Clone the master branch of
> https://git.openwrt.org/openwrt/staging/dangole.git
> and give it shot and let us know the results.
Thanks!
> > Please also remove:
> > 600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
> > 991-rt2800_change_rx_ampdu_factor.patch
> > 992-rt2800_change_ba_size.patch
> > 993-rt2800_change_rx_ampdu_density.patch
> > Those are not needed and can be harmful with the test patches,
> > (especially spurious interrupt one, patches will not apply cleanly
> > with it).
>
> Ack. Hope it doesn't break Rt3883 and/or Rt3663 for which that patch
> was added by Gabor Juhos a decade ago...
The new patches change the way we handle TX status interrupt. I think
spurious interrupts were a problem because we do not disable the IRQ
and read statuses, so we could get interrupt after we empty TX_STA_FIFO
register. With current implementation this should not be an issue.
> > Another thing is fixing RATE_PROBE frames which are aggregated with
> > other frames and not sent at requested rate. I implemented qsel queue patch
> > similar to mt76, but this not work as expected on older Ralink chips.
> > https://github.com/sgruszka/wireless-drivers-next/commit/846d205edd8c36d1b7828fee54bf4cf40bf8cb1a
>
> Which hardware did you try? Just so I can reproduce what's going on
> and maybe help fixing it...
I tested on RT3062 PCI and some USB dongles, don't remember chip version.
Basically HW become unresponsive after sent some traffic.
I debugged the problem by printing sequence number and rate of RATE PROBE
frames by something like this:
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 92ddc19..d7f250b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
@@ -334,6 +334,12 @@ static void rt2x00queue_create_tx_descriptor_ht(struct
rt2x00_dev *rt2x00dev,
txdesc->u.ht.mcs |= 0x08;
}
+ if (tx_info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
+ int ssn = le16_to_cpu(hdr->seq_ctrl) >> 4;
+ printk("RATE PROBE %d %d\n", ssn, txdesc->u.ht.mcs);
+ }
+
+
if (test_bit(CONFIG_HT_DISABLED, >flags)) {
if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
txdesc->u.ht.txop = TXOP_SIFS;
and compared that with on air traffic captured in monitor mode on
different device in wireshark. On air traffic showed different
probe frames rate than requested.
Regards
Stanislaw
Re: feedback on mainlining wilc1000 staging driver
Kalle Valo writes: > Ajay Singh writes: > >> Hi Greg, >> >> We all are working on submitting and reviewing patches for wilc1000 in >> staging driver for quite some time. >> >> We would like to have feedback on the next steps to bring wilc1000 >> driver closer to move into the wireless subsystem tree. >> >> In summary, the following major things from TODO have been addressed in >> staging: >> -remove the defined feature as kernel versions >> -remove OS wrapper functions >> -remove custom debug and tracing functions >> -rework comments and function headers(also coding style) >> -remove build warnings >> -replace all semaphores with mutexes or completions >> -make spi and sdio components coexist in one build >> -turn compile-time platform configuration (BEAGLE_BOARD, PANDA_BOARD, >> PLAT_WMS8304, PLAT_RK, CUSTOMER_PLATFORM, ...) into run-time >> options that are read from DT >> -replace SIOCDEVPRIVATE commands with generic API functions >> -use wext-core handling instead of private SIOCSIWPRIV implementation > > From wireless point of view: if I see wext mentioned anywhere in the > driver I stop right there. cfg80211 is a hard requirement for us > nowadays. Clarification: Depending on the hardware design either cfg80211 or mac80211 is a hard requirement. I haven't checked wilc1000 at all so I don't know what design it has but if it's a "softmac" design then it has to use mac80211, we do not want to support multiple 802.11 UMAC stacks. -- Kalle Valo
Re: feedback on mainlining wilc1000 staging driver
Ajay Singh writes: > Hi Greg, > > We all are working on submitting and reviewing patches for wilc1000 in > staging driver for quite some time. > > We would like to have feedback on the next steps to bring wilc1000 > driver closer to move into the wireless subsystem tree. > > In summary, the following major things from TODO have been addressed in > staging: > -remove the defined feature as kernel versions > -remove OS wrapper functions > -remove custom debug and tracing functions > -rework comments and function headers(also coding style) > -remove build warnings > -replace all semaphores with mutexes or completions > -make spi and sdio components coexist in one build > -turn compile-time platform configuration (BEAGLE_BOARD, PANDA_BOARD, > PLAT_WMS8304, PLAT_RK, CUSTOMER_PLATFORM, ...) into run-time > options that are read from DT > -replace SIOCDEVPRIVATE commands with generic API functions > -use wext-core handling instead of private SIOCSIWPRIV implementation >From wireless point of view: if I see wext mentioned anywhere in the driver I stop right there. cfg80211 is a hard requirement for us nowadays. -- Kalle Valo
Re: [DEBUG PATCH] brcmfmac: add firmware watchdog running on host machine
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> It may happen for FullMAC firmware to crash. It should be detected and
> ideally somehow handled by a driver.
>
> Since commit ff4445a8502c ("brcmfmac: expose device memory to
> devcoredump subsystem") brcmfmac has BRCMF_E_PSM_WATCHDOG event handler
> but it wasn't enough to detect all kind of crashes. E.g. Netgear R8000
> (BCM4709A0 + 3 x BCM43602) user was exepriencing firmware crashes that
> never resulted in passing BRCMF_E_PSM_WATCHDOG to the host driver.
>
> That made me implement this trivial software watchdog that simply checks
> periodically if firmware still replies to the commands.
>
> Luckily this patch DOES NOT seem to be needed anymore since the commit
> 8a3ab2f38f16 ("brcmfmac: trigger memory dump upon firmware halt
> signal"). That change allows brcmfmac to detect firmware crashes
> successfully.
>
> This patch is being posted for research/debugging purposes only. It
> SHOULD NOT be applied until someone notices a firmware crash that
> doesn't trigger the BRCMF_D2H_DEV_FWHALT signal.
Kudos for making it clear that I can safely drop this in patchwork :)
This makes it so much easier for me.
--
Kalle Valo
Re: wireless dongle causing entire machine to hang
On Wed, Aug 15, 2018 at 10:25:48PM -0600, Randy Oostdyk wrote:
> Sorry about the mangled log file! Here's the txt file as an
> attachment, hope it's useful.
We loop infinitely in rt2x00_rxdone because we can not submit
urb. We always get EPROTO error. I think usb host driver should
give ENODEV at some point, but this is out of tree dwc_otg driver,
so I don't expect we can get fix for it.
I prepared a patch that count EPROTO errors and if it's bigger
than 10 mark device as gone. It should not make a problem
when we will get one time random error. I'm attaching it,
please test.
Thanks
Stanislaw
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index a279a43..2689bca 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1014,6 +1014,7 @@ struct rt2x00_dev {
unsigned int extra_tx_headroom;
struct usb_anchor *anchor;
+ unsigned int num_proto_errs;
/* Clock for System On Chip devices. */
struct clk *clk;
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 086aad2..3607b28 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -31,6 +31,22 @@
#include "rt2x00.h"
#include "rt2x00usb.h"
+static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
+{
+ if (status == -ENODEV || status == -ENOENT)
+ return true;
+
+ if (status == -EPROTO)
+ rt2x00_dev->num_proto_errs++;
+ else
+ rt2x00_dev->num_proto_errs = 0;
+
+ if (rt2x00_dev->num_proto_errs > 10)
+ return true;
+
+ return false
+}
+
/*
* Interfacing with the HW.
*/
@@ -57,7 +73,7 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
if (status >= 0)
return 0;
- if (status == -ENODEV || status == -ENOENT) {
+ if (rt2x00usb_check_usb_error(rt2x00dev, status)) {
/* Device has disappeared. */
clear_bit(DEVICE_STATE_PRESENT, >flags);
break;
@@ -321,7 +337,7 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry
*entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV || status == -ENOENT)
+ if (rt2x00usb_check_usb_error(rt2x00dev, status))
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
@@ -410,7 +426,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry
*entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV || status == -ENOENT)
+ if (rt2x00usb_check_usb_error(rt2x00dev, status))
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
Re: feedback on mainlining wilc1000 staging driver
Hi Greg, On Thu, 16 Aug 2018 08:43:54 +0200 Greg KH wrote: > On Thu, Aug 16, 2018 at 01:52:43AM +0530, Ajay Singh wrote: > > Hi Greg, > > > > We all are working on submitting and reviewing patches for wilc1000 > > in staging driver for quite some time. > > > > We would like to have feedback on the next steps to bring wilc1000 > > driver closer to move into the wireless subsystem tree. > > > > It is the middle of the merge window, combined with all of the 1ltf > crap, and other stable stuff. Can you wait until after the merge > window for this please? There's nothing we can do now anyway. > Submit the rest of your pending patches, get those merged and then we > can review the code to see what you have left to do. > Thanks for your time. I can wait till the end of merge window to discuss this. My intention is not to send changes during the current merge window but to understand what is pending for our driver. Let's revisit this later as you have suggested. Regards, Ajay
Re: feedback on mainlining wilc1000 staging driver
On Thu, Aug 16, 2018 at 01:52:43AM +0530, Ajay Singh wrote: > Hi Greg, > > We all are working on submitting and reviewing patches for wilc1000 in > staging driver for quite some time. > > We would like to have feedback on the next steps to bring wilc1000 > driver closer to move into the wireless subsystem tree. It is the middle of the merge window, combined with all of the 1ltf crap, and other stable stuff. Can you wait until after the merge window for this please? There's nothing we can do now anyway. Submit the rest of your pending patches, get those merged and then we can review the code to see what you have left to do. thanks, greg k-h
feedback on mainlining wilc1000 staging driver
Hi Greg, We all are working on submitting and reviewing patches for wilc1000 in staging driver for quite some time. We would like to have feedback on the next steps to bring wilc1000 driver closer to move into the wireless subsystem tree. In summary, the following major things from TODO have been addressed in staging: -remove the defined feature as kernel versions -remove OS wrapper functions -remove custom debug and tracing functions -rework comments and function headers(also coding style) -remove build warnings -replace all semaphores with mutexes or completions -make spi and sdio components coexist in one build -turn compile-time platform configuration (BEAGLE_BOARD, PANDA_BOARD, PLAT_WMS8304, PLAT_RK, CUSTOMER_PLATFORM, ...) into run-time options that are read from DT -replace SIOCDEVPRIVATE commands with generic API functions -use wext-core handling instead of private SIOCSIWPRIV implementation -Move handling for each individual members of 'union message_body' out into a separate 'struct work_struct' and completely remove the multiplexer that is currently part of host_if_work(), allowing movement of the implementation of each message handler into the callsite of the function that currently queues the 'host_if_msg'. -convert all uses of the old GPIO API from to the GPIO descriptor API in and look up GPIO lines from device tree, ACPI or board files, board files should use I have few patches to submit based on last week comments. I will send these patches as soon as the merge window is closed. 1. Delete wilc_debugfs.c file, as not used. 2. Remove use of remaining global variables. 3. Remove udelay realted checkpatch warning. 4. Use void return for function whose return value is not used. Currently, there are 2 known items pending in our TODO. -support soft-ap and p2p mode -support resume/suspend function For the above 2 remaining TODO items, we need to add extra code but as suggested in [1], we have not taken up this activity yet. We would like to know your opinion whether we should start working on these features in staging-next tree or take it up after having moved the code to wireless sub-system. Do you think it’s better to initiate review in parallel with wireless subsystem maintainer to identify any pending TODO items. Please guide us on how to proceed further. [1] . https://patchwork.kernel.org/patch/9809145 Regards, Ajay
