Re: brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT
Rafał Miłecki wrote: > From: Rafał Miłecki > > This new helper reads extra frequency limits specified in DT and > disables unavailable chanels. This is useful for devices (like home > routers) with chipsets limited e.g. by board design. > > In order to respect info read from DT we simply need to check for > IEEE80211_CHAN_DISABLED bit when constructing channel info. > > Signed-off-by: Rafał Miłecki Patch applied to wireless-drivers-next.git, thanks. 0f83ff697356 brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT -- https://patchwork.kernel.org/patch/9522069/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwifiex: don't include mac80211.h
Johannes Berg wrote: > From: Johannes Berg > > This driver doesn't use mac80211, so it shouldn't include mac80211.h, > include only the necessary cfg80211.h instead. > > Signed-off-by: Johannes Berg Patch applied to wireless-drivers-next.git, thanks. 50d55b6d3f1c mwifiex: don't include mac80211.h -- https://patchwork.kernel.org/patch/9498969/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: iwlwifi-next 2017-02-06
Luca Coelho writes: > Here's my second pull-request intended for v4.11. Just the usual set of > fixes, cleanups and improvements, together with the continued work on > support for new hardware. A bit more details in the tag description. > > I have sent this out before and kbuildbot didn't find any issues. I > have also removed my favorite mistakes, namely the "commit" after the > Fixes tag. ;) > > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit 36401cb7ffae731295a6dd1ce2b40d7ad74245f4: > > brcmfmac: be more verbose when PSM's watchdog fires (2017-02-02 08:14:26 > +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-next-for-kalle-2017-02-06 > > for you to fetch changes up to 8364fbb497f00de21d6d347194fa8b6bbae1d6f5: > > iwlwifi: mvm: support new beacon template command (2017-02-06 19:19:27 > +0200) > > > Second batch of improvements and fixes for v4.11. > > * A bunch of bugfixes for the DQA code; > * Work on support for new A000 devices continues; > * Some clean-ups and general improvements > > Pulled, thanks. -- Kalle Valo
Re: [PATCH 00/11 V4] rtlwifi: Various updates
Larry Finger writes: > These 11 changes fix a number of deficiencies. None of them are > serious enough to be pushed to stable; however they help in the > stability of the drivers, and in the robustness of authentication/ > association. > > This material should be sent to the 4.11 stream. > > Signed-off-by: Larry Finger > Cc: Ping-Ke Shih > --- > > V2 - Fix Kalle's comment about unended loops. It now runs a maximum of 200 > times. > V3 - Fix "WARNING: possible condition with no effect (if == else)" found by > Test Robot > V4 - No chenges -resubmitting as requested by Kalle. > --- > Larry Finger (1): > rtlwifi: btcoexist: Change logging in halbtc8192e2ant.c > > Ping-Ke Shih (10): > rtlwifi: Fix programing CAM content sequence. > rtlwifi: Set retry limit depends on vif type. > rtlwifi: Add a new enumeration value to btc_set_type > rtlwifi: btcoexist: Add vendor definition for new btcoexist > rtlwifi: rtl8723be: btcoexist: Add single_ant_path > rtlwifi: move btcoex's ant_num declaration > rtlwifi: rtl8723be: btcoex: add package_type function to btcoex > rtlwifi: btcoex: move bt_type declaration > rtlwifi: rtl8723be: fix ant_sel code > rtlwifi: Add work queue for c2h cmd. Thanks, as patchwork doesn't seem to detect this patchset I applied these manually: 1e75622c630b rtlwifi: Fix programing CAM content sequence. 8d0d43e34208 rtlwifi: Set retry limit depends on vif type. 6f85c03bc34c rtlwifi: Add a new enumeration value to btc_set_type 1a2814739fe5 rtlwifi: btcoexist: Add vendor definition for new btcoexist d46fa3e47aeb rtlwifi: btcoexist: Change logging in halbtc8192e2ant.c db8cb0095b0e rtlwifi: rtl8723be: btcoexist: Add single_ant_path 0de9b5db9fbf rtlwifi: move btcoex's ant_num declaration 7fe1fe75c311 rtlwifi: rtl8723be: btcoex: add package_type function to btcoex e0215c142026 rtlwifi: btcoex: move bt_type declaration 0ff78adeef11 rtlwifi: rtl8723be: fix ant_sel code cceb0a597320 rtlwifi: Add work queue for c2h cmd. -- Kalle Valo
Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.
Larry Finger writes: > On 02/06/2017 06:45 AM, Kalle Valo wrote: >> Larry Finger writes: >> >>> From: Ping-Ke Shih >>> >>> There is a potential race condition when the control byte of a CAM >>> entry is written first. Write in reverse order to correct the condition. >>> >>> Signed-off-by: Ping-Ke Shih >>> Signed-off-by: shaofu >>> Signed-off-by: Larry Finger >>> --- >>> V2 - no changes >>> V3 - no changes >> >> I missed in my reply to v2 that you had already sent v3 from this >> patchset. Strange that I don't see this v3 patchset either in patchwork, >> only v1. >> >> Try submitting v4 in case it was just a temporary glitch in patchwork. >> But if that doesn't help I'll apply these manually. > > I have no idea why my patches are not getting handled by patchwork, > but V4 is not there either. Yeah, that's odd. I do see your patches on the mailing list so I guess something in this set is breaking patchwork's email parser. The only notable difference I saw that in our patches the tags were in this format: [PATCH 01/11 V4] But normally we use something like this: [PATCH V4 01/11] I don't know if that would cause patchwork to fail and I don't really have time to investigate it right now. I'll just apply V4 manually now and let's hope that the problem doesn't reappear. -- Kalle Valo
Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.
On 02/06/2017 06:45 AM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih There is a potential race condition when the control byte of a CAM entry is written first. Write in reverse order to correct the condition. Signed-off-by: Ping-Ke Shih Signed-off-by: shaofu Signed-off-by: Larry Finger --- V2 - no changes V3 - no changes I missed in my reply to v2 that you had already sent v3 from this patchset. Strange that I don't see this v3 patchset either in patchwork, only v1. Try submitting v4 in case it was just a temporary glitch in patchwork. But if that doesn't help I'll apply these manually. I have no idea why my patches are not getting handled by patchwork, but V4 is not there either. Larry
[PATCH] Make EN2 pin optional in the TRF7970A driver
From: Guan Ben
Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.
Signed-off-by: Guan Ben
Signed-off-by: Mark Jonas
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++--
drivers/nfc/trf7970a.c | 26 --
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
- spi-max-frequency: Maximum SPI frequency (<= 200).
- interrupt-parent: phandle of parent interrupt handler.
- interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
- TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+ TRF7970A. EN2 is optional.
- vin-supply: Regulator for supply voltage to VIN pin
Optional SoC Specific Properties:
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..75079fb 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1885,8 +1885,10 @@ static int trf7970a_power_up(struct trf7970a *trf)
usleep_range(5000, 6000);
if (!(trf->quirks & TRF7970A_QUIRK_EN2_MUST_STAY_LOW)) {
- gpio_set_value(trf->en2_gpio, 1);
- usleep_range(1000, 2000);
+ if (gpio_is_valid(trf->en2_gpio)) {
+ gpio_set_value(trf->en2_gpio, 1);
+ usleep_range(1000, 2000);
+ }
}
gpio_set_value(trf->en_gpio, 1);
@@ -1914,7 +1916,8 @@ static int trf7970a_power_down(struct trf7970a *trf)
}
gpio_set_value(trf->en_gpio, 0);
- gpio_set_value(trf->en2_gpio, 0);
+ if (gpio_is_valid(trf->en2_gpio))
+ gpio_set_value(trf->en2_gpio, 0);
ret = regulator_disable(trf->regulator);
if (ret)
@@ -2032,15 +2035,14 @@ static int trf7970a_probe(struct spi_device *spi)
trf->en2_gpio = of_get_named_gpio(np, "ti,enable-gpios", 1);
if (!gpio_is_valid(trf->en2_gpio)) {
- dev_err(trf->dev, "No EN2 GPIO property\n");
- return trf->en2_gpio;
- }
-
- ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
- GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
- if (ret) {
- dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
- return ret;
+ dev_info(trf->dev, "No EN2 GPIO property\n");
+ } else {
+ ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
+ GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
+ if (ret) {
+ dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
+ return ret;
+ }
}
if (of_property_read_bool(np, "en2-rf-quirk"))
--
2.7.4
Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.
On 02/06/2017 06:45 AM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih There is a potential race condition when the control byte of a CAM entry is written first. Write in reverse order to correct the condition. Signed-off-by: Ping-Ke Shih Signed-off-by: shaofu Signed-off-by: Larry Finger --- V2 - no changes V3 - no changes I missed in my reply to v2 that you had already sent v3 from this patchset. Strange that I don't see this v3 patchset either in patchwork, only v1. Try submitting v4 in case it was just a temporary glitch in patchwork. But if that doesn't help I'll apply these manually. I have no idea why that patchsets are missing. I will send V4 shortly. Sorry I did not respond more quickly. I was out of my office today. Larry
Re: [PATCH] wireless-regdb: Remove DFS requirement for India (IN)
On Mon, Jan 30, 2017 at 02:08:32PM +0200, Jouni Malinen wrote: > The "Indoor Use of low power wireless equipment in the frequency band 5 > GHz (Exemption from Licensing Requirement) Rules, 2005" notification by > Ministry of Communications and Information Technology (Wireless Planning > and Coordination Wing) (New Delhi, the 28th January 2005) does not > mandate use of DFS, so remove the DFS flag from the 5250-5330 MHz band > in India. > > In addition, increase the TX power limit to 23 dBm to match the 200 mW > maximum mentioned in the same notification. Also use the exact ranges > from that notification and enable use of 160 MHz channels in the > 5150-5350 MHz band. > > Signed-off-by: Jouni Malinen Applied, thanks.
pull-request: iwlwifi-next 2017-02-06
Hi Kalle, Here's my second pull-request intended for v4.11. Just the usual set of fixes, cleanups and improvements, together with the continued work on support for new hardware. A bit more details in the tag description. I have sent this out before and kbuildbot didn't find any issues. I have also removed my favorite mistakes, namely the "commit" after the Fixes tag. ;) Please let me know if there are any issues. Cheers, Luca. The following changes since commit 36401cb7ffae731295a6dd1ce2b40d7ad74245f4: brcmfmac: be more verbose when PSM's watchdog fires (2017-02-02 08:14:26 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-02-06 for you to fetch changes up to 8364fbb497f00de21d6d347194fa8b6bbae1d6f5: iwlwifi: mvm: support new beacon template command (2017-02-06 19:19:27 +0200) Second batch of improvements and fixes for v4.11. * A bunch of bugfixes for the DQA code; * Work on support for new A000 devices continues; * Some clean-ups and general improvements Beni Lev (1): iwlwifi: mvm: Use aux queue for offchannel frames in dqa Emmanuel Grumbach (1): iwlwifi: mvm: fix PS-Poll enablement Golan Ben-Ami (1): iwlwifi: mvm: support v2 of mfuart load notification Johannes Berg (7): iwlwifi: mvm: reduce usage of IEEE80211_SKB_CB() iwlwifi: mvm: fix D3 replay counter value iwlwifi: mvm: set AID to firmware only for associated stations iwlwifi: mvm: overwrite skb info later iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe iwlwifi: mvm: align copy-break SKB payload for MQ RX iwlwifi: pcie: fix another RF-kill race Liad Kaufman (1): iwlwifi: mvm: release static queues on bcast release Luca Coelho (2): iwlwifi: remove unnecessary argument to iwl_drv_start() iwlwifi: remove unnecessary cfg element in iwl_drv Sara Sharon (12): iwlwifi: mvm: support unification of INIT and RT images iwlwifi: mvm: cleanup incorrect and redundant define iwlwifi: mvm: support new statistics APIs iwlwifi: mvm: support new scan API iwlwifi: mvm: always free inactive queue when moving ownership iwlwifi: mvm: support new alive notification iwlwifi: mvm: synchronize firmware DMA paging memory iwlwifi: pcie: fix the set of DMA memory mask iwlwifi: mvm: fix pending frame counter calculation iwlwifi: mvm: cleanup iwl_mvm_tx_mpdu a bit iwlwifi: support two phys for a000 devices iwlwifi: mvm: support new beacon template command drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 30 +-- drivers/net/wireless/intel/iwlwifi/iwl-config.h | 3 +- drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 25 +++--- drivers/net/wireless/intel/iwlwifi/iwl-drv.h | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-mac.h | 7 +- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-scan.h | 106 +++--- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-stats.h | 29 +- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h| 29 +- drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 90 +++ drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 4 + drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 354 ++--- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 105 -- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 24 + drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +++- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 24 - drivers/net/wireless/intel/iwlwifi/mvm/power.c| 44 - drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 70 +++ drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 11 ++- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 230 +-- drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 227 ++- drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 1 + drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 112 +-- drivers/net/wireless/intel/iwlwifi/mvm/utils.c| 16 ++-- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 17 ++-- drivers/net/wireless/intel/iwlwifi/pcie/internal.h| 2 + drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 8 +- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 23 - 30 files changed, 1035 insertions(+),
Re: [PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches
From: Linus Lüssing Date: Fri, 3 Feb 2017 08:11:03 +0100 > When for instance a mobile Linux device roams from one access point to > another with both APs sharing the same broadcast domain and a > multicast snooping switch in between: > > 1)(c) <~~~> (AP1) <--[SSW]--> (AP2) > > 2) (AP1) <--[SSW]--> (AP2) <~~~> (c) > > Then currently IPv6 multicast packets will get lost for (c) until an > MLD Querier sends its next query message. The packet loss occurs > because upon roaming the Linux host so far stayed silent regarding > MLD and the snooping switch will therefore be unaware of the > multicast topology change for a while. > > This patch fixes this by always resending MLD reports when an interface > change happens, for instance from NO-CARRIER to CARRIER state. > > Signed-off-by: Linus Lüssing Looks good to me, applied, thanks.
Re: pull-request: wireless-drivers 2017-02-06
From: Kalle Valo Date: Mon, 06 Feb 2017 17:19:52 +0200 > one more fix I still would like to get to 4.10 if possible. Please let > me know if there are any problems. This is fine, pulled, thanks Kalle.
MODULE_FIRMWARE() for fallback ucode files?
Hi, currently iwlwifi driver lists only the latest firmware files in MODULE_FIRMWARE() although the driver may read other older files. And this confuses the openSUSE installer, since the installation image is created based on the module information and copies only the firmwares listed there. A bug report is found at: https://bugzilla.suse.com/show_bug.cgi?id=1021082 Would it be better to list up all firmware files? Or how can we inform user-space which firmware files would be possibly loaded? In anyway, the current situation is messy. The driver declares the firmware files that don't exist in the common linux-firmware git tree. If we list up only the latest API version, we should guarantee that these files are landed in the official tree before upstreaming. thanks, Takashi
Re: pull-request: mac80211 2017-02-06
From: Johannes Berg Date: Mon, 6 Feb 2017 09:36:36 +0100 > I know it's super late, but I was travelling last week and the > whole FILS AEAD thing only played out over the weekend anyway. > Since the FILS code is all new in this cycle, it'd be good to > have the fixes, and the others are a bit older but still would > be good to fix sooner rather than later, I think. > > Please pull and let me know if there's any problem. Ok, pulled, thanks Johannes.
Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
On 02/06/2017 04:29 AM, Johannes Berg wrote: On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: Seems the problem is caused by rtl92c_dm_*() casting .priv to "struct rtl_pci_priv", while it is "struct rtl_usb_priv". Those routines are shared by rtl8192ce and rtl8192cu, thus we need to make that difference in cast to be immaterial. I think we need to move "struct bt_coexist_info" to the beginning of both rtlpci_priv and rtl_usb_priv. Then it should not matter. I think you really should consider putting a struct rtl_common into that or something, and getting rid of all the casting that causes this problem to start with? The fix you suggest is prepared and will be submitted soon. As it is much more invasive with ~150 insertions and ~160 deletions, I decided not to have it be the one that is pushed to all stable kernels from 4.0 onward. Larry
pull-request: wireless-drivers 2017-02-06
Hi Dave, one more fix I still would like to get to 4.10 if possible. Please let me know if there are any problems. Kalle The following changes since commit 2b1d530cb3157f828fcaadd259613f59db3c6d1c: MAINTAINERS: ath9k-devel is closed (2017-01-28 09:15:50 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-02-06 for you to fetch changes up to 52f5631a4c056ad01682393be56d2be237e81610: rtlwifi: rtl8192ce: Fix loading of incorrect firmware (2017-01-31 09:05:25 +0200) wireless-drivers fixes for 4.10 Only one important fix for rtlwifi which fixes a regression introduced in 4.9 and which caused problems for many users. Jurij Smakov (1): rtlwifi: rtl8192ce: Fix loading of incorrect firmware drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-)
Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
> You use value '0' to mean set to default values, as far as I can > tell. I think you're confusing the internal API and the userspace API - at a userspace level you have to set NL80211_ATTR_STA_TX_POWER_SETTING to NL80211_TX_POWER_AUTOMATIC to revert back to defaults, no? For perfect backwards compatibility we should ignore it if not supported, but that doesn't really make sense - I think we should reject it and handle errors elsewhere in the not supported case. johannes
Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe
On Mon, 2017-02-06 at 16:05 +0200, Kalle Valo wrote:
> Luca Coelho writes:
>
> > From: Johannes Berg
> >
> > Instead of setting the tx_cmd length in the mvm code, which is
> > complicated by the fact that DQA may want to temporarily store
> > the SKB on the side, adjust the length in the PCIe code which
> > also knows about this since it's responsible for duplicating
> > all those headers that are account for in this code.
> >
> > As the PCIe code already relies on the tx_cmd->len field, this
> > doesn't really introduce any new dependencies.
> >
> > To make this possible we need to move the memcpy() of the TX
> > command until after it was updated.
> >
> > This does even simplify the code though, since the PCIe code
> > already does a lot of manipulations to build A-MSDUs correctly
> > and changing the length becomes a simple operation to see how
> > much was added/removed, rather than predicting it.
> >
> > Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic
> > alloc/dealloc of queues")
>
> Ditto.
Oh no! I copied this from another commit, that's why... I'll fix these
two.
And sorry for the trouble (again!)
--
Luca.
Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe
Luca Coelho writes:
> From: Johannes Berg
>
> Instead of setting the tx_cmd length in the mvm code, which is
> complicated by the fact that DQA may want to temporarily store
> the SKB on the side, adjust the length in the PCIe code which
> also knows about this since it's responsible for duplicating
> all those headers that are account for in this code.
>
> As the PCIe code already relies on the tx_cmd->len field, this
> doesn't really introduce any new dependencies.
>
> To make this possible we need to move the memcpy() of the TX
> command until after it was updated.
>
> This does even simplify the code though, since the PCIe code
> already does a lot of manipulations to build A-MSDUs correctly
> and changing the length becomes a simple operation to see how
> much was added/removed, rather than predicting it.
>
> Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc
> of queues")
Ditto.
--
Kalle Valo
Re: [PATCH 14/25] iwlwifi: mvm: overwrite skb info later
Luca Coelho writes:
> From: Johannes Berg
>
> We don't really need clear the skb's status area nor store the
> dev_cmd into it until we really commit to the frame by handing
> it to the transport - defer those operations until just before
> we do that.
>
> This doesn't entirely fix the bug with frames not getting sent
> out after having been deferred due to DQA, because it doesn't
> restore the info->driver_data[0] place that was already set to
> zero (or another value) by the A-MSDU logic.
>
> Fixes: commit 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc
> of queues")
s/commit // :)
--
Kalle Valo
[PATCH] Print text for disassociation reason.
Hi. Don't know why it wasn't printed there with ieee80211_get_reason_code_string in first place. Works for me: kernel: wlan0: disassociated from 04:b0:20:33:ff:1f (Reason: 34=DISASSOC_LOW_ACK) ps. can't send patch in normal way due to postmaster@vger weirdness, so inserted below From c9b55bb44fe0b902f376a41fa930c9a67a438511 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= Date: Mon, 6 Feb 2017 14:45:15 +0100 Subject: [PATCH] Print text for disassociation reason. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When disassociation happens only numeric reason is printed in ieee80211_rx_mgmt_disassoc(). Add text variant, too. Signed-off-by: Arkadiusz Miśkiewicz --- net/mac80211/mlme.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 098ce9b179ee..fcf8d0aa66ec 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2801,8 +2801,9 @@ static void ieee80211_rx_mgmt_disassoc(struct ieee80211_sub_if_data *sdata, reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code); - sdata_info(sdata, "disassociated from %pM (Reason: %u)\n", - mgmt->sa, reason_code); + sdata_info(sdata, "disassociated from %pM (Reason: %u=%s)\n", + mgmt->sa, reason_code, + ieee80211_get_reason_code_string(reason_code)); ieee80211_set_disassoc(sdata, 0, 0, false, NULL); -- 2.11.0 -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
On Mon, Feb 06, 2017 at 12:52:56PM +0100, Felix Fietkau wrote:
> >> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
> >> +{
> >> + u8 ackto, sifs, slottime = dev->slottime;
> >> +
> >> + slottime += 3 * dev->coverage_class;
> >> +
> >> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
> >> +MT_XIFS_TIME_CFG_OFDM_SIFS);
> >> +
> >> + ackto = slottime + sifs;
> >> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
> >> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
> >> +}
> > Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
> > we will also need this in rt2x00. Vendor drivers use 32 for this setting
> > and do not change it.
> I don't think vendor drivers even have support for coverage class.
Even not supporting coverage class (default is 0 anyway) this results
on different setting depending on slot time and sifs. My understanding
is that this is correct approach, compared to constant value used by
vendor.
> >> +static u32
> >> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
> >> +{
> >> + u32 val = 0;
> >> +
> >> + val |= (v1 & (BIT(6) - 1)) << 0;
> >> + val |= (v2 & (BIT(6) - 1)) << 8;
> >> + val |= (v3 & (BIT(6) - 1)) << 16;
> >> + val |= (v4 & (BIT(6) - 1)) << 24;
> >> + return val;
> >> +}
> > TX_PWR_CFG registers consist of eight 4bit entries, masking
> > two entries with 0x3f does not seems to be correct.
> No, these registers consist of four 6bit entries. Both the vendor driver
> and the datasheet describe them this way.
That different compared to old devices. I assumed those registers would
not change meaning in MT76, but I guess I was wrong.
> >> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band,
> >> u8 bw)
> >> +{
> >> + u32 cfg0, cfg1;
> >> +
> >> + if (mt76x2_ext_pa_enabled(dev, band)) {
> >> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
> >> + cfg1 = 0x00011414;
> >> + } else {
> >> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
> >> + cfg1 = 0x00021414;
> >> + }
> >> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
> >> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
> >> +
> >> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
> >> + 13 + (bw ? 1 : 0));
> >> +}
> > SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
> > or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
> > we have some internal delays configured on TX_SW_CFG registers.
> This is a CCK-only SIFS value (there's a separate one for OFDM).
CCK can be used only on 5GHz? OFDM only on 2GHz? I thought any rates can
be used on both bands. Or maybe this settings is just named wrongly
i.e. CCK_SIFS mean sifs for 5GHz and OFDM_SIFS - sifs for 2GHz ?
Stanislaw
ANNOUNCE: Netdev 2.1 update Feb 06
A few announcements: - We expect to open up registration and announce hotel and location this week. - We are pleased to announce the first netdev 2.1 sponsor! Many thanks to Mellanox who has been a strong supporter of the netdev community. Mellanox is first to cross the netdev2.1 sponsor line with a silver. The Call for Proposals is still open, submit early to avoid the hazards of last minute traffic. Refer to: http://netdevconf.org/2.1/submit-proposal.html cheers, jamal
Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.
Larry Finger writes: > From: Ping-Ke Shih > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: shaofu > Signed-off-by: Larry Finger > --- > V2 - no changes > V3 - no changes I missed in my reply to v2 that you had already sent v3 from this patchset. Strange that I don't see this v3 patchset either in patchwork, only v1. Try submitting v4 in case it was just a temporary glitch in patchwork. But if that doesn't help I'll apply these manually. -- Kalle Valo
Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
Symmetry is still broken on firmware crash (at least with 6174).
ath10k_pci_hif_stop gets called twice, once from the driver restart (warm
restart) and once from ieee80211 start (cold restart), resulting in
napi_synchrionize/napi_disable getting called twice and sticking the driver in
an infinite wait loop (napi_synchronize waits until NAPI_STATE_SCHED is off,
while napi_disable leaves NAPI_STATE_SCHED to on when leaving).
> On Feb 6, 2017, at 5:04 AM, Mohammed Shafi Shajakhan
> wrote:
>
> Hi Kalle,
>
> the change suggested by you helps, and the device probe, scan
> is successful as well. Still good to have this change part of your
> basic sanity and regression testing !
>
> regards,
> shafi
>
> On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote:
>> Kalle Valo writes:
>>
>>> Mohammed Shafi Shajakhan writes:
>>>
From: Mohammed Shafi Shajakhan
This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails by calling 'ath10k_hif_stop'. Its good to note
that the error is never propogated to 'ath10k_pci_probe' when
ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
PCI related things seems to be ok
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
Call Trace:
[] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[] ? __wake_up_common+0x4d/0x80
[] ? cpu_load_update+0xdc/0x150
[] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[] net_rx_action+0x20f/0x370
Reported-by: Ben Greear
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan
>>>
>>> Is there an easy way to reproduce this bug? I don't see it on my x86
>>> laptop with qca988x and I call rmmod all the time. I would like to test
>>> this myself.
>>>
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
ath10k_core_free_firmware_files(ar);
err_power_down:
+ ath10k_hif_stop(ar);
ath10k_hif_power_down(ar);
return ret;
>>>
>>> This breaks the symmetry, we should not be calling ath10k_hif_stop() if
>>> we haven't called ath10k_hif_start() from the same function. This can
>>> just create a bigger mess later, for example with other bus support like
>>> sdio or usb. In theory it should enough that we call
>>> ath10k_hif_power_down() and pci.c does the rest correctly "behind the
>>> scenes".
>>>
>>> I investigated this a bit and I think the real cause is that we call
>>> napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
>>> ath10k_pci_hif_stop(). Does anyone remember why?
>>>
>>> I was expecting that we would call napi_enable()/napi_disable() either
>>> in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
>>> mixed like it's currently.
>>
>> So below is something I was thinking of, now napi_enable() is called
>> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
>> that work?
>>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>>
>> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>>
>> +napi_enable(&ar->napi);
>> +
>> ath10k_pci_irq_enable(ar);
>> ath10k_pci_rx_post(ar);
>>
>> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
>> goto err_ce;
>> }
>> -napi_enable(&ar->napi);
>>
>> return 0;
>>
>> --
>> Kalle Valo
>
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
Hi,
even with the below patch applied ?
https://patchwork.kernel.org/patch/9452265/
regards
shafi
From: Michael Ney
Sent: 06 February 2017 17:46
To: Mohammed Shafi Shajakhan
Cc: Valo, Kalle; linux-wireless@vger.kernel.org; ath...@lists.infradead.org;
Shajakhan, Mohammed Shafi (Mohammed Shafi)
Subject: Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
Symmetry is still broken on firmware crash (at least with 6174).
ath10k_pci_hif_stop gets called twice, once from the driver restart (warm
restart) and once from ieee80211 start (cold restart), resulting in
napi_synchrionize/napi_disable getting called twice and sticking the driver in
an infinite wait loop (napi_synchronize waits until NAPI_STATE_SCHED is off,
while napi_disable leaves NAPI_STATE_SCHED to on when leaving).
> On Feb 6, 2017, at 5:04 AM, Mohammed Shafi Shajakhan
> wrote:
>
> Hi Kalle,
>
> the change suggested by you helps, and the device probe, scan
> is successful as well. Still good to have this change part of your
> basic sanity and regression testing !
>
> regards,
> shafi
>
> On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote:
>> Kalle Valo writes:
>>
>>> Mohammed Shafi Shajakhan writes:
>>>
From: Mohammed Shafi Shajakhan
This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails by calling 'ath10k_hif_stop'. Its good to note
that the error is never propogated to 'ath10k_pci_probe' when
ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
PCI related things seems to be ok
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
Call Trace:
[] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[] ? __wake_up_common+0x4d/0x80
[] ? cpu_load_update+0xdc/0x150
[] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[] net_rx_action+0x20f/0x370
Reported-by: Ben Greear
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan
>>>
>>> Is there an easy way to reproduce this bug? I don't see it on my x86
>>> laptop with qca988x and I call rmmod all the time. I would like to test
>>> this myself.
>>>
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
ath10k_core_free_firmware_files(ar);
err_power_down:
+ ath10k_hif_stop(ar);
ath10k_hif_power_down(ar);
return ret;
>>>
>>> This breaks the symmetry, we should not be calling ath10k_hif_stop() if
>>> we haven't called ath10k_hif_start() from the same function. This can
>>> just create a bigger mess later, for example with other bus support like
>>> sdio or usb. In theory it should enough that we call
>>> ath10k_hif_power_down() and pci.c does the rest correctly "behind the
>>> scenes".
>>>
>>> I investigated this a bit and I think the real cause is that we call
>>> napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
>>> ath10k_pci_hif_stop(). Does anyone remember why?
>>>
>>> I was expecting that we would call napi_enable()/napi_disable() either
>>> in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
>>> mixed like it's currently.
>>
>> So below is something I was thinking of, now napi_enable() is called
>> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
>> that work?
>>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>>
>> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>>
>> +napi_enable(&ar->napi);
>> +
>> ath10k_pci_irq_enable(ar);
>> ath10k_pci_rx_post(ar);
>>
>> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
>> goto err_ce;
>> }
>> -napi_enable(&ar->napi);
>>
>> return 0;
>>
>> --
>> Kalle Valo
>
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
On 2017-02-06 12:25, Stanislaw Gruszka wrote:
> On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau
> Driver looks great to me, though I think it could be better commented.
> I have some minor issues, but if they need to be fixed, it could be done
> by incremental patches after apply this one to the tree.
>
> Reviewed-by: Stanislaw Gruszka
Thanks for the review.
>> +enum dma_msg_port {
>> +WLAN_PORT,
>> +CPU_RX_PORT,
>> +CPU_TX_PORT,
>> +HOST_PORT,
>> +VIRTUAL_CPU_RX_PORT,
>> +VIRTUAL_CPU_TX_PORT,
>> +DISCARD,
>> +};
> Not used ?
Yeah, I guess it can be removed.
>> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
>> +{
>> +u8 ackto, sifs, slottime = dev->slottime;
>> +
>> +slottime += 3 * dev->coverage_class;
>> +
>> +sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
>> + MT_XIFS_TIME_CFG_OFDM_SIFS);
>> +
>> +ackto = slottime + sifs;
>> +mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
>> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
>> +}
> Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
> we will also need this in rt2x00. Vendor drivers use 32 for this setting
> and do not change it.
I don't think vendor drivers even have support for coverage class.
> Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
> with default settings, but perhaps should be changed depending on
> channel properties as well.
>
>> +static u32
>> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
>> +{
>> +u32 val = 0;
>> +
>> +val |= (v1 & (BIT(6) - 1)) << 0;
>> +val |= (v2 & (BIT(6) - 1)) << 8;
>> +val |= (v3 & (BIT(6) - 1)) << 16;
>> +val |= (v4 & (BIT(6) - 1)) << 24;
>> +return val;
>> +}
> TX_PWR_CFG registers consist of eight 4bit entries, masking
> two entries with 0x3f does not seems to be correct.
No, these registers consist of four 6bit entries. Both the vendor driver
and the datasheet describe them this way.
>> +mt76_wr(dev, MT_TX_PWR_CFG_3,
>> +mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
>> +mt76_wr(dev, MT_TX_PWR_CFG_4,
>> +mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
>> +mt76_wr(dev, MT_TX_PWR_CFG_7,
>> +mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
>> +mt76_wr(dev, MT_TX_PWR_CFG_8,
>> +mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
>> +mt76_wr(dev, MT_TX_PWR_CFG_9,
>> +mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
> Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
> for example t.vht[6] is never used.
There are not enough register fields for all rates individually, so they
overlap. This looks a bit confusing and random, but I did check it
carefully against the vendor driver and the datasheet.
>> +static void
>> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band,
>> u8 bw)
>> +{
>> +u32 cfg0, cfg1;
>> +
>> +if (mt76x2_ext_pa_enabled(dev, band)) {
>> +cfg0 = bw ? 0x000b0c01 : 0x00101101;
>> +cfg1 = 0x00011414;
>> +} else {
>> +cfg0 = bw ? 0x000b0b01 : 0x00101001;
>> +cfg1 = 0x00021414;
>> +}
>> +mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
>> +mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
>> +
>> +mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
>> + 13 + (bw ? 1 : 0));
>> +}
> SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
> or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
> we have some internal delays configured on TX_SW_CFG registers.
This is a CCK-only SIFS value (there's a separate one for OFDM).
> But again this is interesting for rt2x00, where we stay with
> defaults, but looks we should configure XIFS_TIME_CFG based on
> channel.
I think many of these might be mt76x2 specific tweaks, so be careful
with applying any of that to rt2x00.
>> +if (chandef->width >= NL80211_CHAN_WIDTH_40)
>> +sifs++;
>> +
>> +mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
> This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
> mt76x2_configure_tx_delay().
Will look into that.
>> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
>> +{
>> +int len = ieee80211_get_hdrlen_from_skb(skb);
>> +int ret;
>> +
>> +if (len % 4 == 0)
>> +return 0;
>> +
>> +if (skb_headroom(skb) < 2) {
>> +ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
>> +if (ret != 0)
>> +return ret;
> This should not be needed if hw->extra_tx_headroom is set properly.
Thanks, will send a follow-up cleanup patch if this one is accepted.
>> +if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
>> +qsel = 0;
> For better understating: qsel = MT_QSEL_MGMT;
Right.
>> +void mt76x2_p
Re: [PATCH 01/11 V2] rtlwifi: Fix programing CAM content sequence.
Larry Finger writes: > From: Ping-Ke Shih > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: shaofu > Signed-off-by: Larry Finger > --- > V2 - no changes Weird, I don't see any of the v2 patches in patchwork: https://patchwork.kernel.org/project/linux-wireless/list/?state=*&page=1 I do see other recent patches from you Larry, but not this set. Can you resubmit, please? -- Kalle Valo
Submitted patches for 4.11 NOW
Hi, Linus is hinting that he might release the final 4.10 next Sunday. So if you want have patches with new features in 4.11 better post them NOW to not the miss the merge window. -- Kalle Valo
Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau
Driver looks great to me, though I think it could be better commented.
I have some minor issues, but if they need to be fixed, it could be done
by incremental patches after apply this one to the tree.
Reviewed-by: Stanislaw Gruszka
> +enum dma_msg_port {
> + WLAN_PORT,
> + CPU_RX_PORT,
> + CPU_TX_PORT,
> + HOST_PORT,
> + VIRTUAL_CPU_RX_PORT,
> + VIRTUAL_CPU_TX_PORT,
> + DISCARD,
> +};
Not used ?
> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
> +{
> + u8 ackto, sifs, slottime = dev->slottime;
> +
> + slottime += 3 * dev->coverage_class;
> +
> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
> + MT_XIFS_TIME_CFG_OFDM_SIFS);
> +
> + ackto = slottime + sifs;
> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
> +MT_TX_TIMEOUT_CFG_ACKTO, ackto);
> +}
Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
we will also need this in rt2x00. Vendor drivers use 32 for this setting
and do not change it.
Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
with default settings, but perhaps should be changed depending on
channel properties as well.
> +static u32
> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
> +{
> + u32 val = 0;
> +
> + val |= (v1 & (BIT(6) - 1)) << 0;
> + val |= (v2 & (BIT(6) - 1)) << 8;
> + val |= (v3 & (BIT(6) - 1)) << 16;
> + val |= (v4 & (BIT(6) - 1)) << 24;
> + return val;
> +}
TX_PWR_CFG registers consist of eight 4bit entries, masking
two entries with 0x3f does not seems to be correct.
> + mt76_wr(dev, MT_TX_PWR_CFG_3,
> + mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
> + mt76_wr(dev, MT_TX_PWR_CFG_4,
> + mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_7,
> + mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
> + mt76_wr(dev, MT_TX_PWR_CFG_8,
> + mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_9,
> + mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
for example t.vht[6] is never used.
> +static void
> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8
> bw)
> +{
> + u32 cfg0, cfg1;
> +
> + if (mt76x2_ext_pa_enabled(dev, band)) {
> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
> + cfg1 = 0x00011414;
> + } else {
> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
> + cfg1 = 0x00021414;
> + }
> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
> +13 + (bw ? 1 : 0));
> +}
SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
we have some internal delays configured on TX_SW_CFG registers.
But again this is interesting for rt2x00, where we stay with
defaults, but looks we should configure XIFS_TIME_CFG based on
channel.
> + if (chandef->width >= NL80211_CHAN_WIDTH_40)
> + sifs++;
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
mt76x2_configure_tx_delay().
> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
> +{
> + int len = ieee80211_get_hdrlen_from_skb(skb);
> + int ret;
> +
> + if (len % 4 == 0)
> + return 0;
> +
> + if (skb_headroom(skb) < 2) {
> + ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
> + if (ret != 0)
> + return ret;
This should not be needed if hw->extra_tx_headroom is set properly.
> + if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
> + qsel = 0;
For better understating: qsel = MT_QSEL_MGMT;
> +void mt76x2_pre_tbtt_tasklet(unsigned long arg)
> +{
> + struct mt76x2_dev *dev = (struct mt76x2_dev *) arg;
> + struct mt76_queue *q = &dev->mt76.q_tx[MT_TXQ_PSD];
> + struct beacon_bc_data data = {};
> + struct sk_buff *skb;
> + int i, nframes;
> +
> + data.dev = dev;
> + __skb_queue_head_init(&data.q);
> +
> + ieee80211_iterate_active_interfaces_atomic(mt76_hw(dev),
This symbol, not like most of other mac80211 symbols, is exported via
EXPORT_SYMBOL_GPL(), so I'm not sure if it can be used on dual licensed
file, perhaps licence of this file should be changed to GPL only.
Stanislaw
[PATCH v3 0/2] mac80211: use crypto shash for AES cmac
This is something I spotted while working on AES in various modes for ARM and arm64. The mac80211 aes_cmac code reimplements the CMAC algorithm based on the core AES cipher, which is rather restrictive in how platforms can satisfy the dependency on this algorithm. For instance, SIMD implementations may have a considerable setup time, which cannot be amortized over the entire input when calling into the crypto API one block at a time. Also, it prevents the use of more secure fixed time implementations, since not all AES drivers expose the cipher interface. So switch aes_cmac to use a cmac(aes) shash. Before updating the aes_cmac code in patch #2, the FILS AEAD code is moved to using a cmac(aes) shash supplied by the crypto API so that we can remove the open coded version entirely in the second patch. v3: - use more idiomatic SHASH_DESC_ON_STACK to allocate the shash descriptors - replace compound literal zero vectors with explicitly defined ones - drop a redundant memcpy() in #2 Ard Biesheuvel (2): mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher mac80211: aes-cmac: switch to shash CMAC driver net/mac80211/Kconfig | 1 + net/mac80211/aes_cmac.c | 126 net/mac80211/aes_cmac.h | 15 +-- net/mac80211/fils_aead.c | 74 +--- net/mac80211/key.h | 2 +- 5 files changed, 66 insertions(+), 152 deletions(-) -- 2.7.4
[PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver
Instead of open coding the CMAC algorithm in the mac80211 driver using
byte wide xors and calls into the crypto layer for each block of data,
instantiate a cmac(aes) synchronous hash and pass all the data into it
directly. This does not only simplify the code, it also allows the use
of more efficient and more secure implementations, especially on
platforms where SIMD ciphers have a considerable setup cost.
Signed-off-by: Ard Biesheuvel
---
net/mac80211/aes_cmac.c | 126
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2 +-
3 files changed, 32 insertions(+), 107 deletions(-)
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index d0bd5fff5f0a..2fb65588490c 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -22,126 +22,50 @@
#define CMAC_TLEN_256 16 /* CMAC TLen = 128 bits (16 octets) */
#define AAD_LEN 20
+static const u8 zero[CMAC_TLEN_256];
-void gf_mulx(u8 *pad)
-{
- int i, carry;
-
- carry = pad[0] & 0x80;
- for (i = 0; i < AES_BLOCK_SIZE - 1; i++)
- pad[i] = (pad[i] << 1) | (pad[i + 1] >> 7);
- pad[AES_BLOCK_SIZE - 1] <<= 1;
- if (carry)
- pad[AES_BLOCK_SIZE - 1] ^= 0x87;
-}
-
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
-const u8 *addr[], const size_t *len, u8 *mac,
-size_t mac_len)
-{
- u8 cbc[AES_BLOCK_SIZE], pad[AES_BLOCK_SIZE];
- const u8 *pos, *end;
- size_t i, e, left, total_len;
-
- memset(cbc, 0, AES_BLOCK_SIZE);
-
- total_len = 0;
- for (e = 0; e < num_elem; e++)
- total_len += len[e];
- left = total_len;
-
- e = 0;
- pos = addr[0];
- end = pos + len[0];
-
- while (left >= AES_BLOCK_SIZE) {
- for (i = 0; i < AES_BLOCK_SIZE; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- if (left > AES_BLOCK_SIZE)
- crypto_cipher_encrypt_one(tfm, cbc, cbc);
- left -= AES_BLOCK_SIZE;
- }
-
- memset(pad, 0, AES_BLOCK_SIZE);
- crypto_cipher_encrypt_one(tfm, pad, pad);
- gf_mulx(pad);
-
- if (left || total_len == 0) {
- for (i = 0; i < left; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- cbc[left] ^= 0x80;
- gf_mulx(pad);
- }
-
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- pad[i] ^= cbc[i];
- crypto_cipher_encrypt_one(tfm, pad, pad);
- memcpy(mac, pad, mac_len);
-}
-
-
-void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN];
+ SHASH_DESC_ON_STACK(desc, tfm);
+ u8 out[AES_BLOCK_SIZE];
- memset(zero, 0, CMAC_TLEN);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN;
- addr[2] = zero;
- len[2] = CMAC_TLEN;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN);
+ crypto_shash_finup(desc, zero, CMAC_TLEN, out);
+
+ memcpy(mic, out, CMAC_TLEN);
}
-void ieee80211_aes_cmac_256(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN_256];
+ SHASH_DESC_ON_STACK(desc, tfm);
- memset(zero, 0, CMAC_TLEN_256);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN_256;
- addr[2] = zero;
- len[2] = CMAC_TLEN_256;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN_256);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN_256);
+ crypto_shash_finup(desc, zero, CMAC_TLEN_256, mic);
}
-struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
- size_t key_len)
+struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
+ size_t key_
[PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the
crypto API rather than reusing the open coded implementation in
aes_cmac_vector(). This makes the code more understandable, and allows
platforms to implement cmac(aes) in a more secure (*) and efficient way
than is typically possible when using the AES cipher directly.
So replace the crypto_cipher by a crypto_shash, and update the aes_s2v()
routine to call the shash interface directly.
* In particular, the generic table based AES implementation is sensitive
to known-plaintext timing attacks on the key, to which AES based MAC
algorithms are especially vulnerable, given that their plaintext is not
usually secret. Time invariant alternatives are available (e.g., based
on SIMD algorithms), but may incur a setup cost that is prohibitive when
operating on a single block at a time, which is why they don't usually
expose the cipher API.
Signed-off-by: Ard Biesheuvel
---
net/mac80211/Kconfig | 1 +
net/mac80211/aes_cmac.h | 4 --
net/mac80211/fils_aead.c | 74 +---
3 files changed, 34 insertions(+), 45 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 3891cbd2adea..76e30f4797fb 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -6,6 +6,7 @@ config MAC80211
select CRYPTO_AES
select CRYPTO_CCM
select CRYPTO_GCM
+ select CRYPTO_CMAC
select CRC32
---help---
This option enables the hardware independent IEEE 802.11
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index c827e1d5de8b..3702041f44fd 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -11,10 +11,6 @@
#include
-void gf_mulx(u8 *pad);
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
-const u8 *addr[], const size_t *len, u8 *mac,
-size_t mac_len);
struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
size_t key_len);
void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index 5c3af5eb4052..3cfb1e2ab7ac 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -9,66 +9,58 @@
#include
#include
+#include
#include
#include "ieee80211_i.h"
#include "aes_cmac.h"
#include "fils_aead.h"
-static int aes_s2v(struct crypto_cipher *tfm,
+static void gf_mulx(u8 *pad)
+{
+ u64 a = get_unaligned_be64(pad);
+ u64 b = get_unaligned_be64(pad + 8);
+
+ put_unaligned_be64((a << 1) | (b >> 63), pad);
+ put_unaligned_be64((b << 1) ^ ((a >> 63) ? 0x87 : 0), pad + 8);
+}
+
+static int aes_s2v(struct crypto_shash *tfm,
size_t num_elem, const u8 *addr[], size_t len[], u8 *v)
{
- u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
+ u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
+ SHASH_DESC_ON_STACK(desc, tfm);
size_t i;
- const u8 *data[2];
- size_t data_len[2], data_elems;
+
+ desc->tfm = tfm;
/* D = AES-CMAC(K, ) */
- memset(tmp, 0, AES_BLOCK_SIZE);
- data[0] = tmp;
- data_len[0] = AES_BLOCK_SIZE;
- aes_cmac_vector(tfm, 1, data, data_len, d, AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
for (i = 0; i < num_elem - 1; i++) {
/* D = dbl(D) xor AES_CMAC(K, Si) */
gf_mulx(d); /* dbl */
- aes_cmac_vector(tfm, 1, &addr[i], &len[i], tmp,
- AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, addr[i], len[i], tmp);
crypto_xor(d, tmp, AES_BLOCK_SIZE);
}
+ crypto_shash_init(desc);
+
if (len[i] >= AES_BLOCK_SIZE) {
/* len(Sn) >= 128 */
- size_t j;
- const u8 *pos;
-
/* T = Sn xorend D */
-
- /* Use a temporary buffer to perform xorend on Sn (addr[i]) to
-* avoid modifying the const input argument.
-*/
- data[0] = addr[i];
- data_len[0] = len[i] - AES_BLOCK_SIZE;
- pos = addr[i] + data_len[0];
- for (j = 0; j < AES_BLOCK_SIZE; j++)
- tmp[j] = pos[j] ^ d[j];
- data[1] = tmp;
- data_len[1] = AES_BLOCK_SIZE;
- data_elems = 2;
+ crypto_shash_update(desc, addr[i], len[i] - AES_BLOCK_SIZE);
+ crypto_xor(d, addr[i] + len[i] - AES_BLOCK_SIZE,
+ AES_BLOCK_SIZE);
} else {
/* len(Sn) < 128 */
/* T = dbl(D) xor pad(Sn) */
gf_mulx(d); /* dbl */
- memset(tmp, 0, AES_BLOCK_SIZE);
- memcpy(tmp, addr[i], len[i]);
- tmp[len[i]] = 0x80;
- crypto_xor(d, tmp, AES_BLOCK_SIZE);
- data[0
Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: > On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: > > Seems the problem is caused by rtl92c_dm_*() casting .priv to > > "struct > > rtl_pci_priv", while it is "struct rtl_usb_priv". > > Those routines are shared by rtl8192ce and rtl8192cu, thus we need to > make that > difference in cast to be immaterial. I think we need to move "struct > bt_coexist_info" to the beginning of both rtlpci_priv and > rtl_usb_priv. Then it > should not matter. I think you really should consider putting a struct rtl_common into that or something, and getting rid of all the casting that causes this problem to start with? johannes
Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac
On 6 February 2017 at 10:01, Malinen, Jouni wrote: > On Sun, Feb 05, 2017 at 03:23:26PM +, Ard Biesheuvel wrote: >> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is >> working. >> I have not tested patch #1 myself, mainly because the test methodology >> requires downloading Ubuntu installer images, and I am currently on a >> metered 3G connection (and will be for another couple of weeks) > > These v2 patches pass the test cases as well. > Thanks! > (And you don't really need Ubuntu to run the hwsim test cases; any > reasonably recent distribution that is capable of running kvm should > work.) > Well, now that you have done my testing for me, I am not sure I will get around to trying the VM. Thanks, Ard.
Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
Hi Kalle,
the change suggested by you helps, and the device probe, scan
is successful as well. Still good to have this change part of your
basic sanity and regression testing !
regards,
shafi
On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote:
> Kalle Valo writes:
>
> > Mohammed Shafi Shajakhan writes:
> >
> >> From: Mohammed Shafi Shajakhan
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [] ? __wake_up_common+0x4d/0x80
> >> [] ? cpu_load_update+0xdc/0x150
> >> [] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >>ath10k_core_free_firmware_files(ar);
> >>
> >> err_power_down:
> >> + ath10k_hif_stop(ar);
> >>ath10k_hif_power_down(ar);
> >>
> >>return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
>
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
>
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>
> + napi_enable(&ar->napi);
> +
> ath10k_pci_irq_enable(ar);
> ath10k_pci_rx_post(ar);
>
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
> goto err_ce;
> }
> - napi_enable(&ar->napi);
>
> return 0;
>
> --
> Kalle Valo
Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac
On Sun, Feb 05, 2017 at 03:23:26PM +, Ard Biesheuvel wrote: > NOTE: Jouni has been so kind to test patch #2, and confirmed that it is > working. > I have not tested patch #1 myself, mainly because the test methodology > requires downloading Ubuntu installer images, and I am currently on a > metered 3G connection (and will be for another couple of weeks) These v2 patches pass the test cases as well. (And you don't really need Ubuntu to run the hwsim test cases; any reasonably recent distribution that is capable of running kvm should work.) -- Jouni MalinenPGP id EFC895FA
Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata
On Mon, 16 Jan 2017 17:28:18 +0100
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
>
> This allows cleaning up struct bcma_sflash from unneeded fields.
>
> Signed-off-by: Rafał Miłecki
Acked-by: Boris Brezillon
> ---
> Kalle: This is mtd focused patch, so I guess it should go through mtd tree. Do
>you find bcma change important enough to care to Ack it? :)
> ---
> drivers/mtd/devices/bcm47xxsflash.c | 6 +++---
> include/linux/bcma/bcma_driver_chipcommon.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/devices/bcm47xxsflash.c
> b/drivers/mtd/devices/bcm47xxsflash.c
> index 514be04..4decd8c 100644
> --- a/drivers/mtd/devices/bcm47xxsflash.c
> +++ b/drivers/mtd/devices/bcm47xxsflash.c
> @@ -284,7 +284,6 @@ static int bcm47xxsflash_bcma_probe(struct
> platform_device *pdev)
> b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
> if (!b47s)
> return -ENOMEM;
> - sflash->priv = b47s;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -334,6 +333,8 @@ static int bcm47xxsflash_bcma_probe(struct
> platform_device *pdev)
> b47s->size = sflash->size;
> bcm47xxsflash_fill_mtd(b47s, &pdev->dev);
>
> + platform_set_drvdata(pdev, b47s);
> +
> err = mtd_device_parse_register(&b47s->mtd, probes, NULL, NULL, 0);
> if (err) {
> pr_err("Failed to register MTD device: %d\n", err);
> @@ -349,8 +350,7 @@ static int bcm47xxsflash_bcma_probe(struct
> platform_device *pdev)
>
> static int bcm47xxsflash_bcma_remove(struct platform_device *pdev)
> {
> - struct bcma_sflash *sflash = dev_get_platdata(&pdev->dev);
> - struct bcm47xxsflash *b47s = sflash->priv;
> + struct bcm47xxsflash *b47s = platform_get_drvdata(pdev);
>
> mtd_device_unregister(&b47s->mtd);
> iounmap(b47s->window);
> diff --git a/include/linux/bcma/bcma_driver_chipcommon.h
> b/include/linux/bcma/bcma_driver_chipcommon.h
> index b20e3d5..2f1c690 100644
> --- a/include/linux/bcma/bcma_driver_chipcommon.h
> +++ b/include/linux/bcma/bcma_driver_chipcommon.h
> @@ -593,9 +593,6 @@ struct bcma_sflash {
> u32 blocksize;
> u16 numblocks;
> u32 size;
> -
> - struct mtd_info *mtd;
> - void *priv;
> };
> #endif
>
Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
On 6 February 2017 at 08:47, Johannes Berg wrote:
>
>> {
>> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
>> + struct shash_desc *desc;
>> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
>> CRYPTO_MINALIGN_ATTR;
I realised we have a more idiomatic SHASH_DESC_ON_STACK for this.
>> size_t i;
>> - const u8 *data[2];
>> - size_t data_len[2], data_elems;
>> +
>> + desc = (struct shash_desc *)buf;
>> + desc->tfm = tfm;
>>
>> + crypto_shash_digest(desc, (u8[AES_BLOCK_SIZE]){},
>> AES_BLOCK_SIZE, d);
>
> That's an interesting expression in there. Can we name it into a real
> variable? :)
>
Sure, if you prefer.
> I'm also slightly worried about stack usage now - do we know none of
> this goes into an sg list eventually?
>
Shashes do not usually use scatterlists: the shash API does not use
them, but uses u8[] arrays and lengths everywhere, and shashes are
explicitly synchronous, which means they are unsuitable for being
exposed on top of a high latency peripheral that uses DMA.
Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
> The type and mask are used as follows when checking an algorithm: > > alg->type & mask == type & mask > > So to request a synchronous algorithm (that is, one with the > CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and > mask to CRYPTO_ALG_ASYNC. Ah. Ok, that makes sense, thanks for the explanation. johannes
Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
On Mon, Feb 06, 2017 at 07:54:37AM +0100, Johannes Berg wrote:
> Hi,
>
> > The skcipher could have been of the async variant which may return
> > from skcipher_encrypt() with -EINPROGRESS after having queued the
> > request.
> > The FILS AEAD implementation here does not have code for dealing with
> > that possibility, so allocate a sync cipher explicitly to avoid
> > potential issues with hardware accelerators.
>
> > - tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
> > + tfm2 = crypto_alloc_skcipher("ctr(aes)", 0,
> > CRYPTO_ALG_ASYNC);
>
> I'll apply this, after having found some code elsewhere that does
> something similar, but I'll note that this is super confusing, since
> the only documentation mentioning this flag says:
>
> The mask flag restricts the type of cipher. The only allowed flag is
> CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
> asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
The type and mask are used as follows when checking an algorithm:
alg->type & mask == type & mask
So to request a synchronous algorithm (that is, one with the
CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and
mask to CRYPTO_ALG_ASYNC.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
> {
> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> + struct shash_desc *desc;
> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
> CRYPTO_MINALIGN_ATTR;
> size_t i;
> - const u8 *data[2];
> - size_t data_len[2], data_elems;
> +
> + desc = (struct shash_desc *)buf;
> + desc->tfm = tfm;
>
> + crypto_shash_digest(desc, (u8[AES_BLOCK_SIZE]){},
> AES_BLOCK_SIZE, d);
That's an interesting expression in there. Can we name it into a real
variable? :)
I'm also slightly worried about stack usage now - do we know none of
this goes into an sg list eventually?
johannes
pull-request: mac80211 2017-02-06
Hi Dave, I know it's super late, but I was travelling last week and the whole FILS AEAD thing only played out over the weekend anyway. Since the FILS code is all new in this cycle, it'd be good to have the fixes, and the others are a bit older but still would be good to fix sooner rather than later, I think. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756: ip6_gre: fix ip6gre_err() invalid reads (2017-02-05 17:23:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-02-06 for you to fetch changes up to fd551bac4795854adaa87bad7e5136083719802b: nl80211: Fix mesh HT operation check (2017-02-06 07:59:07 +0100) A few simple fixes: * fix FILS AEAD cipher usage to use the correct AAD vectors and to use synchronous algorithms * fix using mesh HT operation data from userspace * fix adding mesh vendor elements to beacons & plink frames Jouni Malinen (2): mac80211: Fix FILS AEAD protection in Association Request frame mac80211: Allocate a sync skcipher explicitly for FILS AEAD Masashi Honma (1): nl80211: Fix mesh HT operation check Thorsten Horstmann (1): mac80211: Fix adding of mesh vendor IEs net/mac80211/fils_aead.c | 6 +++--- net/mac80211/mesh.c | 2 +- net/wireless/nl80211.c | 1 + 3 files changed, 5 insertions(+), 4 deletions(-)
