* Re: WIFI P2P ping doesn't work.
From: Matt Chen @ 2013-10-08 16:03 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless
In-Reply-To: <52542B3B.1020703@rempel-privat.de>
Hi Oleksij,
Thanks for the info anyway. :)
2013/10/8 Oleksij Rempel <linux@rempel-privat.de>:
> Hi Matt,
>
> no suggestions. I was able to reproduce same issue yesterday on
> ath9k_htc. But currently no time to digg in it.
>
>
> Am 08.10.2013 17:41, schrieb Matt Chen:
>> No one has any suggestion and comment ?
>>
>> 2013/10/8 Matt Chen <machen@suse.com>:
>>> Hi list,
>>>
>>> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
>>> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
>>> with most recent commit.
>>>
>>> The my_p2p_supplicant.conf for my wpa_supplicant is :
>>> =======================================
>>> ctrl=/var/run/wpa_supplicant
>>> update_config=1
>>>
>>> device_name=HP GO
>>> device_type=1-0050F204-2
>>>
>>> p2p_go_ht40=1
>>>
>>> =========================================
>>>
>>> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
>>> -ddt -f /var/log/wpa_supplicant -B
>>>
>>> I use wpa_cli to work on P2P. So here goes my case:
>>>
>>> M#1
>>> p2p_find
>>> p2p_stop
>>> p2p_peers
>>> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>>>
>>> M#2
>>> p2p_find
>>> p2p_stop
>>> p2p_peers
>>> p2p_connect [M#1 MAC ADDRESS] pbc
>>>
>>>
>>> Then I can find the M#1 become the P0 GO mode and M#2 become station
>>> mode. And each status is completed. But after that, I set each machine
>>> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
>>> not able to ping each IP.
>>>
>>> Is there anything I am doing wrong ?
>>>
>>> Thank you.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> Regards,
> Oleksij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: WIFI P2P ping doesn't work.
From: Oleksij Rempel @ 2013-10-08 15:56 UTC (permalink / raw)
To: Matt Chen, linux-wireless
In-Reply-To: <CALx5=V8AJr5FTWkbT+s79kbPX2NftmbC74HgH3V5TEUj0gvdpA@mail.gmail.com>
Hi Matt,
no suggestions. I was able to reproduce same issue yesterday on
ath9k_htc. But currently no time to digg in it.
Am 08.10.2013 17:41, schrieb Matt Chen:
> No one has any suggestion and comment ?
>
> 2013/10/8 Matt Chen <machen@suse.com>:
>> Hi list,
>>
>> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
>> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
>> with most recent commit.
>>
>> The my_p2p_supplicant.conf for my wpa_supplicant is :
>> =======================================
>> ctrl=/var/run/wpa_supplicant
>> update_config=1
>>
>> device_name=HP GO
>> device_type=1-0050F204-2
>>
>> p2p_go_ht40=1
>>
>> =========================================
>>
>> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
>> -ddt -f /var/log/wpa_supplicant -B
>>
>> I use wpa_cli to work on P2P. So here goes my case:
>>
>> M#1
>> p2p_find
>> p2p_stop
>> p2p_peers
>> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>>
>> M#2
>> p2p_find
>> p2p_stop
>> p2p_peers
>> p2p_connect [M#1 MAC ADDRESS] pbc
>>
>>
>> Then I can find the M#1 become the P0 GO mode and M#2 become station
>> mode. And each status is completed. But after that, I set each machine
>> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
>> not able to ping each IP.
>>
>> Is there anything I am doing wrong ?
>>
>> Thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Oleksij
^ permalink raw reply
* Re: WIFI P2P ping doesn't work.
From: Matt Chen @ 2013-10-08 15:41 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CALx5=V_OdHRJsourv2Hiykg-shyrisdrNnzD1qvpjAWR2iQyfg@mail.gmail.com>
No one has any suggestion and comment ?
2013/10/8 Matt Chen <machen@suse.com>:
> Hi list,
>
> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
> with most recent commit.
>
> The my_p2p_supplicant.conf for my wpa_supplicant is :
> =======================================
> ctrl=/var/run/wpa_supplicant
> update_config=1
>
> device_name=HP GO
> device_type=1-0050F204-2
>
> p2p_go_ht40=1
>
> =========================================
>
> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
> -ddt -f /var/log/wpa_supplicant -B
>
> I use wpa_cli to work on P2P. So here goes my case:
>
> M#1
> p2p_find
> p2p_stop
> p2p_peers
> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>
> M#2
> p2p_find
> p2p_stop
> p2p_peers
> p2p_connect [M#1 MAC ADDRESS] pbc
>
>
> Then I can find the M#1 become the P0 GO mode and M#2 become station
> mode. And each status is completed. But after that, I set each machine
> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
> not able to ping each IP.
>
> Is there anything I am doing wrong ?
>
> Thank you.
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192cu: Fix error in pointer arithmetic
From: Larry Finger @ 2013-10-08 15:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Mark Cave-Ayland, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
An error in calculating the offset in an skb causes the driver to read
essential device info from the wrong locations. The main effect is that
automatic gain calculations are nonsense.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [2.6.39+]
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 04c7e57..25e50ff 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -343,7 +343,8 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
(bool)GET_RX_DESC_PAGGR(pdesc));
rx_status->mactime = GET_RX_DESC_TSFL(pdesc);
if (phystatus) {
- p_drvinfo = (struct rx_fwinfo_92c *)(pdesc + RTL_RX_DESC_SIZE);
+ p_drvinfo = (struct rx_fwinfo_92c *)(skb->data +
+ stats->rx_bufshift);
rtl92c_translate_rx_signal_stuff(hw, skb, stats, pdesc,
p_drvinfo);
}
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Add new firmware files for rtl8192cu
From: Larry Finger @ 2013-10-08 15:00 UTC (permalink / raw)
To: dwmw2, Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1380234392-31062-1-git-send-email-Larry.Finger@lwfinger.net>
On 09/26/2013 05:26 PM, Larry Finger wrote:
> The vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404
> includes new firmware files. These were extracted from data statements
> in that driver to form these files.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 3 +++
> rtlwifi/rtl8192cufw_A.bin | Bin 0 -> 16116 bytes
> rtlwifi/rtl8192cufw_B.bin | Bin 0 -> 16096 bytes
> rtlwifi/rtl8192cufw_TMSC.bin | Bin 0 -> 16116 bytes
> 4 files changed, 3 insertions(+)
> create mode 100644 rtlwifi/rtl8192cufw_A.bin
> create mode 100644 rtlwifi/rtl8192cufw_B.bin
> create mode 100644 rtlwifi/rtl8192cufw_TMSC.bin
I understand that you probably have too much to do, but I am inquiring about the
status of this submission and "[PATCH] rtlwifi: Add new firmware files for
rtl8188eu" that I sent on 09/27/2013. I have several patches that depend on
these firmware files, and I would prefer that those driver patches are submitted
in time to make the 3.13 kernel.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 14:52 UTC (permalink / raw)
To: Johannes Berg
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <1381239951.13359.13.camel@jlt4.sipsolutions.net>
On 8 October 2013 15:45, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 15:45 +0200, Johannes Berg wrote:
>> On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
>>
>> > Actually, as the size is always the same, it should be feasible to
>> > alloc a couple of request structs at init time. would one for rx and
>> > one for tx be sufficient? or is this code more reentrant than that?
>>
>> TX can run concurrently on multiple (four) queues using the same key.
>
> And maybe even more with injection ... I wouldn't go there.
>
OK, clear.
If you think this patch has any merit at all, I am happy to modify it
so that it kmalloc()s the request struct with GFP_ATOMIC at every
invocation.
However, personally I don't think this should be necessary and in fact
my patch removes a stack allocation of u8[48] (from
ieee80211_crypto_ccmp_decrypt() and from ccmp_encrypt_skb() in wpa.c)
so it does even out a bit.
regards,
Ard.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 13:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <1381239908.13359.12.camel@jlt4.sipsolutions.net>
On Tue, 2013-10-08 at 15:45 +0200, Johannes Berg wrote:
> On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
>
> > Actually, as the size is always the same, it should be feasible to
> > alloc a couple of request structs at init time. would one for rx and
> > one for tx be sufficient? or is this code more reentrant than that?
>
> TX can run concurrently on multiple (four) queues using the same key.
And maybe even more with injection ... I wouldn't go there.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 13:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <23D74823-0DE3-4A87-9E89-310F437A328D@linaro.org>
On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
> Actually, as the size is always the same, it should be feasible to
> alloc a couple of request structs at init time. would one for rx and
> one for tx be sufficient? or is this code more reentrant than that?
TX can run concurrently on multiple (four) queues using the same key.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 13:41 UTC (permalink / raw)
To: David Laight
Cc: Johannes Berg, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B737B@saturn3.aculab.com>
On 8 okt. 2013, at 15:01, "David Laight" <David.Laight@ACULAB.COM> wrote:
>> Hmm, thanks I guess. I'll need to review this in more detail, but I have
>> a question first:
>>
>>> + /* allocate the variable sized aead_request on the stack */
>>> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>>> + sizeof(struct aead_request));
>>> + struct aead_request req[1 + l];
>>
>> This looks a bit odd, why round up first and then add one? Why even
>> bother using a struct array rather than some local struct like
>
> Is it even a good idea to be allocating variable sized items
> on the kernel stack?
>
> There has to be enough stack available for the maximum number
> of entries - so there is little point in dynamically sizing it.
Actually, as the size is always the same, it should be feasible to alloc a couple of request structs at init time. would one for rx and one for tx be sufficient? or is this code more reentrant than that?
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 13:16 UTC (permalink / raw)
To: David Laight
Cc: Johannes Berg, linux-wireless, netdev, Patch Tracking,
John Linville
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B737B@saturn3.aculab.com>
On 8 October 2013 15:01, David Laight <David.Laight@aculab.com> wrote:
>> Hmm, thanks I guess. I'll need to review this in more detail, but I have
>> a question first:
>>
>> > + /* allocate the variable sized aead_request on the stack */
>> > + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>> > + sizeof(struct aead_request));
>> > + struct aead_request req[1 + l];
>>
>> This looks a bit odd, why round up first and then add one? Why even
>> bother using a struct array rather than some local struct like
>
> Is it even a good idea to be allocating variable sized items
> on the kernel stack?
>
> There has to be enough stack available for the maximum number
> of entries - so there is little point in dynamically sizing it.
>
The result of crypto_aead_reqsize() has nothing to do with the input
or output data, it is a property of the particular implementation of
ccm(aes) that is being used. In the generic case (ccm.c),
it always returns the size of this struct
struct crypto_ccm_req_priv_ctx {
u8 odata[16];
u8 idata[16];
u8 auth_tag[16];
u32 ilen;
u32 flags;
struct scatterlist src[2];
struct scatterlist dst[2];
struct ablkcipher_request abreq;
};
while the particular implementation that I am working on for ARM64
always has size 0. Note that this is data that would otherwise be
allocated on the stack, but in the case of aead, which supports an
asynchronous interface (which this code does not use btw), the data is
attached to the end of the aead_request struct instead.
The alternative is to allocate it dynamically using GFP_ATOMIC and
free it at the end of the function, but in this particular case I
don't think that makes much sense tbh
--
Ard.
^ permalink raw reply
* RE: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: David Laight @ 2013-10-08 13:01 UTC (permalink / raw)
To: Johannes Berg, Ard Biesheuvel; +Cc: linux-wireless, netdev, patches, linville
In-Reply-To: <1381233152.13359.10.camel@jlt4.sipsolutions.net>
PiBIbW0sIHRoYW5rcyBJIGd1ZXNzLiBJJ2xsIG5lZWQgdG8gcmV2aWV3IHRoaXMgaW4gbW9yZSBk
ZXRhaWwsIGJ1dCBJIGhhdmUNCj4gYSBxdWVzdGlvbiBmaXJzdDoNCj4gDQo+ID4gKwkvKiBhbGxv
Y2F0ZSB0aGUgdmFyaWFibGUgc2l6ZWQgYWVhZF9yZXF1ZXN0IG9uIHRoZSBzdGFjayAqLw0KPiA+
ICsJaW50IGwgPSBESVZfUk9VTkRfVVAoY3J5cHRvX2FlYWRfcmVxc2l6ZSh0Zm0pLA0KPiA+ICsJ
CQkgICAgIHNpemVvZihzdHJ1Y3QgYWVhZF9yZXF1ZXN0KSk7DQo+ID4gKwlzdHJ1Y3QgYWVhZF9y
ZXF1ZXN0IHJlcVsxICsgbF07DQo+IA0KPiBUaGlzIGxvb2tzIGEgYml0IG9kZCwgd2h5IHJvdW5k
IHVwIGZpcnN0IGFuZCB0aGVuIGFkZCBvbmU/IFdoeSBldmVuDQo+IGJvdGhlciB1c2luZyBhIHN0
cnVjdCBhcnJheSByYXRoZXIgdGhhbiBzb21lIGxvY2FsIHN0cnVjdCBsaWtlDQoNCklzIGl0IGV2
ZW4gYSBnb29kIGlkZWEgdG8gYmUgYWxsb2NhdGluZyB2YXJpYWJsZSBzaXplZCBpdGVtcw0Kb24g
dGhlIGtlcm5lbCBzdGFjaz8NCg0KVGhlcmUgaGFzIHRvIGJlIGVub3VnaCBzdGFjayBhdmFpbGFi
bGUgZm9yIHRoZSBtYXhpbXVtIG51bWJlcg0Kb2YgZW50cmllcyAtIHNvIHRoZXJlIGlzIGxpdHRs
ZSBwb2ludCBpbiBkeW5hbWljYWxseSBzaXppbmcgaXQuDQoNCglEYXZpZA0KDQo=
^ permalink raw reply
* Re: [PATCH/RFT v2 1/4] ath10k: fix add_interface failure handling
From: Kalle Valo @ 2013-10-08 12:54 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380865425-3791-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> If something failed along add_interface() setup it
> was possible to leak a vdev id, vdev and peer.
>
> This could end up with leaked FW state or FW crash
> (assuming add_interface() failure wasn't a result of
> a crash).
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Then I apply this patch on top of current ath.git master branch (commit
18fe0b53e76) interface up fails on the managed mode:
$ sudo ip link set wlan1 up
RTNETLINK answers: Invalid argument
Logs don't have anything special (the TX encap error was already
before):
[ 1259.818863] ath10k: MSI-X didn't succeed (1), trying MSI
[ 1259.819298] ath10k_pci 0000:02:00.0: irq 49 for MSI/MSI-X
[ 1259.820055] ath10k: MSI interrupt handling
[ 1260.747877] ath10k: UART prints disabled
[ 1260.828219] ath10k: firmware 10.1.389 booted
[ 1260.837585] ath10k: htt target version 2.1
[ 1260.838498] ath10k: Failed to set TX encap: -22
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix RX performance when using AP 10.X FW
From: Kalle Valo @ 2013-10-08 12:24 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1381201236-17035-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Due to oversight AP 10.X support was merged with
> Ethernet RX decap mode.
>
> Only Native Wifi RX decap mode guarantees IP
> header is properly aligned and avoids sk_buff data
> realignment (which is very expensive
> performance-wise) in mac80211.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/2] ath10k: minor fixes
From: Kalle Valo @ 2013-10-08 12:23 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380867200-19714-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The patchset fixes a compilation warning and a
> memory leak in FW loading code.
>
> Michal Kazior (2):
> ath10k: fix printf format string
> ath10k: fix possible memory leak in new FW loading
Both appplied, thanks for fixing my bugs :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, John Linville
In-Reply-To: <1381234564.13359.11.camel@jlt4.sipsolutions.net>
On 8 October 2013 14:16, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 14:00 +0200, Ard Biesheuvel wrote:
>
>> BTW I should probably have mentioned that this is fully tested code:
>> my zd1211 works happily with it using pairwise CCMP with no
>> regressions in performance.
>
> Good to know. Not that I think zd1211 is a good device for performance
> tests (you'd have to measure CPU utilisation in some way), but
> ultimately it doesn't really matter as all the high-performance devices
> need hardware crypto anyway.
>
I agree. I am not saying the typical performance of a zd1211 is a
meaningful quantity, just that this particular device performs
identically before and after applying this patch, which suggests that
it is not creating lots of corrupted frames or messing up the
authentication.
Regards,
--
Ard.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 12:16 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <CAKv+Gu9-ddqyuGg=NDFoWzNko+0uMG_po6WnzTc7g3DAzx=_dQ@mail.gmail.com>
On Tue, 2013-10-08 at 14:00 +0200, Ard Biesheuvel wrote:
> BTW I should probably have mentioned that this is fully tested code:
> my zd1211 works happily with it using pairwise CCMP with no
> regressions in performance.
Good to know. Not that I think zd1211 is a good device for performance
tests (you'd have to measure CPU utilisation in some way), but
ultimately it doesn't really matter as all the high-performance devices
need hardware crypto anyway.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 12:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <1381233152.13359.10.camel@jlt4.sipsolutions.net>
On 8 October 2013 13:52, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 13:31 +0200, Ard Biesheuvel wrote:
>
> Hmm, thanks I guess. I'll need to review this in more detail, but I have
> a question first:
>
>> + /* allocate the variable sized aead_request on the stack */
>> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>> + sizeof(struct aead_request));
>> + struct aead_request req[1 + l];
>
> This looks a bit odd, why round up first and then add one? Why even
> bother using a struct array rather than some local struct like
>
> struct {
> struct aead_request req;
> u8 data[crypto_aed_reqsize(tfm)];
> } req_data;
>
> or so?
>
Yes, that looks much better. I will put that in my v2, let me know if
you have more questions/comments.
BTW I should probably have mentioned that this is fully tested code:
my zd1211 works happily with it using pairwise CCMP with no
regressions in performance.
Cheers,
Ard.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 11:52 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless, netdev, patches, linville
In-Reply-To: <1381231915-24232-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, 2013-10-08 at 13:31 +0200, Ard Biesheuvel wrote:
Hmm, thanks I guess. I'll need to review this in more detail, but I have
a question first:
> + /* allocate the variable sized aead_request on the stack */
> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
> + sizeof(struct aead_request));
> + struct aead_request req[1 + l];
This looks a bit odd, why round up first and then add one? Why even
bother using a struct array rather than some local struct like
struct {
struct aead_request req;
u8 data[crypto_aed_reqsize(tfm)];
} req_data;
or so?
johannes
^ permalink raw reply
* [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 11:31 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: patches, johannes, linville, Ard Biesheuvel
Use the generic CCM aead chaining mode driver rather than a local
implementation that sits right on top of the core AES cipher.
This allows the use of accelerated implementations of either
CCM as a whole or the CTR mode which it encapsulates.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/Kconfig | 1 +
net/mac80211/aes_ccm.c | 165 +++++++++++++++++--------------------------------
net/mac80211/aes_ccm.h | 8 +--
net/mac80211/key.h | 2 +-
net/mac80211/wpa.c | 24 +++----
5 files changed, 71 insertions(+), 129 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 62535fe..dc31ec3 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -4,6 +4,7 @@ config MAC80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select CRYPTO_CCM
select CRC32
select AVERAGE
---help---
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index be7614b9..ef808d7 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -2,6 +2,8 @@
* Copyright 2003-2004, Instant802 Networks, Inc.
* Copyright 2005-2006, Devicescape Software, Inc.
*
+ * Rewrite: Copyright (C) 2013 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
@@ -17,134 +19,77 @@
#include "key.h"
#include "aes_ccm.h"
-static void aes_ccm_prepare(struct crypto_cipher *tfm, u8 *scratch, u8 *a)
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ u8 *data, size_t data_len, u8 *cdata, u8 *mic)
{
- int i;
- u8 *b_0, *aad, *b, *s_0;
+ struct scatterlist assoc, pt, ct[2];
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
- aad = scratch + 4 * AES_BLOCK_SIZE;
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
+ /* allocate the variable sized aead_request on the stack */
+ int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
+ sizeof(struct aead_request));
+ struct aead_request req[1 + l];
- crypto_cipher_encrypt_one(tfm, b, b_0);
+ memset(req, 0, sizeof(*req) + crypto_aead_reqsize(tfm));
- /* Extra Authenticate-only data (always two AES blocks) */
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- aad[i] ^= b[i];
- crypto_cipher_encrypt_one(tfm, b, aad);
+ sg_init_one(&pt, data, data_len);
+ sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
+ sg_init_table(ct, 2);
+ sg_set_buf(&ct[0], cdata, data_len);
+ sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
- aad += AES_BLOCK_SIZE;
+ aead_request_set_tfm(req, tfm);
+ aead_request_set_crypt(req, &pt, ct, data_len, b_0);
+ aead_request_set_assoc(req, &assoc, assoc.length);
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- aad[i] ^= b[i];
- crypto_cipher_encrypt_one(tfm, a, aad);
+ crypto_aead_encrypt(req);
+}
- /* Mask out bits from auth-only-b_0 */
- b_0[0] &= 0x07;
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ u8 *cdata, size_t data_len, u8 *mic, u8 *data)
+{
+ struct scatterlist assoc, pt, ct[2];
- /* S_0 is used to encrypt T (= MIC) */
- b_0[14] = 0;
- b_0[15] = 0;
- crypto_cipher_encrypt_one(tfm, s_0, b_0);
-}
+ /* allocate the variable sized aead_request on the stack */
+ int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
+ sizeof(struct aead_request));
+ struct aead_request req[1 + l];
+ memset(req, 0, sizeof(*req) + crypto_aead_reqsize(tfm));
-void ieee80211_aes_ccm_encrypt(struct crypto_cipher *tfm, u8 *scratch,
- u8 *data, size_t data_len,
- u8 *cdata, u8 *mic)
-{
- int i, j, last_len, num_blocks;
- u8 *pos, *cpos, *b, *s_0, *e, *b_0;
-
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
- e = scratch + 2 * AES_BLOCK_SIZE;
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
-
- num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
- last_len = data_len % AES_BLOCK_SIZE;
- aes_ccm_prepare(tfm, scratch, b);
-
- /* Process payload blocks */
- pos = data;
- cpos = cdata;
- for (j = 1; j <= num_blocks; j++) {
- int blen = (j == num_blocks && last_len) ?
- last_len : AES_BLOCK_SIZE;
-
- /* Authentication followed by encryption */
- for (i = 0; i < blen; i++)
- b[i] ^= pos[i];
- crypto_cipher_encrypt_one(tfm, b, b);
-
- b_0[14] = (j >> 8) & 0xff;
- b_0[15] = j & 0xff;
- crypto_cipher_encrypt_one(tfm, e, b_0);
- for (i = 0; i < blen; i++)
- *cpos++ = *pos++ ^ e[i];
- }
-
- for (i = 0; i < IEEE80211_CCMP_MIC_LEN; i++)
- mic[i] = b[i] ^ s_0[i];
-}
+ sg_init_one(&pt, data, data_len);
+ sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
+ sg_init_table(ct, 2);
+ sg_set_buf(&ct[0], cdata, data_len);
+ sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
+ aead_request_set_tfm(req, tfm);
+ aead_request_set_crypt(req, ct, &pt, data_len + IEEE80211_CCMP_MIC_LEN,
+ b_0);
+ aead_request_set_assoc(req, &assoc, assoc.length);
-int ieee80211_aes_ccm_decrypt(struct crypto_cipher *tfm, u8 *scratch,
- u8 *cdata, size_t data_len, u8 *mic, u8 *data)
-{
- int i, j, last_len, num_blocks;
- u8 *pos, *cpos, *b, *s_0, *a, *b_0;
-
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
- a = scratch + 2 * AES_BLOCK_SIZE;
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
-
- num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
- last_len = data_len % AES_BLOCK_SIZE;
- aes_ccm_prepare(tfm, scratch, a);
-
- /* Process payload blocks */
- cpos = cdata;
- pos = data;
- for (j = 1; j <= num_blocks; j++) {
- int blen = (j == num_blocks && last_len) ?
- last_len : AES_BLOCK_SIZE;
-
- /* Decryption followed by authentication */
- b_0[14] = (j >> 8) & 0xff;
- b_0[15] = j & 0xff;
- crypto_cipher_encrypt_one(tfm, b, b_0);
- for (i = 0; i < blen; i++) {
- *pos = *cpos++ ^ b[i];
- a[i] ^= *pos++;
- }
- crypto_cipher_encrypt_one(tfm, a, a);
- }
-
- for (i = 0; i < IEEE80211_CCMP_MIC_LEN; i++) {
- if ((mic[i] ^ s_0[i]) != a[i])
- return -1;
- }
-
- return 0;
+ return crypto_aead_decrypt(req);
}
-
-struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[])
+struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[])
{
- struct crypto_cipher *tfm;
+ struct crypto_aead *tfm;
+ int err;
- tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
- if (!IS_ERR(tfm))
- crypto_cipher_setkey(tfm, key, WLAN_KEY_LEN_CCMP);
+ tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(tfm))
+ return tfm;
- return tfm;
-}
+ err = crypto_aead_setkey(tfm, key, WLAN_KEY_LEN_CCMP);
+ if (!err)
+ err = crypto_aead_setauthsize(tfm, IEEE80211_CCMP_MIC_LEN);
+ if (!err)
+ return tfm;
+ crypto_free_aead(tfm);
+ return ERR_PTR(err);
+}
-void ieee80211_aes_key_free(struct crypto_cipher *tfm)
+void ieee80211_aes_key_free(struct crypto_aead *tfm)
{
- crypto_free_cipher(tfm);
+ crypto_free_aead(tfm);
}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 5b7d744..52650b3 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -12,13 +12,13 @@
#include <linux/crypto.h>
-struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[]);
-void ieee80211_aes_ccm_encrypt(struct crypto_cipher *tfm, u8 *scratch,
+struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[]);
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
u8 *data, size_t data_len,
u8 *cdata, u8 *mic);
-int ieee80211_aes_ccm_decrypt(struct crypto_cipher *tfm, u8 *scratch,
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
u8 *cdata, size_t data_len,
u8 *mic, u8 *data);
-void ieee80211_aes_key_free(struct crypto_cipher *tfm);
+void ieee80211_aes_key_free(struct crypto_aead *tfm);
#endif /* AES_CCM_H */
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 036d57e..aaae0ed 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -83,7 +83,7 @@ struct ieee80211_key {
* Management frames.
*/
u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
- struct crypto_cipher *tfm;
+ struct crypto_aead *tfm;
u32 replays; /* dot11RSNAStatsCCMPReplays */
} ccmp;
struct {
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index c9edfcb..c39ee61 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -301,22 +301,16 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
}
-static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
+static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *b_0, u8 *aad,
int encrypted)
{
__le16 mask_fc;
int a4_included, mgmt;
u8 qos_tid;
- u8 *b_0, *aad;
u16 data_len, len_a;
unsigned int hdrlen;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- memset(scratch, 0, 6 * AES_BLOCK_SIZE);
-
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
- aad = scratch + 4 * AES_BLOCK_SIZE;
-
/*
* Mask FC: zero subtype b4 b5 b6 (if not mgmt)
* Retry, PwrMgt, MoreData; set Protected
@@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
data_len -= IEEE80211_CCMP_MIC_LEN;
/* First block, b_0 */
- b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
+ b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
/* Nonce: Nonce Flags | A2 | PN
* Nonce Flags: Priority (b0..b3) | Management (b4) | Reserved (b5..b7)
*/
@@ -407,7 +401,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 scratch[6 * AES_BLOCK_SIZE];
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -460,8 +455,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
return 0;
pos += IEEE80211_CCMP_HDR_LEN;
- ccmp_special_blocks(skb, pn, scratch, 0);
- ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, scratch, pos, len,
+ ccmp_special_blocks(skb, pn, b_0, aad, 0);
+ ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
pos, skb_put(skb, IEEE80211_CCMP_MIC_LEN));
return 0;
@@ -525,12 +520,13 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx)
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 scratch[6 * AES_BLOCK_SIZE];
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
/* hardware didn't decrypt/verify MIC */
- ccmp_special_blocks(skb, pn, scratch, 1);
+ ccmp_special_blocks(skb, pn, b_0, aad, 1);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, scratch,
+ key->u.ccmp.tfm, b_0, aad,
skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
data_len,
skb->data + skb->len - IEEE80211_CCMP_MIC_LEN,
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH v3 0/6] Add Mesh Channel Switch Support
From: Jean-Pierre Tosoni @ 2013-10-08 7:49 UTC (permalink / raw)
To: devel, linux-wireless, yeohchunyeow
In-Reply-To: <1380760429-26100-1-git-send-email-yeohchunyeow@cozybit.com>
Hi, see some typos below.
Jean-Pierre
> -----Message d'origine-----
> De : devel-bounces@lists.open80211s.org [mailto:devel-
> bounces@lists.open80211s.org] De la part de Chun-Yeow Yeoh
> Envoyé : jeudi 3 octobre 2013 02:34
>
> Limitations:
> * Channel switch is only allow for the same band and also same channel
> width from the previous setting.
Allow -> allowed
settings
>
> These patches are reviewed and commented by Bob Copeland, Thomas
> Pedersen
> and Johannes Berg. Any further comments are welcomed.
>
> Add seperate patch for refactoring the ieee80211_parse_ch_switch_ie to
Seperate -> separate
> reduce the number of function paramaters.
Parameters
>
> Chun-Yeow Yeoh (6):
> mac80211: process the CSA frame for mesh accordingly
> {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
> mac80211: add the CSA and MCSP elements in mesh beaconing
> mac80211: refactor the parsing of chan switch ie
> {nl,cfg,mac}80211: finalizing mesh channel switching
> mac80211: process mesh channel switching using beacon
>
> include/linux/ieee80211.h | 20 +++
> net/mac80211/Kconfig | 11 ++
> net/mac80211/cfg.c | 24 ++++
> net/mac80211/debug.h | 10 ++
> net/mac80211/ibss.c | 67 ++--------
> net/mac80211/ieee80211_i.h | 29 ++++-
> net/mac80211/mesh.c | 293
> +++++++++++++++++++++++++++++++++++++++++++-
> net/mac80211/mlme.c | 32 +++--
> net/mac80211/rx.c | 5 +-
> net/mac80211/spectmgmt.c | 33 +++--
> net/mac80211/tx.c | 16 +++
> net/mac80211/util.c | 96 +++++++++++++++
> net/wireless/nl80211.c | 4 +-
> 13 files changed, 540 insertions(+), 100 deletions(-)
>
> --
> 1.7.9.5
>
> _______________________________________________
> Devel mailing list
> Devel@lists.open80211s.org
> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-10-07
From: Johannes Berg @ 2013-10-08 10:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1381139793.13586.18.camel@jlt4.sipsolutions.net>
Please hold off on this,
> iwlwifi: mvm: Add device wide power command
This commit causes a regression in monitor mode.
johannes
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Stanislaw Gruszka @ 2013-10-08 10:47 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <20131007080201.GA18265@ns.kevlo.org>
On Mon, Oct 07, 2013 at 04:02:01PM +0800, Kevin Lo wrote:
> In rt2800_config_channel_rf3xxx(), there's no need to toggle
> RF R30 bit 7 twice.
>
> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
This one is fine.
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Stanislaw Gruszka @ 2013-10-08 10:46 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <525269F0.5000802@kevlo.org>
On Mon, Oct 07, 2013 at 03:59:44PM +0800, Kevin Lo wrote:
> rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
> rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET,
> rt2x00dev->freq_offset);
> rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);
NACK, still malformed
^ permalink raw reply
* Re: [PATCH] nl80211: vendor command support
From: Johannes Berg @ 2013-10-08 10:41 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEe+vVezWHBkOt_M4pfqCu--c78EuyMEmGD2oqcpP9=c-w@mail.gmail.com>
On Tue, 2013-10-08 at 12:34 +0200, Eliad Peller wrote:
> don't you miss the rdev->cur_cmd_info initialization in case of
> vendor_cmd (like it's being done in testmode)?
Indeed, I missed that. Need to test it anyway :)
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: vendor command support
From: Eliad Peller @ 2013-10-08 10:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1381222401-21999-1-git-send-email-johannes@sipsolutions.net>
On Tue, Oct 8, 2013 at 11:53 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Add support for vendor-specific commands to nl80211. This is
> intended to be used for really vendor-specific functionality
> that can't be implemented in a generic fashion for any reason.
> It's *NOT* intended to be used for any normal/generic feature
> or any optimisations that could be implemented across drivers.
>
> Currently, only vendor commands (with replies) are supported,
> no dump operations or vendor-specific notifications.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
[...]
>
> #ifdef CONFIG_NL80211_TESTMODE
> static struct genl_multicast_group nl80211_testmode_mcgrp = {
> @@ -6633,11 +6686,11 @@ static int nl80211_testmode_do(struct sk_buff *skb, struct genl_info *info)
> if (!info->attrs[NL80211_ATTR_TESTDATA])
> return -EINVAL;
>
> - rdev->testmode_info = info;
> + rdev->cur_cmd_info = info;
> err = rdev_testmode_cmd(rdev, wdev,
> nla_data(info->attrs[NL80211_ATTR_TESTDATA]),
> nla_len(info->attrs[NL80211_ATTR_TESTDATA]));
> - rdev->testmode_info = NULL;
> + rdev->cur_cmd_info = NULL;
>
> return err;
> }
[...]
> +
> +int cfg80211_vendor_cmd_reply(struct sk_buff *skb)
> +{
> + struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
> + void *hdr = ((void **)skb->cb)[1];
> + struct nlattr *data = ((void **)skb->cb)[2];
> +
> + if (WARN_ON(!rdev->cur_cmd_info)) {
> + kfree_skb(skb);
> + return -EINVAL;
> + }
> +
> + nla_nest_end(skb, data);
> + genlmsg_end(skb, hdr);
> + return genlmsg_reply(skb, rdev->cur_cmd_info);
> +}
don't you miss the rdev->cur_cmd_info initialization in case of
vendor_cmd (like it's being done in testmode)?
Eliad.
^ permalink raw reply
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