* Re: mwifiex: check for mfg_mode in add_virtual_intf
From: Kalle Valo @ 2017-09-20 12:46 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1504816363-31015-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> If driver is loaded with 'mfg_mode' enabled, then the sending
> commands are not allowed. So, skip sending commands, to firmware
> in mwifiex_add_virtual_intf if 'mfg_mode' is enabled.
>
> Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added interface")
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
26177d7f3969 mwifiex: check for mfg_mode in add_virtual_intf
--
https://patchwork.kernel.org/patch/9942827/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: notify cfg80211 about scan abort
From: Kalle Valo @ 2017-09-20 12:46 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1504121915-2063-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> Driver sends a series of scan commands to firmware to serve a
> user scan request. If an intermediate scan command fails, driver
> aborts the scan but it is not being informed to cfg80211. This
> will cause issues in applications performing periodic scans.
> Fix this by informing scan abort.
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
31726ff20190 mwifiex: notify cfg80211 about scan abort
--
https://patchwork.kernel.org/patch/9930689/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: rtl8192ee: Fix memory leak when loading firmware
From: Kalle Valo @ 2017-09-20 12:44 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Stable
In-Reply-To: <20170914181744.8216-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In routine rtl92ee_set_fw_rsvdpagepkt(), the driver allocates an skb, but
> never calls rtl_cmd_send_packet(), which will free the buffer. All other
> rtlwifi drivers perform this operation correctly.
>
> This problem has been in the driver since it was included in the kernel.
> Fortunately, each firmware load only leaks 4 buffers, which likely
> explains why it has not previously been detected.
>
> Cc: Stable <stable@vger.kernel.org> # 3.18+
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
519ce2f933fa rtlwifi: rtl8192ee: Fix memory leak when loading firmware
--
https://patchwork.kernel.org/patch/9953677/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: btcoexist: 23b 1ant: fix duplicated code for different branches
From: Kalle Valo @ 2017-09-20 12:44 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting
In-Reply-To: <20170831144859.2291-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> A typo led to this issue, which was detected with the help of Coccinelle.
>
> In addition to fixing the error, the code is refactored to eliminate an
> if statement.
>
> Addresses-Coverity-ID: 1226788
>
> Reported-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
0f61953dd0f5 rtlwifi: btcoexist: 23b 1ant: fix duplicated code for different branches
--
https://patchwork.kernel.org/patch/9932349/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] b43: fix unitialized reads of ret by initializing the array to zero
From: Kalle Valo @ 2017-09-20 12:41 UTC (permalink / raw)
To: Colin Ian King
Cc: linux-wireless, b43-dev, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170905181550.23839-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The u8 char array ret is not being initialized and elements outside
> the range start to end contain just garbage values from the stack.
> This results in a later scan of the array to read potentially
> uninitialized values. Fix this by initializing the array to zero.
> This seems to have been an issue since the very first commit.
>
> Detected by CoverityScan CID#139652 ("Uninitialized scalar variable")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Michael Buesch <m@bues.ch>
2 patches applied to wireless-drivers-next.git, thanks.
e31fbe1034d9 b43: fix unitialized reads of ret by initializing the array to zero
e3ae1c772046 b43legacy: fix unitialized reads of ret by initializing the array to zero
--
https://patchwork.kernel.org/patch/9939435/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rsi: fix a dereference on adapter before it has been null checked
From: Kalle Valo @ 2017-09-20 12:40 UTC (permalink / raw)
To: Colin Ian King
Cc: Amitkumar Karwar, Prameela Rani Garnepudi, Karun Eagalapati,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170908152452.3594-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The assignment of dev is dereferencing adapter before adapter has
> been null checked, potentially leading to a null pointer dereference.
> Fix this by simply moving the assignment of dev to a later point
> after the sanity null check of adapter.
>
> Detected by CoverityScan CID#1398383 ("Dereference before null check")
>
> Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
6508497cbdc7 rsi: fix a dereference on adapter before it has been null checked
--
https://patchwork.kernel.org/patch/9944509/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/8] rsi: add p2p support parameters to mac80211
From: Kalle Valo @ 2017-09-20 12:40 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi
In-Reply-To: <1504085908-2163-2-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> wrote:
> From: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>
> This patch adds p2p supported parameters to mac80211 hw and
> wiphy structures during mac80211 registration.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
8 patches applied to wireless-drivers-next.git, thanks.
421eedff1180 rsi: add p2p support parameters to mac80211
b8bd3a439f35 rsi: add/remove interface enhancements for p2p
df771911914a rsi: add support for p2p listen
4671c209ac46 rsi: handle peer connection and disconnection in p2p mode
eac4eed3224b rsi: tx and rx path enhancements for p2p mode
efe877aa0f40 rsi: disallow power save config when AP vap running
c7245c0975f1 rsi: aggregation changes for p2p mode
af75687286bf rsi: miscellaneous changes for p2p mode
--
https://patchwork.kernel.org/patch/9929129/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2,1/2] qtnfmac: lock access to h/w in tx path
From: Kalle Valo @ 2017-09-20 12:35 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Sergey Matyukevich
In-Reply-To: <20170918122950.32612-2-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> Fix tx path regression. Lock should be held when queuing packets
> to h/w fifos in order to properly handle configurations with
> multiple enabled interfaces.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
2 patches applied to wireless-drivers.git, thanks.
20da2ec06bfa qtnfmac: lock access to h/w in tx path
a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes
--
https://patchwork.kernel.org/patch/9956607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2, 1/9] qtnfmac: qlink: convert channel width from bitfiled to simple enum
From: Kalle Valo @ 2017-09-20 12:33 UTC (permalink / raw)
To: Igor Mitsyanko; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170920122314.5397A60710@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
>
>> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>>
>> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
>
> No empty commit logs, please. After the first patch I was about to write
> one myself but after seeing multiple of them I'm not going to do that.
>
> 9 patches set to Changes Requested.
BTW, I got a mail undelivered message. Not sure why smtp.codeaurora.org
could not find the host but reporting it here just in case:
<avinashp@quantenna.com>: unable to look up host
quantenna-com.mail.protection.outlook.com: Name or service not known
<igor.mitsyanko.os@quantenna.com>: unable to look up host
quantenna-com.mail.protection.outlook.com: Name or service not known
<sergey.matyukevich.os@quantenna.com>: unable to look up host
quantenna-com.mail.protection.outlook.com: Name or service not known
--
Kalle Valo
^ permalink raw reply
* Re: [V2, 1/9] qtnfmac: qlink: convert channel width from bitfiled to simple enum
From: Kalle Valo @ 2017-09-20 12:23 UTC (permalink / raw)
To: Igor Mitsyanko; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170902014451.17766-2-igor.mitsyanko.os@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
No empty commit logs, please. After the first patch I was about to write
one myself but after seeing multiple of them I'm not going to do that.
9 patches set to Changes Requested.
9935431 [V2,1/9] qtnfmac: qlink: convert channel width from bitfiled to simple enum
9935437 [V2,2/9] qtnfmac: make "Channel change" event report full channel info
9935443 [V2,3/9] qtnfmac: retrieve current channel info from EP
9935445 [V2,4/9] qtnfmac: do not cache channel info from "connect" command
9935429 [V2,5/9] qtnfmac: let wifi card handle channel switch request to the same chan
9935441 [V2,6/9] qtnfmac: pass VIF info to SendChannel command
9935433 [V2,7/9] qtnfmac: do not cache CSA chandef info
9935439 [V2,8/9] qtnfmac: remove unused mac::status field
9935435 [V2,9/9] qtnfmac: do not report channel changes until wiphy is registered
--
https://patchwork.kernel.org/patch/9935431/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: Add rcu read side critical sections
From: Johannes Berg @ 2017-09-20 12:17 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: linux-wireless, David S. Miller, netdev
In-Reply-To: <20170920121137.GZ4914@intel.com>
On Wed, 2017-09-20 at 15:11 +0300, Ville Syrjälä wrote:
>
> > I guess since the outer pointer isn't protected, only the inner ...
>
> I think just the fact that even the pointers in ieee80211_tx_data
> don't have the __rcu annotation makes it rather hard to see what is
> really rcu protected and what isn't. If every user of those pointers
> would have to do the rcu_dereference() things would be rather more
> explicit.
It wouldn't make sense though, because those users don't need to
provide the protection, and they don't need to make sure to use the
pointer in an RCU safe manner (access once etc.) since they're in code
that can't really go wrong... mostly.
> > Therefore, this patch is wrong.
>
> OK, so the problem is in ath9k then.
I agree.
> > I actually think the same is true for ieee80211_tx_dequeue(), but
[...]
> Well, I think this is as far as I want to dig into the matter. I can
> respin the patch once more with just tx_dequeue() fix in there, if
> you want (not sure you do if you think it's wrong as well). After
> that I'll leave it to someone who actually knows what they're doing
> with mac80211 ;)
:-)
I think we should rather document that RCU is required for that
function, I think for some usages it may be OK without but with keys
I'm pretty sure you'll need it.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mwifiex: resubmit failed to submit RX URBs in main thread
From: Kalle Valo @ 2017-09-20 12:13 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare
In-Reply-To: <1504122674-3379-2-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> writes:
> From: James Cao <jcao@marvell.com>
>
> Current driver has 6 Rx data URBs. Once any packet received
> kernel calls our callback, in which the same URB will be
> resubmitted after Rx indication. In URB submission function a new
> skb will be allocated since the previous one is passed to upper
> layer (freed later). Since the skb is from a special pool (not
> regular memory), skb allocation may fail when kernel holds a lot
> of Rx packets on some low resource platforms.
The special pool being GFP_ATOMIC allocations or what?
> The URB will not be resubmitted in this no free skb case. If driver
> fails to resubmit all 6 URBs, Rx will stop. To cover this scenario
> check and resubmit Rx URBs in main thread.
>
> Signed-off-by: James Cao <jcao@marvell.com>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
[...]
> @@ -278,6 +279,16 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
> break;
> }
>
> + /* Try to resubmit RX URB if sunmission failed earlier */
> + if (!atomic_read(&adapter->rx_pending) &&
> + adapter->iface_type == MWIFIEX_USB) {
> + usb_card = adapter->card;
> + if (atomic_read(&usb_card->rx_data_urb_pending) <
> + MWIFIEX_RX_DATA_URB &&
> + adapter->if_ops.submit_rem_rx_urbs)
> + adapter->if_ops.submit_rem_rx_urbs(adapter);
> + }
To me this just feels wrong. Normally the proceduce is to drop the frame
if allocations fail, not try to reallocate. I need more convincing that
this really is the right approach.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: Add rcu read side critical sections
From: Ville Syrjälä @ 2017-09-20 12:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, netdev
In-Reply-To: <1505903964.3026.14.camel@sipsolutions.net>
On Wed, Sep 20, 2017 at 12:39:24PM +0200, Johannes Berg wrote:
> On Wed, 2017-09-20 at 13:11 +0300, Ville Syrjala wrote:
>
> > --- a/net/mac80211/tx.c
> > +++ b/net/mac80211/tx.c
> > @@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
> > struct ieee80211_tx_data tx;
> > struct sk_buff *skb2;
> >
> > - if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP)
> > + rcu_read_lock();
>
> The documentation says:
>
> /**
> * ieee80211_tx_prepare_skb - prepare an 802.11 skb for transmission
> * @hw: pointer as obtained from ieee80211_alloc_hw()
> * @vif: virtual interface
> * @skb: frame to be sent from within the driver
> * @band: the band to transmit on
> * @sta: optional pointer to get the station to send the frame to
> *
> * Note: must be called under RCU lock
> */
>
> You can't even argue that it should be the function itself doing it,
> because the (admittedly optional) sta pointer would otherwise not have
> proper protection after you leave the function ... You can't pass out a
> sta pointer that's RCU protected.
Yeah, I suppose that would need rcu_handoff+some other mechanism to
make sure it stays around after that.
>
> Side note: Perhaps some annotation should be there? not sure it's
> possible - would have to be something like
> struct ieee80211_sta * __rcu *sta;
>
> I guess since the outer pointer isn't protected, only the inner ...
I think just the fact that even the pointers in ieee80211_tx_data don't
have the __rcu annotation makes it rather hard to see what is really rcu
protected and what isn't. If every user of those pointers would have to
do the rcu_dereference() things would be rather more explicit.
> Therefore, this patch is wrong.
OK, so the problem is in ath9k then.
> I actually think the same is true for ieee80211_tx_dequeue(), but I'm
> less sure about it - the sta pointer there clearly is somehow safely
> passed in (even if it's w/o RCU, the driver can potentially make that
> safe), but the key pointer seems unsafe in this case (as well) if
> there's no outer RCU protection.
Well, I think this is as far as I want to dig into the matter. I can
respin the patch once more with just tx_dequeue() fix in there, if you
want (not sure you do if you think it's wrong as well). After that I'll
leave it to someone who actually knows what they're doing with mac80211 ;)
--
Ville Syrjälä
Intel OTC
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
From: Kalle Valo @ 2017-09-20 12:09 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, Joe Perches, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, linux-wireless@vger.kernel.org
In-Reply-To: <20170920060244.GA13616@google.com>
Brian Norris <briannorris@chromium.org> writes:
> On Wed, Sep 20, 2017 at 07:30:29AM +0300, Kalle Valo wrote:
>> Brian Norris <briannorris@chromium.org> writes:
>>
>> > Hi Ganapathi,
>> >
>> > On Thu, Sep 14, 2017 at 02:14:24PM +0000, Ganapathi Bhat wrote:
>> >> > On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote:
>
>> >> > Why not use a ratelimit?
>> >> Since this is for receive, the packets are from AP side and we cannot
>> >> lower the rate from AP. On some low performance systems this change
>> >> will be helpful.
>> >
>> > I think Joe was referring to things like printk_ratelimited() or
>> > dev_err_ratelimited(). Those automatically ratelimit prints for you,
>> > using a static counter. You'd just need to make a small warpper for
>> > mwifiex_dbg() using __ratelimit().
>> >
>> > Those sort of rate limits are significantly different than yours though.
>> > You were looking to avoid printing errors when there are only a few
>> > failures in a row, whereas the existing rate-limiting infrastructure
>> > looks to avoid printing errors if too many happen in a row. Those are
>> > different goals.
>>
>> Are you saying that this patch is good to take? Or should Ganapathi
>> submit v2?
>
> If you're asking me...
Yeah, I was asking you because to me this patch looks like an ugly
workaround to a bug. And now that looked patch 1 more closely it feels
the same.
> All I was saying was that I don't think Joe's suggestion will help
> Ganapathi. I'd expect Ganapathi could confirm/deny that part. (Or Joe
> could correct me if my interpretation is wrong.)
Ok.
> I'm also not familiar with how we expect dev_alloc_skb() failures to be
> handled. If that's a common expected failure mode in low-memory
> situations (seems reasonable?) and the driver handles these failure just
> fine (completely unreviewed by me, so far; I suspect it doesn't do this
> completely correctly), then sure, being less noisy about it as done in
> this patch should be fine.
But this is a debug message so it should not bother normal users, right?
I think that having a threshold like this is just hiding problems and
not solving them. The real issue here is that dev_alloc_skb() is failing
and that's what should be solved, not to paper it over by limiting debug
messages. It just means that the real issue will be even more difficult
to detect in the future.
> IOW, I don't have concrete feedback for Ganapathi to address, but I'm
> not exactly "ack"ing it myself.
I'm not very confident about this patch either, it's not just making any
sense.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: use get_random_mask_addr() helper
From: Kalle Valo @ 2017-09-20 11:47 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, linux-wireless@vger.kernel.org, Cathy Luo,
Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare
In-Reply-To: <20170919164316.GA4617@google.com>
Brian Norris <briannorris@chromium.org> writes:
> Hi,
>
> On Tue, Sep 19, 2017 at 05:30:06PM +0300, Kalle Valo wrote:
>> Ganapathi Bhat <gbhat@marvell.com> writes:
>>
>> > Hi Kalle,
>> >>
>> >> > Avoid calculating random MAC address in driver. Instead make use of
>> >> > 'get_random_mask_addr()' function.
>> >> >
>> >> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
>> >>
>> >> I don't see 1/2 anywhere. Did it get lost?
>> >
>> > Actually there is no 1/2. What I did is: 'git send-email'; CTRL + C
>
> It's dependent on this patch though, which kinda should be '1/2':
>
> [PATCH] mwifiex: avoid storing random_mac in private
Thanks for pointing out, I'll make sure that I commit these in correct
order.
>> > (to correct a typo); and then tried sending it again. I think that
>> > created some problem here. Kindly let me know how to proceed.
>>
>> Ok. I'll wait for review comments and if all goes well I'll apply it in
>> few days.
>
> FWIW, this looks OK to me:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
>
> It's just a bit strange that we have to keep our own on-stack temporary
> buffer for this. Maybe this could use an in-place helper too? Or (if
> it's really legal for us to modify the cfg80211_scan_request in-place)
> why doesn't the upper-layer nl80211 code do the randomization for us?
> Many (all?) drivers I see implementing randomization have to do this
> anyway; they don't use request->mac_addr directly. (Or I suppose some
> firmware could implement the randomization on its own someday...but
> would we really trust it?)
Good questions and I was wondering the same when looking at this patch.
But I wasn't involved in the interface design so I don't really know the
background here.
I'm planning to apply this patch anyway, any improvements can be done as
a followup patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mwifiex: add device specific ioctl handler
From: Kalle Valo @ 2017-09-20 11:43 UTC (permalink / raw)
To: Xinming Hu
Cc: Arend van Spriel, Xinming Hu, Linux Wireless, Brian Norris,
Dmitry Torokhov, rajatja@google.com, Zhiyuan Yang, Tim Song,
Cathy Luo, Ganapathi Bhat
In-Reply-To: <429692343ed64d759eef2aa014a87fbb@SC-EXCH02.marvell.com>
Xinming Hu <huxm@marvell.com> writes:
>> You could look at
>> nl80211 vendor commands, but that is also under scrutiny if common wifi
>> functionality is provided by it. I am pretty sure Kalle has his ideas about this :-)
>>
>
> Yes, the new utility should use nl80211 interface.
> But we have lots of legacy utility based on ioctl, it will be helpful
> to reduce massive work on refactoring.
That's not an excuse to implement bad interfaces. It's not really that
hard to convert ioctl based tools to use nl80211 testmode command, I
even have myself done that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mwifiex: add device specific ioctl handler
From: Kalle Valo @ 2017-09-20 11:38 UTC (permalink / raw)
To: Arend van Spriel
Cc: Xinming Hu, Linux Wireless, Brian Norris, Dmitry Torokhov,
rajatja, Zhiyuan Yang, Tim Song, Cathy Luo, Ganapathi Bhat,
Xinming Hu
In-Reply-To: <59C22949.9030304@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 9/20/2017 8:44 AM, Xinming Hu wrote:
>> From: Xinming Hu <huxm@marvell.com>
>>
>> Add net_dev ndo_do_ioctl handler, which could be used for
>> downloading host command by utility in manufactory test
>
> Not sure if we want ioctls in upstream wireless drivers.
Yeah, patches adding ioctls to wireless drivers are automatically
rejected.
> You could look at nl80211 vendor commands, but that is also under
> scrutiny if common wifi functionality is provided by it. I am pretty
> sure Kalle has his ideas about this :-)
For manufacturing tests we have nl80211 testmode command and event.
There are upstream drivers already using it so you even have examples.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: Add rcu read side critical sections
From: Johannes Berg @ 2017-09-20 10:39 UTC (permalink / raw)
To: Ville Syrjala, linux-wireless; +Cc: David S. Miller, netdev
In-Reply-To: <20170920101123.23312-1-ville.syrjala@linux.intel.com>
On Wed, 2017-09-20 at 13:11 +0300, Ville Syrjala wrote:
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
> struct ieee80211_tx_data tx;
> struct sk_buff *skb2;
>
> - if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP)
> + rcu_read_lock();
The documentation says:
/**
* ieee80211_tx_prepare_skb - prepare an 802.11 skb for transmission
* @hw: pointer as obtained from ieee80211_alloc_hw()
* @vif: virtual interface
* @skb: frame to be sent from within the driver
* @band: the band to transmit on
* @sta: optional pointer to get the station to send the frame to
*
* Note: must be called under RCU lock
*/
You can't even argue that it should be the function itself doing it,
because the (admittedly optional) sta pointer would otherwise not have
proper protection after you leave the function ... You can't pass out a
sta pointer that's RCU protected.
Side note: Perhaps some annotation should be there? not sure it's
possible - would have to be something like
struct ieee80211_sta * __rcu *sta;
I guess since the outer pointer isn't protected, only the inner ...
Therefore, this patch is wrong.
I actually think the same is true for ieee80211_tx_dequeue(), but I'm
less sure about it - the sta pointer there clearly is somehow safely
passed in (even if it's w/o RCU, the driver can potentially make that
safe), but the key pointer seems unsafe in this case (as well) if
there's no outer RCU protection.
johannes
^ permalink raw reply
* [PATCH v2 1/2] mac80211: Add rcu read side critical sections
From: Ville Syrjala @ 2017-09-20 10:11 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, David S. Miller, netdev, Ville Syrjälä
In-Reply-To: <20170918195919.15860-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
I got the following lockdep warning about the rcu_dereference()s in
ieee80211_tx_h_select_key(). After tracing all callers of
ieee80211_tx_h_select_key() I discovered that ieee80211_get_buffered_bc()
and ieee80211_build_data_template() had the rcu_read_lock/unlock() but
three other places did not. So I just blindly added them and made the
read side critical section extend as far as the lifetime of 'tx' which
is where we seem to be stuffing the rcu protected pointers. No real clue
whether this is correct or not.
[ 854.573700] ../net/mac80211/tx.c:594 suspicious rcu_dereference_check() usage!
[ 854.573704]
other info that might help us debug this:
[ 854.573707]
rcu_scheduler_active = 2, debug_locks = 1
[ 854.573712] 6 locks held by kworker/u2:0/2877:
[ 854.573715] #0: ("%s"wiphy_name(local->hw.wiphy)){++++.+}, at: [<c1067f37>] process_one_work+0x127/0x580
[ 854.573742] #1: ((&sdata->work)){+.+.+.}, at: [<c1067f37>] process_one_work+0x127/0x580
[ 854.573758] #2: (&wdev->mtx){+.+.+.}, at: [<f83271c3>] ieee80211_sta_work+0x23/0x1c70 [mac80211]
[ 854.573902] #3: (&local->sta_mtx){+.+.+.}, at: [<f82c9b10>] __sta_info_flush+0x60/0x160 [mac80211]
[ 854.573947] #4: (&(&txq->axq_lock)->rlock){+.-...}, at: [<f825729c>] ath_tx_node_cleanup+0x5c/0x180 [ath9k]
[ 854.573973] #5: (&(&fq->lock)->rlock){+.-...}, at: [<f82fb064>] ieee80211_tx_dequeue+0x24/0xa80 [mac80211]
[ 854.574023]
stack backtrace:
[ 854.574028] CPU: 0 PID: 2877 Comm: kworker/u2:0 Not tainted 4.13.0-mgm-ovl+ #52
[ 854.574032] Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004
[ 854.574070] Workqueue: phy0 ieee80211_iface_work [mac80211]
[ 854.574076] Call Trace:
[ 854.574086] dump_stack+0x16/0x19
[ 854.574092] lockdep_rcu_suspicious+0xcb/0xf0
[ 854.574131] ieee80211_tx_h_select_key+0x1b5/0x500 [mac80211]
[ 854.574171] ieee80211_tx_dequeue+0x283/0xa80 [mac80211]
[ 854.574181] ath_tid_dequeue+0x84/0xf0 [ath9k]
[ 854.574189] ath_tx_node_cleanup+0xb8/0x180 [ath9k]
[ 854.574199] ath9k_sta_state+0x48/0xf0 [ath9k]
[ 854.574207] ? ath9k_del_ps_key.isra.19+0x60/0x60 [ath9k]
[ 854.574240] drv_sta_state+0xaf/0x8c0 [mac80211]
[ 854.574275] __sta_info_destroy_part2+0x10b/0x140 [mac80211]
[ 854.574309] __sta_info_flush+0xd5/0x160 [mac80211]
[ 854.574349] ieee80211_set_disassoc+0xd3/0x570 [mac80211]
[ 854.574390] ieee80211_sta_connection_lost+0x30/0x60 [mac80211]
[ 854.574431] ieee80211_sta_work+0x1ff/0x1c70 [mac80211]
[ 854.574436] ? mark_held_locks+0x62/0x90
[ 854.574443] ? _raw_spin_unlock_irqrestore+0x55/0x70
[ 854.574447] ? trace_hardirqs_on_caller+0x11c/0x1a0
[ 854.574452] ? trace_hardirqs_on+0xb/0x10
[ 854.574459] ? dev_mc_net_exit+0xe/0x20
[ 854.574467] ? skb_dequeue+0x48/0x70
[ 854.574504] ieee80211_iface_work+0x2d8/0x320 [mac80211]
[ 854.574509] process_one_work+0x1d1/0x580
[ 854.574513] ? process_one_work+0x127/0x580
[ 854.574519] worker_thread+0x31/0x380
[ 854.574525] kthread+0xd9/0x110
[ 854.574529] ? process_one_work+0x580/0x580
[ 854.574534] ? kthread_create_on_node+0x30/0x30
[ 854.574540] ret_from_fork+0x19/0x24
[ 854.574548] =============================
[ 854.574551] WARNING: suspicious RCU usage
[ 854.574555] 4.13.0-mgm-ovl+ #52 Not tainted
[ 854.574558] -----------------------------
[ 854.574561] ../net/mac80211/tx.c:608 suspicious rcu_dereference_check() usage!
[ 854.574564]
other info that might help us debug this:
[ 854.574568]
rcu_scheduler_active = 2, debug_locks = 1
[ 854.574572] 6 locks held by kworker/u2:0/2877:
[ 854.574574] #0: ("%s"wiphy_name(local->hw.wiphy)){++++.+}, at: [<c1067f37>] process_one_work+0x127/0x580
[ 854.574590] #1: ((&sdata->work)){+.+.+.}, at: [<c1067f37>] process_one_work+0x127/0x580
[ 854.574606] #2: (&wdev->mtx){+.+.+.}, at: [<f83271c3>] ieee80211_sta_work+0x23/0x1c70 [mac80211]
[ 854.574657] #3: (&local->sta_mtx){+.+.+.}, at: [<f82c9b10>] __sta_info_flush+0x60/0x160 [mac80211]
[ 854.574702] #4: (&(&txq->axq_lock)->rlock){+.-...}, at: [<f825729c>] ath_tx_node_cleanup+0x5c/0x180 [ath9k]
[ 854.574721] #5: (&(&fq->lock)->rlock){+.-...}, at: [<f82fb064>] ieee80211_tx_dequeue+0x24/0xa80 [mac80211]
[ 854.574771]
stack backtrace:
[ 854.574775] CPU: 0 PID: 2877 Comm: kworker/u2:0 Not tainted 4.13.0-mgm-ovl+ #52
[ 854.574779] Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004
[ 854.574814] Workqueue: phy0 ieee80211_iface_work [mac80211]
[ 854.574821] Call Trace:
[ 854.574825] dump_stack+0x16/0x19
[ 854.574830] lockdep_rcu_suspicious+0xcb/0xf0
[ 854.574869] ieee80211_tx_h_select_key+0x44e/0x500 [mac80211]
[ 854.574908] ieee80211_tx_dequeue+0x283/0xa80 [mac80211]
[ 854.574919] ath_tid_dequeue+0x84/0xf0 [ath9k]
[ 854.574927] ath_tx_node_cleanup+0xb8/0x180 [ath9k]
[ 854.574936] ath9k_sta_state+0x48/0xf0 [ath9k]
[ 854.574945] ? ath9k_del_ps_key.isra.19+0x60/0x60 [ath9k]
[ 854.574978] drv_sta_state+0xaf/0x8c0 [mac80211]
[ 854.575012] __sta_info_destroy_part2+0x10b/0x140 [mac80211]
[ 854.575046] __sta_info_flush+0xd5/0x160 [mac80211]
[ 854.575087] ieee80211_set_disassoc+0xd3/0x570 [mac80211]
[ 854.575127] ieee80211_sta_connection_lost+0x30/0x60 [mac80211]
[ 854.575168] ieee80211_sta_work+0x1ff/0x1c70 [mac80211]
[ 854.575173] ? mark_held_locks+0x62/0x90
[ 854.575178] ? _raw_spin_unlock_irqrestore+0x55/0x70
[ 854.575182] ? trace_hardirqs_on_caller+0x11c/0x1a0
[ 854.575187] ? trace_hardirqs_on+0xb/0x10
[ 854.575192] ? dev_mc_net_exit+0xe/0x20
[ 854.575197] ? skb_dequeue+0x48/0x70
[ 854.575233] ieee80211_iface_work+0x2d8/0x320 [mac80211]
[ 854.575238] process_one_work+0x1d1/0x580
[ 854.575243] ? process_one_work+0x127/0x580
[ 854.575248] worker_thread+0x31/0x380
[ 854.575253] kthread+0xd9/0x110
[ 854.575257] ? process_one_work+0x580/0x580
[ 854.575262] ? kthread_create_on_node+0x30/0x30
[ 854.575267] ret_from_fork+0x19/0x24
v2: Callers of ieee80211_tx() already have the
rcu_read_lock/unlock()
Move the rcu critical section inside the spinlock in
ieee80211_tx_dequeue() (Johannes Berg)
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
net/mac80211/tx.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 94826680cf2b..fc4d8294d664 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1770,15 +1770,21 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
struct ieee80211_tx_data tx;
struct sk_buff *skb2;
- if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP)
+ rcu_read_lock();
+
+ if (ieee80211_tx_prepare(sdata, &tx, NULL, skb) == TX_DROP) {
+ rcu_read_unlock();
return false;
+ }
info->band = band;
info->control.vif = vif;
info->hw_queue = vif->hw_queue[skb_get_queue_mapping(skb)];
- if (invoke_tx_handlers(&tx))
+ if (invoke_tx_handlers(&tx)) {
+ rcu_read_unlock();
return false;
+ }
if (sta) {
if (tx.sta)
@@ -1792,9 +1798,12 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
if (WARN_ON(skb2 != skb || !skb_queue_empty(&tx.skbs))) {
ieee80211_free_txskb(hw, skb2);
ieee80211_purge_tx_queue(hw, &tx.skbs);
+ rcu_read_unlock();
return false;
}
+ rcu_read_unlock();
+
return true;
}
EXPORT_SYMBOL(ieee80211_tx_prepare_skb);
@@ -3413,6 +3422,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
spin_lock_bh(&fq->lock);
+ rcu_read_lock();
+
if (test_bit(IEEE80211_TXQ_STOP, &txqi->flags))
goto out;
@@ -3511,6 +3522,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
IEEE80211_SKB_CB(skb)->control.vif = vif;
out:
+ rcu_read_unlock();
+
spin_unlock_bh(&fq->lock);
return skb;
--
2.13.5
^ permalink raw reply related
* Re: Re: [PATCH] mwifiex: add device specific ioctl handler
From: Xinming Hu @ 2017-09-20 10:04 UTC (permalink / raw)
To: Arend van Spriel, Xinming Hu, Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja@google.com,
Zhiyuan Yang, Tim Song, Cathy Luo, Ganapathi Bhat
SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJlbmQgdmFuIFNw
cmllbCBbbWFpbHRvOmFyZW5kLnZhbnNwcmllbEBicm9hZGNvbS5jb21dDQo+IFNlbnQ6IDIwMTfE
6jnUwjIwyNUgMTY6NDANCj4gVG86IFhpbm1pbmcgSHUgPGh1eGlubWluZzgyMEBnbWFpbC5jb20+
OyBMaW51eCBXaXJlbGVzcw0KPiA8bGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnPg0KPiBD
YzogS2FsbGUgVmFsbyA8a3ZhbG9AY29kZWF1cm9yYS5vcmc+OyBCcmlhbiBOb3JyaXMNCj4gPGJy
aWFubm9ycmlzQGdvb2dsZS5jb20+OyBEbWl0cnkgVG9yb2tob3YgPGR0b3JAZ29vZ2xlLmNvbT47
DQo+IHJhamF0amFAZ29vZ2xlLmNvbTsgWmhpeXVhbiBZYW5nIDx5YW5nenlAbWFydmVsbC5jb20+
OyBUaW0gU29uZw0KPiA8c29uZ3Rhb0BtYXJ2ZWxsLmNvbT47IENhdGh5IEx1byA8Y2x1b0BtYXJ2
ZWxsLmNvbT47IEdhbmFwYXRoaSBCaGF0DQo+IDxnYmhhdEBtYXJ2ZWxsLmNvbT47IFhpbm1pbmcg
SHUgPGh1eG1AbWFydmVsbC5jb20+DQo+IFN1YmplY3Q6IFtFWFRdIFJlOiBbUEFUQ0hdIG13aWZp
ZXg6IGFkZCBkZXZpY2Ugc3BlY2lmaWMgaW9jdGwgaGFuZGxlcg0KPiANCj4gRXh0ZXJuYWwgRW1h
aWwNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gT24gOS8yMC8yMDE3IDg6NDQgQU0sIFhpbm1pbmcg
SHUgd3JvdGU6DQo+ID4gRnJvbTogWGlubWluZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPg0K
PiA+IEFkZCBuZXRfZGV2IG5kb19kb19pb2N0bCBoYW5kbGVyLCB3aGljaCBjb3VsZCBiZSB1c2Vk
IGZvciBkb3dubG9hZGluZw0KPiA+IGhvc3QgY29tbWFuZCBieSB1dGlsaXR5IGluIG1hbnVmYWN0
b3J5IHRlc3QNCj4gDQo+IE5vdCBzdXJlIGlmIHdlIHdhbnQgaW9jdGxzIGluIHVwc3RyZWFtIHdp
cmVsZXNzIGRyaXZlcnMuDQoNClllcywgd2V4dCBpb2N0bCBjb3VsZCBiZSBkaXNjYXJkIGFuZCBy
ZXBsYWNlZCBieSB3ZWxsIGRlZmluZWQgbmw4MDIxMS9jZmc4MDIxMS4NCkJ1dCBwZXIgbXkgdW5k
ZXJzdGFuZCwgdGhlIG5ldCBkZXZpY2UgaW9jdGwgd2lsbCBzdGlsbCB3b3JrcyBub3JtYWxseS4g
UmlnaHQgPw0KDQo+IFlvdSBjb3VsZCBsb29rIGF0DQo+IG5sODAyMTEgdmVuZG9yIGNvbW1hbmRz
LCBidXQgdGhhdCBpcyBhbHNvIHVuZGVyIHNjcnV0aW55IGlmIGNvbW1vbiB3aWZpDQo+IGZ1bmN0
aW9uYWxpdHkgaXMgcHJvdmlkZWQgYnkgaXQuIEkgYW0gcHJldHR5IHN1cmUgS2FsbGUgaGFzIGhp
cyBpZGVhcyBhYm91dCB0aGlzIDotKQ0KPiANCg0KWWVzLCB0aGUgbmV3IHV0aWxpdHkgc2hvdWxk
IHVzZSBubDgwMjExIGludGVyZmFjZS4NCkJ1dCB3ZSBoYXZlIGxvdHMgb2YgbGVnYWN5IHV0aWxp
dHkgYmFzZWQgb24gaW9jdGwsIGl0IHdpbGwgYmUgaGVscGZ1bCB0byByZWR1Y2UgbWFzc2l2ZSB3
b3JrIG9uIHJlZmFjdG9yaW5nLg0KDQo+IFJlZ2FyZHMsDQo+IEFyZW5kDQo=
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-20 9:36 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <20170919094204.GR26927@us.netrek.org>
On Tue, Sep 19, 2017 at 07:42:04PM +1000, James Cameron wrote:
> On Thu, Sep 14, 2017 at 07:27:39PM +1000, James Cameron wrote:
> > On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> > > On 09/13/2017 04:46 PM, James Cameron wrote:
> > > >
> > > >I'll give it some more testing and let you know, but it seems as
> > > >capable of keeping a connection as 4.13 plus my earlier revert.
> > > >
> >
> > Testing went well; removing the call to enable ASPM was as good as
> > changing the DBI read back to 16-bit width.
> >
> > > The change I sent earlier should be as good as reverting the change
> > > to write_byte in your reversion.
> >
> > Yes, that would be the hope.
> >
> > But with the 16-bit DBI read, the register REG_DBI_CTRL+0 is being
> > read as well, in the first read in _rtl8821ae_enable_aspm_back_door,
> > so perhaps reading that register has an unexpected side-effect.
> >
>
> I've ruled that out after testing for several days different kernels
> based on v4.13;
>
> - add an rtl_read_byte of REG_DBI_CTRL+0 in rtl8821ae_hw_init just
> after the call to enable_aspm; does not solve problem,
>
> - add an rtl_read_byte of REG_DBI_CTRL+0 at the start of
> _rtl8821ae_check_pcie_dma_hang; does not solve problem,
When the problem occurs, register 0x350 bit 25 is set, for which a
comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
hang.
So perhaps driver should call _rtl8821ae_check_pcie_dma_hang
and _rtl8821ae_reset_pcie_interface_dma.
Any ideas where to do this?
> [...]
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* RE: [EXT] Re: [PATCH] mwifiex: add device specific ioctl handler
From: Xinming Hu @ 2017-09-20 9:11 UTC (permalink / raw)
To: Souptick Joarder, Xinming Hu
Cc: Linux Wireless, Kalle Valo, Brian Norris, Dmitry Torokhov,
rajatja@google.com, Zhiyuan Yang, Tim Song, Cathy Luo,
Ganapathi Bhat
In-Reply-To: <CAFqt6zbMExWwykzNmU1Q8snvSyX-XJE+QTivrtBZGHEGKqyUSA@mail.gmail.com>
SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU291cHRpY2sgSm9h
cmRlciBbbWFpbHRvOmpyZHIubGludXhAZ21haWwuY29tXQ0KPiBTZW50OiAyMDE35bm0OeaciDIw
5pelIDE2OjA3DQo+IFRvOiBYaW5taW5nIEh1IDxodXhpbm1pbmc4MjBAZ21haWwuY29tPg0KPiBD
YzogTGludXggV2lyZWxlc3MgPGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZz47IEthbGxl
IFZhbG8NCj4gPGt2YWxvQGNvZGVhdXJvcmEub3JnPjsgQnJpYW4gTm9ycmlzIDxicmlhbm5vcnJp
c0Bnb29nbGUuY29tPjsgRG1pdHJ5DQo+IFRvcm9raG92IDxkdG9yQGdvb2dsZS5jb20+OyByYWph
dGphQGdvb2dsZS5jb207IFpoaXl1YW4gWWFuZw0KPiA8eWFuZ3p5QG1hcnZlbGwuY29tPjsgVGlt
IFNvbmcgPHNvbmd0YW9AbWFydmVsbC5jb20+OyBDYXRoeSBMdW8NCj4gPGNsdW9AbWFydmVsbC5j
b20+OyBHYW5hcGF0aGkgQmhhdCA8Z2JoYXRAbWFydmVsbC5jb20+OyBYaW5taW5nIEh1DQo+IDxo
dXhtQG1hcnZlbGwuY29tPg0KPiBTdWJqZWN0OiBbRVhUXSBSZTogW1BBVENIXSBtd2lmaWV4OiBh
ZGQgZGV2aWNlIHNwZWNpZmljIGlvY3RsIGhhbmRsZXINCj4gDQo+IEV4dGVybmFsIEVtYWlsDQo+
IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+IE9uIFdlZCwgU2VwIDIwLCAyMDE3IGF0IDEyOjE0IFBNLCBY
aW5taW5nIEh1IDxodXhpbm1pbmc4MjBAZ21haWwuY29tPg0KPiB3cm90ZToNCj4gPiBGcm9tOiBY
aW5taW5nIEh1IDxodXhtQG1hcnZlbGwuY29tPg0KPiA+DQo+ID4gQWRkIG5ldF9kZXYgbmRvX2Rv
X2lvY3RsIGhhbmRsZXIsIHdoaWNoIGNvdWxkIGJlIHVzZWQgZm9yIGRvd25sb2FkaW5nDQo+ID4g
aG9zdCBjb21tYW5kIGJ5IHV0aWxpdHkgaW4gbWFudWZhY3RvcnkgdGVzdA0KPiA+DQo+ID4gU2ln
bmVkLW9mZi1ieTogWGlubWluZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2Zm
LWJ5OiBDYXRoeSBMdW8gPGNsdW9AbWFydmVsbC5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogR2Fu
YXBhdGhpIEJoYXQgPGdiaGF0QG1hcnZlbGwuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL25l
dC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvY21kZXZ0LmMgfCA1OQ0KPiArKysrKysrKysrKysr
KysrKysrKysrKysrKysNCj4gPiAgZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4
L21haW4uYyAgIHwgMjMgKysrKysrKysrKysNCj4gPiAgZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L21haW4uaCAgIHwgIDcgKysrLQ0KPiA+ICAzIGZpbGVzIGNoYW5nZWQsIDg4
IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvY21kZXZ0LmMNCj4gPiBiL2RyaXZlcnMv
bmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9jbWRldnQuYw0KPiA+IGluZGV4IDBlZGM1ZDYu
Ljg2ZWUzOTkgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9t
d2lmaWV4L2NtZGV2dC5jDQo+ID4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9t
d2lmaWV4L2NtZGV2dC5jDQo+ID4gQEAgLTgzOSw2ICs4MzksOCBAQCBpbnQgbXdpZmlleF9wcm9j
ZXNzX2NtZHJlc3Aoc3RydWN0DQo+IG13aWZpZXhfYWRhcHRlciAqYWRhcHRlcikNCj4gPiAgICAg
ICAgICAgICAgICAgICAgICAgICBob3N0Y21kID0gYWRhcHRlci0+Y3Vycl9jbWQtPmRhdGFfYnVm
Ow0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIGhvc3RjbWQtPmxlbiA9IHNpemU7DQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgbWVtY3B5KGhvc3RjbWQtPmNtZCwgcmVzcCwgc2l6ZSk7
DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgYWRhcHRlci0+aG9zdGNtZF9yZXNwX2RhdGEu
bGVuID0gc2l6ZTsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBtZW1jcHkoYWRhcHRlci0+
aG9zdGNtZF9yZXNwX2RhdGEuY21kLA0KPiByZXNwLA0KPiA+ICsgc2l6ZSk7DQo+ID4gICAgICAg
ICAgICAgICAgIH0NCj4gPiAgICAgICAgIH0NCj4gPiAgICAgICAgIG9yaWdfY21kcmVzcF9ubyA9
IGxlMTZfdG9fY3B1KHJlc3AtPmNvbW1hbmQpOyBAQCAtMTIyMSw2DQo+ID4gKzEyMjMsNjMgQEAg
aW50IG13aWZpZXhfcmV0XzgwMl8xMV9oc19jZmcoc3RydWN0IG13aWZpZXhfcHJpdmF0ZQ0KPiA+
ICpwcml2LCAgfSAgRVhQT1JUX1NZTUJPTF9HUEwobXdpZmlleF9wcm9jZXNzX2hzX2NvbmZpZyk7
DQo+ID4NCj4gPiArLyogVGhpcyBmdW5jdGlvbiBnZXQgaG9zdGNtZCBkYXRhIGZyb20gdXNlcnNw
YWNlIGFuZCBjb25zdHJ1Y3QgYSBjbWQNCj4gPiArICogdG8gYmUgZG93bmxvYWQgdG8gRlcuDQo+
ID4gKyAqLw0KPiA+ICtpbnQgbXdpZmlleF9wcm9jZXNzX2hvc3RfY29tbWFuZChzdHJ1Y3QgbXdp
ZmlleF9wcml2YXRlICpwcml2LA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHN0cnVjdCBpZnJlcSAqcmVxKSB7DQo+ID4gKyAgICAgICBzdHJ1Y3QgbXdpZmlleF9kc19taXNj
X2NtZCAqaG9zdGNtZF9idWY7DQo+ID4gKyAgICAgICBzdHJ1Y3QgaG9zdF9jbWRfZHNfY29tbWFu
ZCAqY21kOw0KPiA+ICsgICAgICAgc3RydWN0IG13aWZpZXhfYWRhcHRlciAqYWRhcHRlciA9IHBy
aXYtPmFkYXB0ZXI7DQo+ID4gKyAgICAgICBpbnQgcmV0Ow0KPiA+ICsNCj4gPiArICAgICAgIGhv
c3RjbWRfYnVmID0ga3phbGxvYyhzaXplb2YoKmhvc3RjbWRfYnVmKSwgR0ZQX0tFUk5FTCk7DQo+
IA0KPiB3aWxsIGl0IGJlIHNpemVvZigqaG9zdGNtZF9idWYpIG9yIHNpemVvZiggc3RydWN0IG13
aWZpZXhfZHNfbWlzY19jbWQgKikgPw0KDQpJdCBzaG91bGQgYmUgc2l6ZW9mKCpob3N0Y21kX2J1
ZiksIGFzIHdlIGFyZSB0cnlpbmcgdG8gYWxsb2NhdGUgYSBzdHJ1Y3QsIG5vdCBhIHBvaW50ZXIu
DQoNCj4gDQo+ID4gKyAgICAgICBpZiAoIWhvc3RjbWRfYnVmKQ0KPiA+ICsgICAgICAgICAgICAg
ICByZXR1cm4gLUVOT01FTTsNCj4gPiArDQo+ID4gKyAgICAgICBjbWQgPSAodm9pZCAqKWhvc3Rj
bWRfYnVmLT5jbWQ7DQo+ID4gKw0KPiA+ICsgICAgICAgaWYgKGNvcHlfZnJvbV91c2VyKGNtZCwg
cmVxLT5pZnJfZGF0YSwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YoY21k
LT5jb21tYW5kKSArIHNpemVvZihjbWQtPnNpemUpKSkNCj4gew0KPiA+ICsgICAgICAgICAgICAg
ICByZXQgPSAtRUZBVUxUOw0KPiA+ICsgICAgICAgICAgICAgICBnb3RvIGRvbmU7DQo+ID4gKyAg
ICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgaG9zdGNtZF9idWYtPmxlbiA9IGxlMTZfdG9fY3B1
KGNtZC0+c2l6ZSk7DQo+ID4gKyAgICAgICBpZiAoaG9zdGNtZF9idWYtPmxlbiA+IE1XSUZJRVhf
U0laRV9PRl9DTURfQlVGRkVSKSB7DQo+ID4gKyAgICAgICAgICAgICAgIHJldCA9IC1FSU5WQUw7
DQo+ID4gKyAgICAgICAgICAgICAgIGdvdG8gZG9uZTsNCj4gPiArICAgICAgIH0NCj4gPiArDQo+
ID4gKyAgICAgICBpZiAoY29weV9mcm9tX3VzZXIoY21kLCByZXEtPmlmcl9kYXRhLCBob3N0Y21k
X2J1Zi0+bGVuKSkgew0KPiA+ICsgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOw0KPiA+ICsg
ICAgICAgICAgICAgICBnb3RvIGRvbmU7DQo+ID4gKyAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAg
ICAgaWYgKG13aWZpZXhfc2VuZF9jbWQocHJpdiwgMCwgMCwgMCwgaG9zdGNtZF9idWYsIHRydWUp
KSB7DQo+ID4gKyAgICAgICAgICAgICAgIGRldl9lcnIocHJpdi0+YWRhcHRlci0+ZGV2LCAiRmFp
bGVkIHRvIHByb2Nlc3MNCj4gaG9zdGNtZFxuIik7DQo+ID4gKyAgICAgICAgICAgICAgIHJldCA9
IC1FRkFVTFQ7DQo+ID4gKyAgICAgICAgICAgICAgIGdvdG8gZG9uZTsNCj4gPiArICAgICAgIH0N
Cj4gPiArDQo+ID4gKyAgICAgICBpZiAoYWRhcHRlci0+aG9zdGNtZF9yZXNwX2RhdGEubGVuID4g
aG9zdGNtZF9idWYtPmxlbikgew0KPiA+ICsgICAgICAgICAgICAgICByZXQgPSAtRUZCSUc7DQo+
ID4gKyAgICAgICAgICAgICAgIGdvdG8gZG9uZTsNCj4gPiArICAgICAgIH0NCj4gPiArDQo+ID4g
KyAgICAgICBpZiAoY29weV90b191c2VyKHJlcS0+aWZyX2RhdGEsIGFkYXB0ZXItPmhvc3RjbWRf
cmVzcF9kYXRhLmNtZCwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgYWRhcHRlci0+aG9z
dGNtZF9yZXNwX2RhdGEubGVuKSkgew0KPiA+ICsgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxU
Ow0KPiA+ICsgICAgICAgICAgICAgICBnb3RvIGRvbmU7DQo+ID4gKyAgICAgICB9DQo+ID4gKw0K
PiA+ICsgICAgICAgcmV0ID0gMDsNCj4gPiArZG9uZToNCj4gPiArICAgICAgIGtmcmVlKGhvc3Rj
bWRfYnVmKTsNCj4gPiArICAgICAgIHJldHVybiByZXQ7DQo+ID4gK30NCj4gPiArDQo+ID4gIC8q
DQo+ID4gICAqIFRoaXMgZnVuY3Rpb24gaGFuZGxlcyB0aGUgY29tbWFuZCByZXNwb25zZSBvZiBh
IHNsZWVwIGNvbmZpcm0NCj4gY29tbWFuZC4NCj4gPiAgICoNCj4gPiBkaWZmIC0tZ2l0IGEvZHJp
dmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L21haW4uYw0KPiA+IGIvZHJpdmVycy9u
ZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L21haW4uYw0KPiA+IGluZGV4IGVlNDBiNzMuLjNl
NzcwMGYgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lm
aWV4L21haW4uYw0KPiA+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmll
eC9tYWluLmMNCj4gPiBAQCAtMTI2NSwxMiArMTI2NSwzNSBAQCBzdGF0aWMgc3RydWN0IG5ldF9k
ZXZpY2Vfc3RhdHMNCj4gKm13aWZpZXhfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYp
DQo+ID4gICAgICAgICByZXR1cm4gbXdpZmlleF8xZF90b193bW1fcXVldWVbc2tiLT5wcmlvcml0
eV07DQo+ID4gIH0NCj4gPg0KPiA+ICtzdGF0aWMgaW50IG13aWZpZXhfZG9faW9jdGwoc3RydWN0
IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxDQo+ID4gKypyZXEsIGludCBjbWQpIHsNCj4g
PiArICAgICAgIHN0cnVjdCBtd2lmaWV4X3ByaXZhdGUgKnByaXYgPSBtd2lmaWV4X25ldGRldl9n
ZXRfcHJpdihkZXYpOw0KPiA+ICsgICAgICAgaW50IHJldDsNCj4gPiArDQo+ID4gKyAgICAgICBp
ZiAoIXByaXYtPmFkYXB0ZXItPm1mZ19tb2RlKQ0KPiA+ICsgICAgICAgICAgICAgICByZXR1cm4g
LUVJTlZBTDsNCj4gDQo+IHJldCBjYW4gYmUgdXNlZCBpbnN0ZWFkIG9mIHJldHVybmluZyAtRUlO
VkFMLg0KDQpHZW5lcmFsbHkgc3BlYWtpbmcsIEl0IGlzIGEgZ29vZCBiZWhhdmlvciB0aGF0IEZ1
bmN0aW9uIGhhdmUgYSBzaW5nbGUgcG9pbnQgb2YgZXhpdCwgdGh1cyBtYWtlIHN1cmUgcmlnaHQg
Y2xlYW51cC4NCkluIHRoaXMgZnVuY3Rpb24sIHRoZXJlIGlzIG5vIHN1Y2ggbmVlZHMsIGFuZCB3
ZSBtaWdodCBuZWVkIGFkZCAoMSkgZmxhZyBleGl0ICgyKSBzZXZlcmFsIGdvdG8gLg0KSSB3b3Vs
ZCBsaWtlIHRvIGtlZXAgY3VycmVudCBjb2Rpbmcgc3R5bGUgZm9yIHNpbXBsaWZ5LCBwbGVhc2Ug
c3VnZ2VzdCBpZiB5b3UgaGF2ZSBtb3JlIGNvbmNlcm4uDQoNClJlZ2FyZHMsDQpTaW1vbg0KPiAN
Cj4gPiArDQo+ID4gKyAgICAgICBtd2lmaWV4X2RiZyhwcml2LT5hZGFwdGVyLCAiaW9jdGwgY21k
ID0gMHgleFxuIiwgY21kKTsNCj4gPiArDQo+ID4gKyAgICAgICBzd2l0Y2ggKGNtZCkgew0KPiA+
ICsgICAgICAgY2FzZSBNV0lGSUVYX0hPU1RDTURfSU9DVEw6DQo+ID4gKyAgICAgICAgICAgICAg
IHJldCA9IG13aWZpZXhfcHJvY2Vzc19ob3N0X2NvbW1hbmQocHJpdiwgcmVxKTsNCj4gPiArICAg
ICAgICAgICAgICAgYnJlYWs7DQo+ID4gKyAgICAgICBkZWZhdWx0Og0KPiA+ICsgICAgICAgICAg
ICAgICByZXQgPSAtRUlOVkFMOw0KPiA+ICsgICAgICAgICAgICAgICBicmVhazsNCj4gPiArICAg
ICAgIH0NCj4gPiArDQo+ID4gKyAgICAgICByZXR1cm4gcmV0Ow0KPiA+ICt9DQo+ID4gKw0KPiA+
ICAvKiBOZXR3b3JrIGRldmljZSBoYW5kbGVycyAqLw0KPiA+ICBzdGF0aWMgY29uc3Qgc3RydWN0
IG5ldF9kZXZpY2Vfb3BzIG13aWZpZXhfbmV0ZGV2X29wcyA9IHsNCj4gPiAgICAgICAgIC5uZG9f
b3BlbiA9IG13aWZpZXhfb3BlbiwNCj4gPiAgICAgICAgIC5uZG9fc3RvcCA9IG13aWZpZXhfY2xv
c2UsDQo+ID4gICAgICAgICAubmRvX3N0YXJ0X3htaXQgPSBtd2lmaWV4X2hhcmRfc3RhcnRfeG1p
dCwNCj4gPiAgICAgICAgIC5uZG9fc2V0X21hY19hZGRyZXNzID0gbXdpZmlleF9uZG9fc2V0X21h
Y19hZGRyZXNzLA0KPiA+ICsgICAgICAgLm5kb19kb19pb2N0bCA9IG13aWZpZXhfZG9faW9jdGws
DQo+ID4gICAgICAgICAubmRvX3ZhbGlkYXRlX2FkZHIgPSBldGhfdmFsaWRhdGVfYWRkciwNCj4g
PiAgICAgICAgIC5uZG9fdHhfdGltZW91dCA9IG13aWZpZXhfdHhfdGltZW91dCwNCj4gPiAgICAg
ICAgIC5uZG9fZ2V0X3N0YXRzID0gbXdpZmlleF9nZXRfc3RhdHMsIGRpZmYgLS1naXQNCj4gPiBh
L2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9tYWluLmgNCj4gPiBiL2RyaXZl
cnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9tYWluLmgNCj4gPiBpbmRleCBhNzZiZDc5
Li40NjM5ZjQ5IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwv
bXdpZmlleC9tYWluLmgNCj4gPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213
aWZpZXgvbWFpbi5oDQo+ID4gQEAgLTE2MCw2ICsxNjAsOSBAQCBlbnVtIHsNCj4gPiAgLyogVGhy
ZXNob2xkIGZvciB0eF90aW1lb3V0X2NudCBiZWZvcmUgd2UgdHJpZ2dlciBhIGNhcmQgcmVzZXQg
Ki8NCj4gPiAgI2RlZmluZSBUWF9USU1FT1VUX1RIUkVTSE9MRCAgIDYNCj4gPg0KPiA+ICsvKiBJ
T0NUTCBudW1iZXIgdXNlZCBmb3IgaG9zdGNtZCBwcm9jZXNzKi8gI2RlZmluZQ0KPiA+ICtNV0lG
SUVYX0hPU1RDTURfSU9DVEwgKFNJT0NERVZQUklWQVRFICsgMSkNCj4gPiArDQo+ID4gICNkZWZp
bmUgTVdJRklFWF9EUlZfSU5GT19TSVpFX01BWCAweDQwMDAwDQo+ID4NCj4gPiAgLyogQWRkcmVz
cyBhbGlnbm1lbnQgKi8NCj4gPiBAQCAtOTEyLDYgKzkxNSw3IEBAIHN0cnVjdCBtd2lmaWV4X2Fk
YXB0ZXIgew0KPiA+ICAgICAgICAgdTggZXZlbnRfcmVjZWl2ZWQ7DQo+ID4gICAgICAgICB1OCBk
YXRhX3JlY2VpdmVkOw0KPiA+ICAgICAgICAgdTE2IHNlcV9udW07DQo+ID4gKyAgICAgICBzdHJ1
Y3QgbXdpZmlleF9kc19taXNjX2NtZCBob3N0Y21kX3Jlc3BfZGF0YTsNCj4gPiAgICAgICAgIHN0
cnVjdCBjbWRfY3RybF9ub2RlICpjbWRfcG9vbDsNCj4gPiAgICAgICAgIHN0cnVjdCBjbWRfY3Ry
bF9ub2RlICpjdXJyX2NtZDsNCj4gPiAgICAgICAgIC8qIHNwaW4gbG9jayBmb3IgY29tbWFuZCAq
Lw0KPiA+IEBAIC0xNjExLDcgKzE2MTUsOCBAQCBpbnQgbXdpZmlleF9nZXRfdGRsc19saXN0KHN0
cnVjdCBtd2lmaWV4X3ByaXZhdGUNCj4gPiAqcHJpdiwNCj4gPiAgdTggbXdpZmlleF9nZXRfY2Vu
dGVyX2ZyZXFfaW5kZXgoc3RydWN0IG13aWZpZXhfcHJpdmF0ZSAqcHJpdiwgdTggYmFuZCwNCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1MzIgcHJpX2NoYW4sIHU4IGNoYW5f
YncpOyAgaW50DQo+ID4gbXdpZmlleF9pbml0X2NoYW5uZWxfc2Nhbl9nYXAoc3RydWN0IG13aWZp
ZXhfYWRhcHRlciAqYWRhcHRlcik7DQo+ID4gLQ0KPiA+ICtpbnQgbXdpZmlleF9wcm9jZXNzX2hv
c3RfY29tbWFuZChzdHJ1Y3QgbXdpZmlleF9wcml2YXRlICpwcml2LA0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBpZnJlcSAqcmVxKTsNCj4gPiAgaW50IG13aWZp
ZXhfdGRsc19jaGVja190eChzdHJ1Y3QgbXdpZmlleF9wcml2YXRlICpwcml2LCBzdHJ1Y3QNCj4g
PiBza19idWZmICpza2IpOyAgdm9pZCBtd2lmaWV4X2ZsdXNoX2F1dG9fdGRsc19saXN0KHN0cnVj
dA0KPiA+IG13aWZpZXhfcHJpdmF0ZSAqcHJpdik7ICB2b2lkDQo+ID4gbXdpZmlleF9hdXRvX3Rk
bHNfdXBkYXRlX3BlZXJfc3RhdHVzKHN0cnVjdCBtd2lmaWV4X3ByaXZhdGUgKnByaXYsDQo+ID4g
LS0NCj4gPiAxLjkuMQ0KPiA+DQo=
^ permalink raw reply
* Re: [PATCH] mwifiex: add device specific ioctl handler
From: Arend van Spriel @ 2017-09-20 8:39 UTC (permalink / raw)
To: Xinming Hu, Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja, Zhiyuan Yang,
Tim Song, Cathy Luo, Ganapathi Bhat, Xinming Hu
In-Reply-To: <1505889853-20493-1-git-send-email-huxinming820@gmail.com>
On 9/20/2017 8:44 AM, Xinming Hu wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> Add net_dev ndo_do_ioctl handler, which could be used for
> downloading host command by utility in manufactory test
Not sure if we want ioctls in upstream wireless drivers. You could look
at nl80211 vendor commands, but that is also under scrutiny if common
wifi functionality is provided by it. I am pretty sure Kalle has his
ideas about this :-)
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mwifiex: add device specific ioctl handler
From: Souptick Joarder @ 2017-09-20 8:06 UTC (permalink / raw)
To: Xinming Hu
Cc: Linux Wireless, Kalle Valo, Brian Norris, Dmitry Torokhov,
rajatja, Zhiyuan Yang, Tim Song, Cathy Luo, Ganapathi Bhat,
Xinming Hu
In-Reply-To: <1505889853-20493-1-git-send-email-huxinming820@gmail.com>
On Wed, Sep 20, 2017 at 12:14 PM, Xinming Hu <huxinming820@gmail.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> Add net_dev ndo_do_ioctl handler, which could be used for
> downloading host command by utility in manufactory test
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++++++++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/main.c | 23 +++++++++++
> drivers/net/wireless/marvell/mwifiex/main.h | 7 +++-
> 3 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 0edc5d6..86ee399 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -839,6 +839,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
> hostcmd = adapter->curr_cmd->data_buf;
> hostcmd->len = size;
> memcpy(hostcmd->cmd, resp, size);
> + adapter->hostcmd_resp_data.len = size;
> + memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
> }
> }
> orig_cmdresp_no = le16_to_cpu(resp->command);
> @@ -1221,6 +1223,63 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
> }
> EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
>
> +/* This function get hostcmd data from userspace and construct a cmd
> + * to be download to FW.
> + */
> +int mwifiex_process_host_command(struct mwifiex_private *priv,
> + struct ifreq *req)
> +{
> + struct mwifiex_ds_misc_cmd *hostcmd_buf;
> + struct host_cmd_ds_command *cmd;
> + struct mwifiex_adapter *adapter = priv->adapter;
> + int ret;
> +
> + hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
will it be sizeof(*hostcmd_buf) or sizeof( struct mwifiex_ds_misc_cmd *) ?
> + if (!hostcmd_buf)
> + return -ENOMEM;
> +
> + cmd = (void *)hostcmd_buf->cmd;
> +
> + if (copy_from_user(cmd, req->ifr_data,
> + sizeof(cmd->command) + sizeof(cmd->size))) {
> + ret = -EFAULT;
> + goto done;
> + }
> +
> + hostcmd_buf->len = le16_to_cpu(cmd->size);
> + if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
> + ret = -EINVAL;
> + goto done;
> + }
> +
> + if (copy_from_user(cmd, req->ifr_data, hostcmd_buf->len)) {
> + ret = -EFAULT;
> + goto done;
> + }
> +
> + if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
> + dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
> + ret = -EFAULT;
> + goto done;
> + }
> +
> + if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
> + ret = -EFBIG;
> + goto done;
> + }
> +
> + if (copy_to_user(req->ifr_data, adapter->hostcmd_resp_data.cmd,
> + adapter->hostcmd_resp_data.len)) {
> + ret = -EFAULT;
> + goto done;
> + }
> +
> + ret = 0;
> +done:
> + kfree(hostcmd_buf);
> + return ret;
> +}
> +
> /*
> * This function handles the command response of a sleep confirm command.
> *
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index ee40b73..3e7700f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1265,12 +1265,35 @@ static struct net_device_stats *mwifiex_get_stats(struct net_device *dev)
> return mwifiex_1d_to_wmm_queue[skb->priority];
> }
>
> +static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
> +{
> + struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
> + int ret;
> +
> + if (!priv->adapter->mfg_mode)
> + return -EINVAL;
ret can be used instead of returning -EINVAL.
> +
> + mwifiex_dbg(priv->adapter, "ioctl cmd = 0x%x\n", cmd);
> +
> + switch (cmd) {
> + case MWIFIEX_HOSTCMD_IOCTL:
> + ret = mwifiex_process_host_command(priv, req);
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> /* Network device handlers */
> static const struct net_device_ops mwifiex_netdev_ops = {
> .ndo_open = mwifiex_open,
> .ndo_stop = mwifiex_close,
> .ndo_start_xmit = mwifiex_hard_start_xmit,
> .ndo_set_mac_address = mwifiex_ndo_set_mac_address,
> + .ndo_do_ioctl = mwifiex_do_ioctl,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_tx_timeout = mwifiex_tx_timeout,
> .ndo_get_stats = mwifiex_get_stats,
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index a76bd79..4639f49 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -160,6 +160,9 @@ enum {
> /* Threshold for tx_timeout_cnt before we trigger a card reset */
> #define TX_TIMEOUT_THRESHOLD 6
>
> +/* IOCTL number used for hostcmd process*/
> +#define MWIFIEX_HOSTCMD_IOCTL (SIOCDEVPRIVATE + 1)
> +
> #define MWIFIEX_DRV_INFO_SIZE_MAX 0x40000
>
> /* Address alignment */
> @@ -912,6 +915,7 @@ struct mwifiex_adapter {
> u8 event_received;
> u8 data_received;
> u16 seq_num;
> + struct mwifiex_ds_misc_cmd hostcmd_resp_data;
> struct cmd_ctrl_node *cmd_pool;
> struct cmd_ctrl_node *curr_cmd;
> /* spin lock for command */
> @@ -1611,7 +1615,8 @@ int mwifiex_get_tdls_list(struct mwifiex_private *priv,
> u8 mwifiex_get_center_freq_index(struct mwifiex_private *priv, u8 band,
> u32 pri_chan, u8 chan_bw);
> int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter);
> -
> +int mwifiex_process_host_command(struct mwifiex_private *priv,
> + struct ifreq *req);
> int mwifiex_tdls_check_tx(struct mwifiex_private *priv, struct sk_buff *skb);
> void mwifiex_flush_auto_tdls_list(struct mwifiex_private *priv);
> void mwifiex_auto_tdls_update_peer_status(struct mwifiex_private *priv,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] mwifiex: add device specific ioctl handler
From: Xinming Hu @ 2017-09-20 6:44 UTC (permalink / raw)
To: Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja, Zhiyuan Yang,
Tim Song, Cathy Luo, Ganapathi Bhat, Xinming Hu
From: Xinming Hu <huxm@marvell.com>
Add net_dev ndo_do_ioctl handler, which could be used for
downloading host command by utility in manufactory test
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++++++++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.c | 23 +++++++++++
drivers/net/wireless/marvell/mwifiex/main.h | 7 +++-
3 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 0edc5d6..86ee399 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -839,6 +839,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+ adapter->hostcmd_resp_data.len = size;
+ memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1221,6 +1223,63 @@ int mwifiex_ret_802_11_hs_cfg(struct mwifiex_private *priv,
}
EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+ * to be download to FW.
+ */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+ struct ifreq *req)
+{
+ struct mwifiex_ds_misc_cmd *hostcmd_buf;
+ struct host_cmd_ds_command *cmd;
+ struct mwifiex_adapter *adapter = priv->adapter;
+ int ret;
+
+ hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+ if (!hostcmd_buf)
+ return -ENOMEM;
+
+ cmd = (void *)hostcmd_buf->cmd;
+
+ if (copy_from_user(cmd, req->ifr_data,
+ sizeof(cmd->command) + sizeof(cmd->size))) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ hostcmd_buf->len = le16_to_cpu(cmd->size);
+ if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (copy_from_user(cmd, req->ifr_data, hostcmd_buf->len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+ dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+ ret = -EFBIG;
+ goto done;
+ }
+
+ if (copy_to_user(req->ifr_data, adapter->hostcmd_resp_data.cmd,
+ adapter->hostcmd_resp_data.len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ ret = 0;
+done:
+ kfree(hostcmd_buf);
+ return ret;
+}
+
/*
* This function handles the command response of a sleep confirm command.
*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b73..3e7700f 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1265,12 +1265,35 @@ static struct net_device_stats *mwifiex_get_stats(struct net_device *dev)
return mwifiex_1d_to_wmm_queue[skb->priority];
}
+static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ int ret;
+
+ if (!priv->adapter->mfg_mode)
+ return -EINVAL;
+
+ mwifiex_dbg(priv->adapter, "ioctl cmd = 0x%x\n", cmd);
+
+ switch (cmd) {
+ case MWIFIEX_HOSTCMD_IOCTL:
+ ret = mwifiex_process_host_command(priv, req);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
/* Network device handlers */
static const struct net_device_ops mwifiex_netdev_ops = {
.ndo_open = mwifiex_open,
.ndo_stop = mwifiex_close,
.ndo_start_xmit = mwifiex_hard_start_xmit,
.ndo_set_mac_address = mwifiex_ndo_set_mac_address,
+ .ndo_do_ioctl = mwifiex_do_ioctl,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = mwifiex_tx_timeout,
.ndo_get_stats = mwifiex_get_stats,
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index a76bd79..4639f49 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -160,6 +160,9 @@ enum {
/* Threshold for tx_timeout_cnt before we trigger a card reset */
#define TX_TIMEOUT_THRESHOLD 6
+/* IOCTL number used for hostcmd process*/
+#define MWIFIEX_HOSTCMD_IOCTL (SIOCDEVPRIVATE + 1)
+
#define MWIFIEX_DRV_INFO_SIZE_MAX 0x40000
/* Address alignment */
@@ -912,6 +915,7 @@ struct mwifiex_adapter {
u8 event_received;
u8 data_received;
u16 seq_num;
+ struct mwifiex_ds_misc_cmd hostcmd_resp_data;
struct cmd_ctrl_node *cmd_pool;
struct cmd_ctrl_node *curr_cmd;
/* spin lock for command */
@@ -1611,7 +1615,8 @@ int mwifiex_get_tdls_list(struct mwifiex_private *priv,
u8 mwifiex_get_center_freq_index(struct mwifiex_private *priv, u8 band,
u32 pri_chan, u8 chan_bw);
int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter);
-
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+ struct ifreq *req);
int mwifiex_tdls_check_tx(struct mwifiex_private *priv, struct sk_buff *skb);
void mwifiex_flush_auto_tdls_list(struct mwifiex_private *priv);
void mwifiex_auto_tdls_update_peer_status(struct mwifiex_private *priv,
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox