[PATCH 5/6] brcmfmac: add support for dma indices feature

2015-05-20 Thread Arend van Spriel 
From: Franky Lin fran...@broadcom.com

PCIe full dongle firmware can support a dma indices feature with which
firmware can update/fetch the read/write indices of message buffer
rings on both host to dongle and dongle to host directions. The support is
announced by firmware through shared flags.

Reviewed-by: Arend Van Spriel ar...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Signed-off-by: Franky Lin fran...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 140 +
 1 file changed, 119 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 2bc24a4..37a2624 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -115,6 +115,8 @@ enum brcmf_pcie_state {
 #define BRCMF_PCIE_MIN_SHARED_VERSION  5
 #define BRCMF_PCIE_MAX_SHARED_VERSION  5
 #define BRCMF_PCIE_SHARED_VERSION_MASK 0x00FF
+#define BRCMF_PCIE_SHARED_DMA_INDEX0x1
+#define BRCMF_PCIE_SHARED_DMA_2B_IDX   0x10
 
 #define BRCMF_PCIE_FLAGS_HTOD_SPLIT0x4000
 #define BRCMF_PCIE_FLAGS_DTOH_SPLIT0x8000
@@ -146,6 +148,10 @@ enum brcmf_pcie_state {
 #define BRCMF_SHARED_RING_H2D_R_IDX_PTR_OFFSET 8
 #define BRCMF_SHARED_RING_D2H_W_IDX_PTR_OFFSET 12
 #define BRCMF_SHARED_RING_D2H_R_IDX_PTR_OFFSET 16
+#define BRCMF_SHARED_RING_H2D_WP_HADDR_OFFSET  20
+#define BRCMF_SHARED_RING_H2D_RP_HADDR_OFFSET  28
+#define BRCMF_SHARED_RING_D2H_WP_HADDR_OFFSET  36
+#define BRCMF_SHARED_RING_D2H_RP_HADDR_OFFSET  44
 #define BRCMF_SHARED_RING_TCM_MEMLOC_OFFSET0
 #define BRCMF_SHARED_RING_MAX_SUB_QUEUES   52
 
@@ -247,6 +253,13 @@ struct brcmf_pciedev_info {
bool mbdata_completed;
bool irq_allocated;
bool wowl_enabled;
+   u8 dma_idx_sz;
+   void *idxbuf;
+   u32 idxbuf_sz;
+   dma_addr_t idxbuf_dmahandle;
+   u16 (*read_ptr)(struct brcmf_pciedev_info *devinfo, u32 mem_offset);
+   void (*write_ptr)(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
+ u16 value);
 };
 
 struct brcmf_pcie_ringbuf {
@@ -323,6 +336,25 @@ brcmf_pcie_write_tcm16(struct brcmf_pciedev_info *devinfo, 
u32 mem_offset,
 }
 
 
+static u16
+brcmf_pcie_read_idx(struct brcmf_pciedev_info *devinfo, u32 mem_offset)
+{
+   u16 *address = devinfo-idxbuf + mem_offset;
+
+   return (*(address));
+}
+
+
+static void
+brcmf_pcie_write_idx(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
+u16 value)
+{
+   u16 *address = devinfo-idxbuf + mem_offset;
+
+   *(address) = value;
+}
+
+
 static u32
 brcmf_pcie_read_tcm32(struct brcmf_pciedev_info *devinfo, u32 mem_offset)
 {
@@ -868,7 +900,7 @@ static int brcmf_pcie_ring_mb_write_rptr(void *ctx)
brcmf_dbg(PCIE, W r_ptr %d (%d), ring %d\n, commonring-r_ptr,
  commonring-w_ptr, ring-id);
 
-   brcmf_pcie_write_tcm16(devinfo, ring-r_idx_addr, commonring-r_ptr);
+   devinfo-write_ptr(devinfo, ring-r_idx_addr, commonring-r_ptr);
 
return 0;
 }
@@ -886,7 +918,7 @@ static int brcmf_pcie_ring_mb_write_wptr(void *ctx)
brcmf_dbg(PCIE, W w_ptr %d (%d), ring %d\n, commonring-w_ptr,
  commonring-r_ptr, ring-id);
 
-   brcmf_pcie_write_tcm16(devinfo, ring-w_idx_addr, commonring-w_ptr);
+   devinfo-write_ptr(devinfo, ring-w_idx_addr, commonring-w_ptr);
 
return 0;
 }
@@ -915,7 +947,7 @@ static int brcmf_pcie_ring_mb_update_rptr(void *ctx)
if (devinfo-state != BRCMFMAC_PCIE_STATE_UP)
return -EIO;
 
-   commonring-r_ptr = brcmf_pcie_read_tcm16(devinfo, ring-r_idx_addr);
+   commonring-r_ptr = devinfo-read_ptr(devinfo, ring-r_idx_addr);
 
brcmf_dbg(PCIE, R r_ptr %d (%d), ring %d\n, commonring-r_ptr,
  commonring-w_ptr, ring-id);
@@ -933,7 +965,7 @@ static int brcmf_pcie_ring_mb_update_wptr(void *ctx)
if (devinfo-state != BRCMFMAC_PCIE_STATE_UP)
return -EIO;
 
-   commonring-w_ptr = brcmf_pcie_read_tcm16(devinfo, ring-w_idx_addr);
+   commonring-w_ptr = devinfo-read_ptr(devinfo, ring-w_idx_addr);
 
brcmf_dbg(PCIE, R w_ptr %d (%d), ring %d\n, commonring-w_ptr,
  commonring-r_ptr, ring-id);
@@ -1038,6 +1070,13 @@ static void brcmf_pcie_release_ringbuffers(struct 
brcmf_pciedev_info *devinfo)
}
kfree(devinfo-shared.flowrings);
devinfo-shared.flowrings = NULL;
+   if (devinfo-idxbuf) {
+   dma_free_coherent(devinfo-pdev-dev,
+ devinfo-idxbuf_sz,
+ devinfo-idxbuf,
+ devinfo-idxbuf_dmahandle);
+   devinfo-idxbuf = NULL;
+   }
 }
 
 
@@ -1053,19 +1092,72 @@ static int brcmf_pcie_init_ringbuffers(struct

[PATCH 0/6] brcmfmac: PCIe changes and NVRAM support

2015-05-20 Thread Arend van Spriel 
This series for the brcmfmac driver provides:

* cleanup and new feature support in PCIe code.
* alternative nvram loading for router support.

The series is intended for v4.2 kernel and apply to the master
branch of the wireless-drivers-next repository.

Arend van Spriel (1):
  brcmfmac: allow device tree node without 'interrupts' property

Franky Lin (3):
  brcmfmac: remove pci shared structure rev4 support
  brcmfmac: remove dummy cache flush/invalidate function
  brcmfmac: add support for dma indices feature

Hante Meuleman (2):
  brcmfmac: Improve throughput by scheduling msbug flow worker.
  brcmfmac: Add support for host platform NVRAM loading.

 .../net/wireless/brcm80211/brcmfmac/commonring.c   |  18 ---
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 107 +-
 drivers/net/wireless/brcm80211/brcmfmac/flowring.c |   5 +-
 drivers/net/wireless/brcm80211/brcmfmac/flowring.h |   4 +-
 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c   |  20 +--
 drivers/net/wireless/brcm80211/brcmfmac/of.c   |  11 +-
 drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 157 -
 7 files changed, 209 insertions(+), 113 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND] mips: bcm47xx: allow retrieval of complete nvram contents

2015-05-20 Thread Arend van Spriel 
From: Hante Meuleman meule...@broadcom.com

Host platforms such as routers supported by OpenWRT can
support NVRAM reading directly from internal NVRAM store.
The brcmfmac for one requires the complete nvram contents
to select what needs to be sent to wireless device.

Reviewed-by: Arend Van Spriel ar...@broadcom.com
Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
Reviewed-by: Daniel (Deognyoun) Kim de...@broadcom.com
Signed-off-by: Hante Meuleman meule...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
Made a typo so it did not go the the linux-mips mailing list. Sorry for
the noise.

Regards,
Arend
---
 arch/mips/bcm47xx/nvram.c | 40 +---
 include/linux/bcm47xx_nvram.h | 15 +++
 2 files changed, 48 insertions(+), 7 deletions(-)

diff --git a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c
index ba632ff..3bb7f41 100644
--- a/arch/mips/bcm47xx/nvram.c
+++ b/arch/mips/bcm47xx/nvram.c
@@ -138,6 +138,7 @@ static int nvram_init(void)
 #ifdef CONFIG_MTD
struct mtd_info *mtd;
struct nvram_header header;
+   struct nvram_header *pheader;
size_t bytes_read;
int err;
 
@@ -146,20 +147,21 @@ static int nvram_init(void)
return -ENODEV;
 
err = mtd_read(mtd, 0, sizeof(header), bytes_read, (uint8_t *)header);
-   if (!err  header.magic == NVRAM_MAGIC) {
-   u8 *dst = (uint8_t *)nvram_buf;
-   size_t len = header.len;
-
-   if (header.len  NVRAM_SPACE) {
+   if (!err  header.magic == NVRAM_MAGIC 
+   header.len  sizeof(header)) {
+   if (header.len  NVRAM_SPACE - 2) {
pr_err(nvram on flash (%i bytes) is bigger than the 
reserved space in memory, will just copy the first %i bytes\n,
header.len, NVRAM_SPACE);
-   len = NVRAM_SPACE;
+   header.len = NVRAM_SPACE - 2;
}
 
-   err = mtd_read(mtd, 0, len, bytes_read, dst);
+   err = mtd_read(mtd, 0, header.len, bytes_read,
+  (u8 *)nvram_buf);
if (err)
return err;
 
+   pheader = (struct nvram_header *)nvram_buf;
+   pheader-len = header.len;
return 0;
}
 #endif
@@ -221,3 +223,27 @@ int bcm47xx_nvram_gpio_pin(const char *name)
return -ENOENT;
 }
 EXPORT_SYMBOL(bcm47xx_nvram_gpio_pin);
+
+char *bcm47xx_nvram_get_contents(size_t *nvram_size)
+{
+   int err;
+   char *nvram;
+   struct nvram_header *header;
+
+   if (!nvram_buf[0]) {
+   err = nvram_init();
+   if (err)
+   return NULL;
+   }
+
+   header = (struct nvram_header *)nvram_buf;
+   *nvram_size = header-len - sizeof(struct nvram_header);
+   nvram = vmalloc(*nvram_size);
+   if (!nvram)
+   return NULL;
+   memcpy(nvram, nvram_buf[sizeof(struct nvram_header)], *nvram_size);
+
+   return nvram;
+}
+EXPORT_SYMBOL(bcm47xx_nvram_get_contents);
+
diff --git a/include/linux/bcm47xx_nvram.h b/include/linux/bcm47xx_nvram.h
index b12b07e..c73927c 100644
--- a/include/linux/bcm47xx_nvram.h
+++ b/include/linux/bcm47xx_nvram.h
@@ -10,11 +10,17 @@
 
 #include linux/types.h
 #include linux/kernel.h
+#include linux/vmalloc.h
 
 #ifdef CONFIG_BCM47XX
 int bcm47xx_nvram_init_from_mem(u32 base, u32 lim);
 int bcm47xx_nvram_getenv(const char *name, char *val, size_t val_len);
 int bcm47xx_nvram_gpio_pin(const char *name);
+char *bcm47xx_nvram_get_contents(size_t *val_len);
+static inline void bcm47xx_nvram_release_contents(char *nvram)
+{
+   vfree(nvram);
+};
 #else
 static inline int bcm47xx_nvram_init_from_mem(u32 base, u32 lim)
 {
@@ -29,6 +35,15 @@ static inline int bcm47xx_nvram_gpio_pin(const char *name)
 {
return -ENOTSUPP;
 };
+
+static inline char *bcm47xx_nvram_get_contents(size_t *val_len)
+{
+   return NULL;
+};
+
+static inline void bcm47xx_nvram_release_contents(char *nvram)
+{
+};
 #endif
 
 #endif /* __BCM47XX_NVRAM_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH] Added 2 new Control Frames ( Beamforming Report Poll VHT NDP Announcement) defined in 802.11ac [EDT]

2015-05-20 Thread Rahul Jain 
EP-FEDC771DF4FF48A9829CB85254E29FD3

Dear Johannes,

As per your request, I have updated the commit message.
This patch is first step towards further changes to be done related to 802.11ac 
new frames.

From 69340d63e0c63c1ae75cdb62bf4bd04a9c961a1f Mon Sep 17 00:00:00 2001  

 
From: rahul
Date: Thu, 14 May 2015 10:21:48 +0530   
   
Subject: [PATCH] Added 2 new Control Frames ( Beamforming Report Poll  VHT 
   
NDP Announcement) defined in 802.11ac.  
  

   
Beamforming Report Poll frame - This frame is used to retrieve additional   
   
feedback from the second and subsequent beamformees. The beamformer must use
   
the Beamforming Report Poll frame. In Beamforming Report Poll, the Feedback 
   
Segment Retransmission Bitmap field indicates the requested feedback segments   
of a VHT Compressed Beamforming report. 
   

   
VHT Null Data Packet (NDP) Announcement - This frame is used by Beamformers to  
gain control of the channel and identiy beformees. Beamformees will respond to  
the NDP Announcement, while all other stations will simply defer channel access 
until the sounding sequence is complete 
   
--- 
   
include/linux/ieee80211.h |2 ++ 
  
1 file changed, 2 insertions(+) 
  

   
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h  
   
index b9c7897..ca38616 100644   
   
--- a/include/linux/ieee80211.h 
   
+++ b/include/linux/ieee80211.h 
   
@@ -75,6 +75,8 @@   
   
#define IEEE80211_STYPE_ACTION 0x00D0   
  

   
/* control */   
  
+#define IEEE80211_STYPE_BEAMFORM_POLL  0x0040  
   
+#define IEEE80211_STYPE_VHT_NDP_ANNOUCE0x0050  
   
#define IEEE80211_STYPE_CTL_EXT0x0060   
  
#define IEEE80211_STYPE_BACK_REQ   0x0080   
  
#define IEEE80211_STYPE_BACK   0x0090   
  
--  
   
1.7.9.5   


Thanks
-Rahul Jain 



--- Original Message ---
Sender : Johannes Berg
Date : May 19, 2015 12:58 (GMT+05:30)
Title : Re: [PATCH] Added 2 new Control Frames ( Beamforming Report Poll  VHT 
NDP Announcement) defined in 802.11ac

On Thu, 2015-05-14 at 05:02 +, Rahul Jain wrote:
 hello All,
 
 Below is the patch for 2 new control frames defined in 802.11ac.
 Please review and merge.
 
 From b9ca335040547e565684f5bf60d37db896322663 Mon Sep 17 00:00:00 2001
   
   

 From: rahul 
 Date: Thu, 14 May 2015 10:21:48 +0530
 Subject: [PATCH] Added 2 new Control Frames ( Beamforming Report Poll  VHT 
  NDP Announcement) defined in 802.11ac

As long as nobody is using these, I don't see much reason to merge this.

Also, a much better commit log would be needed.

johannes 
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

[PATCH] brcmfmac: simplify check finding NVRAM v1 device path

2015-05-20 Thread Rafał Miłecki 
With a simple use of snprintf and small buffer we can compare NVRAM
entry value with a full string. This way we avoid checking random chars
at magic offsets.
Tested on BCM43602 with NVRAM hacked to use v1 format.

Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 181a0e8..0d02e31 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
@@ -222,6 +222,10 @@ static int brcmf_init_nvram_parser(struct nvram_parser 
*nvp,
 static void brcmf_fw_strip_multi_v1(struct nvram_parser *nvp, u16 domain_nr,
u16 bus_nr)
 {
+   /* Device path with a leading '=' key-value separator */
+   char pcie_path[] = =pcie/?/?;
+   size_t pcie_len;
+
u32 i, j;
bool found;
u8 *nvram;
@@ -238,6 +242,9 @@ static void brcmf_fw_strip_multi_v1(struct nvram_parser 
*nvp, u16 domain_nr,
/* First search for the devpathX and see if it is the configuration
 * for domain_nr/bus_nr. Search complete nvp
 */
+   snprintf(pcie_path, sizeof(pcie_path), =pcie/%d/%d, domain_nr,
+bus_nr);
+   pcie_len = strlen(pcie_path);
found = false;
i = 0;
while (i  nvp-nvram_len - BRCMF_FW_NVRAM_DEVPATH_LEN) {
@@ -245,13 +252,10 @@ static void brcmf_fw_strip_multi_v1(struct nvram_parser 
*nvp, u16 domain_nr,
 * Y = domain_nr, Z = bus_nr, X = virtual ID
 */
if ((strncmp(nvp-nvram[i], devpath, 7) == 0) 
-   (strncmp(nvp-nvram[i + 8], =pcie/, 6) == 0)) {
-   if (((nvp-nvram[i + 14] - '0') == domain_nr) 
-   ((nvp-nvram[i + 16] - '0') == bus_nr)) {
-   id = nvp-nvram[i + 7] - '0';
-   found = true;
-   break;
-   }
+   (strncmp(nvp-nvram[i + 8], pcie_path, pcie_len) == 0)) {
+   id = nvp-nvram[i + 7] - '0';
+   found = true;
+   break;
}
while (nvp-nvram[i] != 0)
i++;
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: rfkill: Switch to PM ops

2015-05-20 Thread Johannes Berg 
On Sat, 2015-05-16 at 14:23 +0200, Lars-Peter Clausen wrote:
 Use dev_pm_ops instead of the legacy suspend/resume callbacks for the
 rfkill class suspend and resume operations.

Applied.

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: check fast-xmit on station change

2015-05-20 Thread Johannes Berg 
On Tue, 2015-05-19 at 14:13 +0200, Michal Kazior wrote:
 Drivers with fast-xmit (e.g. ath10k) running in
 AP_VLAN setups would fail to communicate with
 connected 4addr stations.
 
 The reason was when new station associates it
 first goes into master AP interface. It is not
 until later that a dedicated AP_VLAN is created
 for it and the station itself is moved there.
 After that Tx directed at the station should use
 4addr header. However fast-xmit wasn't
 recalculated and 3addr header remained to be used.
 This in turn caused the connected 4addr stations
 to drop packets coming from the AP until some
 other event would cause fast-xmit to recalculate
 for that station (which could never come).

Applied.

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] mac80211: prevent possible crypto tx tailroom corruption

2015-05-20 Thread Johannes Berg 
On Wed, 2015-05-13 at 09:16 +, Michal Kazior wrote:
 There was a possible race between
 ieee80211_reconfig() and
 ieee80211_delayed_tailroom_dec(). This could
 result in inability to transmit data if driver
 crashed during roaming or rekeying and subsequent
 skbs with insufficient tailroom appeared.
 
 This race was probably never seen in the wild
 because a device driver would have to crash AND
 recover within 0.5s which is very unlikely.
 
 I was able to prove this race exists after
 changing the delay to 10s locally and crashing
 ath10k via debugfs immediately after GTK
 rekeying. In case of ath10k the counter went below
 0. This was harmless but other drivers which
 actually require tailroom (e.g. for WEP ICV or
 MMIC) could end up with the counter at 0 instead
 of 0 and introduce insufficient skb tailroom
 failures because mac80211 would not resize skbs
 appropriately anymore.
 
 Fixes: 8d1f7ecd2af5 (mac80211: defer tailroom counter manipulation when 
 roaming)
 Signed-off-by: Michal Kazior michal.kaz...@tieto.com
 ---
 
 Notes:
 While doing PATCH v2 [1/2] I've noticed a subtle bug in the
 delayed tailroom counter logic. Since this touches the
 codepaths [1/2] does I'm posting this as a pair.
 
  net/mac80211/key.c  | 5 -
  net/mac80211/main.c | 3 +++
  2 files changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/net/mac80211/key.c b/net/mac80211/key.c
 index 577a11a13cdf..4c6f8c97d11a 100644
 --- a/net/mac80211/key.c
 +++ b/net/mac80211/key.c
 @@ -695,10 +695,13 @@ void ieee80211_reset_crypto_tx_tailroom(struct 
 ieee80211_sub_if_data *sdata)
   mutex_lock(sdata-local-key_mtx);
  
   sdata-crypto_tx_tailroom_needed_cnt = 0;
 + sdata-crypto_tx_tailroom_pending_dec = 0;
  
   if (sdata-vif.type == NL80211_IFTYPE_AP) {
 - list_for_each_entry(vlan, sdata-u.ap.vlans, u.vlan.list)
 + list_for_each_entry(vlan, sdata-u.ap.vlans, u.vlan.list) {
   vlan-crypto_tx_tailroom_needed_cnt = 0;
 + vlan-crypto_tx_tailroom_pending_dec = 0;
 + }
   }
  
   mutex_unlock(sdata-local-key_mtx);
 diff --git a/net/mac80211/main.c b/net/mac80211/main.c
 index 3c956c5f99b2..d8e1cbdcbc43 100644
 --- a/net/mac80211/main.c
 +++ b/net/mac80211/main.c
 @@ -246,6 +246,7 @@ static void ieee80211_restart_work(struct work_struct 
 *work)
  {
   struct ieee80211_local *local =
   container_of(work, struct ieee80211_local, restart_work);
 + struct ieee80211_sub_if_data *sdata;
  
   /* wait for scan work complete */
   flush_workqueue(local-workqueue);
 @@ -254,6 +255,8 @@ static void ieee80211_restart_work(struct work_struct 
 *work)
%s called with hardware scan in progress\n, __func__);
  
   rtnl_lock();
 + list_for_each_entry(sdata, local-interfaces, list)
 + cancel_delayed_work_sync(sdata-dec_tailroom_needed_wk);

Would it make sense to just flush the work here? That way we don't have
to do all the other things.

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cfg80211: ignore netif running state when changing iftype

2015-05-20 Thread Johannes Berg 
On Tue, 2015-05-19 at 14:37 +0200, Michal Kazior wrote:
 This isn't a revert of f8cdddb8d61d (cfg80211:
 check iface combinations only when iface is
 running) as far as functionality is considred
 because b6a550156bc (cfg80211/mac80211: move more
 combination checks to mac80211) moved the logic
 somewhere else.
 
 It was possible for mac80211 to be coerced into an
 unexpected flow causing sdata union to become
 corrupted. Station pointer was put into
 sdata-u.vlan.sta memory location while it was
 really master AP's sdata-u.ap.next_beacon. This
 led to station entry being later freed as CSA
 beacon before __sta_info_flush() in
 ieee80211_stop_ap() and a subsequent invalid
 pointer dereference crash.
 
 The problem was observed with the following test
 steps:
 
  1. prepare 2 devices
  2. start hostapd AP with wds_sta=1
  3. connect client with 4addr
  4. disconnect
  5. swap roles  connect
  6. disconnect
 [ During AP (which was a client first)
   teardown kernel would crash. ]

That doesn't really explain how it crashes?

 +++ b/net/wireless/util.c
 @@ -944,7 +944,7 @@ int cfg80211_change_iface(struct 
 cfg80211_registered_device *rdev,
ntype == NL80211_IFTYPE_P2P_CLIENT))
   return -EBUSY;
  
 - if (ntype != otype  netif_running(dev)) {
 + if (ntype != otype) {
   dev-ieee80211_ptr-use_4addr = false;
   dev-ieee80211_ptr-mesh_id_up_len = 0;
   wdev_lock(dev-ieee80211_ptr);

I don't think that makes much sense - the code within this block really
only makes sense when the interface *is* running, like disconnecting
etc. Doing that when it's *not* would be entirely unexpected to the
drivers, no?

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH] Added 2 new Control Frames ( Beamforming Report Poll VHT NDP Announcement) defined in 802.11ac [EDT]

2015-05-20 Thread Johannes Berg 
On Wed, 2015-05-20 at 11:51 +, Rahul Jain wrote:
 EP-FEDC771DF4FF48A9829CB85254E29FD3
 
 Dear Johannes,
 
 As per your request, I have updated the commit message.
 This patch is first step towards further changes to be done related to 
 802.11ac new frames.

Perhaps you should combine the two-liner with other patches then?

Standalone, this isn't really worthwhile I think.

 VHT Null Data Packet (NDP) Announcement - This frame is used by Beamformers 
 to  
 gain control of the channel and identiy beformees. Beamformees will respond 
 to  
 the NDP Announcement, while all other stations will simply defer channel 
 access 
 until the sounding sequence is complete   
  
 ---   
  

Anyway you forgot S-o-b now.

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix power save state stuck in ACTIVE caused by race between suspend and Tx packet.

2015-05-20 Thread Johannes Berg 
On Tue, 2015-05-19 at 13:53 +0530, Krishna Chaitanya wrote:

  I'm not sure I get it - we always transmit a frame after resume.
 Let me explain the sequence of events:
 
 tx_frame:
   dynamic_ps_disable_work.
  get the chip out of power save.
 suspend came:
  dynamic ps timer is cancelled.
 tx queues are flushed.
 chip stays out of power save unless there is one more
 tx frame which kicks the dynamic ps timer again.

So initially, for suspend, this shouldn't matter.

And after suspend we always transmit a frame. What gives?

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Seth Forshee 
On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
 This begs the question on how we'd manage keys for firmware signing on
 linux-firmare. Since the keys are x509 keys we need a CA. Based on some 
 initial
 discussions it would seem we'd need the Linux Foundation to create a key, this
 would be embedded in the kernel and that key would be used to sign Kyle's key.
 Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
 did I summarize this correctly ?

I raised the question of key revocation when we discussed this on irc,
but it wasn't answered to my satisfaction. If a key signed by the
kernel-embedded key is compromised, how can that key be revoked so that
it is no longer trusted?

Someone mentioned UEFI blacklists, which I don't know much about, but
not all systems have UEFI. The only reliable option that comes to mind
for me is an in-kernel blacklist of keys which should no longer be
trusted.

Seth
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.1] rtlwifi: Remove the clear interrupt routine from all drivers

2015-05-20 Thread Kalle Valo 
Larry Finger larry.fin...@lwfinger.net writes:

 From: Vincent Fann vincent_f...@realtek.com

 Several of these drivers have there TX randomly blocked for 3~5 seconds while
 measuring tx throughput (iperf). The root couse happens in rtl_pci_flush().
 The function uses a while-loop to wait for TX queue length to decrease to 0.
 The TX queue length counts the number of packets that are queued in the 
 driver.
 The driver relys on the TX OK interrupt to return skb and reduce TX queue 
 length.

 The interrupt subroutine disables interupts, reads the interrupt registers, 
 and
 then clears the registers in the beginning of _rtl_pci_interrupt(). After all
 interupts process are finished, the driver invokes enable_interrupt() to 
 enable
 interupts. This behavior is normal for an interrupt subroutine.

 But enable_interrupt() invokes clear_interrupt() again. This unexpected 
 interrupt
 clearing may cleari me fresh TX OK interrupts. These missing interrupts cause 
 TX
 queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck 
 in
 unterminated while-loop.

 This patch removes clear_interrupt() in enable_interrupt() to avoid this 
 behavior.

 Signed-off-by: Vincent Fann vincent_f...@realtek.com
 Signed-off-by: Shao Fu sha...@realtek.com
 Signed-off-by: Larry Finger larry.fin...@lwfinger.net
 Cc: Stable sta...@vger.kernel.org [3.18+]
 ---

 Kalle,

 This patch is a little large for the current kernel and stable; however, it 
 only
 deletes code that is clearly wrong. I hope it will be OK.

This isn't a recent regression nor a crasher (or similar) so I can't
really justify to send this to 4.1 this late. The way I see it this
could easily wait for 4.2, right?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix power save state stuck in ACTIVE caused by race between suspend and Tx packet.

2015-05-20 Thread Krishna Chaitanya 
On Wed, May 20, 2015 at 7:11 PM, Johannes Berg
johan...@sipsolutions.net wrote:
 On Tue, 2015-05-19 at 13:53 +0530, Krishna Chaitanya wrote:

  I'm not sure I get it - we always transmit a frame after resume.
 Let me explain the sequence of events:

 tx_frame:
   dynamic_ps_disable_work.
  get the chip out of power save.
 suspend came:
  dynamic ps timer is cancelled.
 tx queues are flushed.
 chip stays out of power save unless there is one more
 tx frame which kicks the dynamic ps timer again.

 So initially, for suspend, this shouldn't matter.
Some chipsets are using power_save state from mac80211
to stay in DOZE mode, so in that case we end up
drawing more power. We can force the chipset fw to enter
DOZE independent of the mac80211 power save state but
when resuming the chip FW should again configure as per
mac80211 power save state.

 And after suspend we always transmit a frame. What gives?

Yes, but we have seen that in idle case this delay is more like
30secs-1min depending on the keepalive packet.

Till that time the chip is active and drawing more power.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: clear sdiodev-pdata if irq_of_parse_and_map fails

2015-05-20 Thread Henrik Eriksson 
Clear the pdata pointer in sdiodev after freeing the memory.  In my case
not doing so interferes with device initialization as request_irq of
sdiodev-pdata-oob_irq_nr fails, but even if not, leaving a wild
pointer is incorrect.

Signed-off-by: Henrik Eriksson henri...@axis.com
---
 drivers/net/wireless/brcm80211/brcmfmac/of.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c 
b/drivers/net/wireless/brcm80211/brcmfmac/of.c
index c824570..71ead7b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
@@ -43,6 +43,7 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
if (!irq) {
brcmf_err(interrupt could not be mapped\n);
devm_kfree(dev, sdiodev-pdata);
+   sdiodev-pdata = NULL;
return;
}
irqf = irqd_get_trigger_type(irq_get_irq_data(irq));
-- 
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Seth Forshee 
On Wed, May 20, 2015 at 04:08:58PM +0100, David Howells wrote:
 Seth Forshee seth.fors...@canonical.com wrote:
 
   This begs the question on how we'd manage keys for firmware signing on
   linux-firmare. Since the keys are x509 keys we need a CA. Based on some
   initial discussions it would seem we'd need the Linux Foundation to create
   a key, this would be embedded in the kernel and that key would be used to
   sign Kyle's key.  Kyle would in turn use his key for signing
   linux-firmware files. David, Kyle, did I summarize this correctly ?
  
  I raised the question of key revocation when we discussed this on irc,
  but it wasn't answered to my satisfaction. If a key signed by the
  kernel-embedded key is compromised, how can that key be revoked so that
  it is no longer trusted?
  
  Someone mentioned UEFI blacklists, which I don't know much about, but
  not all systems have UEFI. The only reliable option that comes to mind
  for me is an in-kernel blacklist of keys which should no longer be
  trusted.
 
 Key revocation is generally an unpleasant problem.  How do you inform a system
 that a key of any sort is revoked?  With PGP, for instance, you might be able
 to connect to the net and consult a server.

Distros could distribute updates to the blacklist via their usual update
mechanisms. That could be a new kernel with an updated blacklist (after
all we should expect blacklist updates to be very infrequent).

I suppose a database in the initrd which was loaded prior to loading any
firmware could work too, then perhaps new blacklists could be loaded
into a running kernel without a reboot as well. But that database should
probably be signed too, which creates a chicken-and-egg sort of problem.

 UEFI has a blacklist that can theoretically be used to prevent both usage of a
 key and usage of a particular object.  As I understand it, the blacklist in
 UEFI is just a table of SHA256 hashes.
 
 Relying on UEFI presents three problems, though: (1) the system admin has to
 manually, as far as I'm aware, inform the BIOS; (2) the UEFI storage is
 limited; and (3) not all systems have UEFI.

Yeah, that doesn't really sound like a good solution. Not all users are
sys admins.

 What you do on a non-UEFI system, I'm not sure.  If the kernel isn't verified
 by the loader or the system firmware then you don't have a 'fully' secure
 system anyway and the blacklist may be of questionable value.

I think there's still value - compromised firmware could easily be a
vector to compromise the kernel. Just because I can't verify my system
security doesn't mean that I don't want measures in place to keep it
from being compromised.

Seth
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.1] rtlwifi: Remove the clear interrupt routine from all drivers

2015-05-20 Thread Larry Finger 

On 05/20/2015 08:53 AM, Kalle Valo wrote:

Larry Finger larry.fin...@lwfinger.net writes:


From: Vincent Fann vincent_f...@realtek.com

Several of these drivers have there TX randomly blocked for 3~5 seconds while
measuring tx throughput (iperf). The root couse happens in rtl_pci_flush().
The function uses a while-loop to wait for TX queue length to decrease to 0.
The TX queue length counts the number of packets that are queued in the driver.
The driver relys on the TX OK interrupt to return skb and reduce TX queue 
length.

The interrupt subroutine disables interupts, reads the interrupt registers, and
then clears the registers in the beginning of _rtl_pci_interrupt(). After all
interupts process are finished, the driver invokes enable_interrupt() to enable
interupts. This behavior is normal for an interrupt subroutine.

But enable_interrupt() invokes clear_interrupt() again. This unexpected 
interrupt
clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX
queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in
unterminated while-loop.

This patch removes clear_interrupt() in enable_interrupt() to avoid this 
behavior.

Signed-off-by: Vincent Fann vincent_f...@realtek.com
Signed-off-by: Shao Fu sha...@realtek.com
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Cc: Stable sta...@vger.kernel.org [3.18+]
---

Kalle,

This patch is a little large for the current kernel and stable; however, it only
deletes code that is clearly wrong. I hope it will be OK.


This isn't a recent regression nor a crasher (or similar) so I can't
really justify to send this to 4.1 this late. The way I see it this
could easily wait for 4.2, right?


OK. If any user complains about the 3-5 second hang, I'll refer then to the 
out-of-kernel repo for a fix.


Larry


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread David Howells 
Luis R. Rodriguez mcg...@suse.com wrote:

 This begs the question on how we'd manage keys for firmware signing on
 linux-firmare. Since the keys are x509 keys we need a CA. Based on some
 initial discussions it would seem we'd need the Linux Foundation to create a
 key, this would be embedded in the kernel and that key would be used to sign
 Kyle's key.  Kyle would in turn use his key for signing linux-firmware
 files. David, Kyle, did I summarize this correctly ?

Yes.

 I think we need one change here, we'd need to ensure that such key could
 only be used for vetting firmware files, not modules loaded.  The
 firmware_class could for instance still use all the keys in
 system_trusted_keyring, which would include the UEFI key db, but it does not
 seems reasonable to expect keys used for fw signing to also go into
 system_trusted_keyring to also be used for module signing.

X.509 certificates can take attributes that define what the key held therein
may be used for.

You actually have four categories of key usage, I think:

 (1) Signing modules.

 (2) Signing firmware.

 (3) Signing kernel binaries for kexec.

 (4) Signing other keys that can then be chained to (1) - (3).

For instance, the LF might use their key to sign Kyle's key.  Kyle might want
to replace his key yearly, say, because the more examples of things signed
with it, the more exposed it becomes.  So the kernel would need to carry the
LF key, say, and then the appropriate one of Kyle's keys could be loaded
dynamically.

David
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

2015-05-20 Thread Larry Finger 

On 05/20/2015 01:17 AM, Haggai Eran wrote:

On May 19, 2015 08:47, Haggai Eran haggai.e...@gmail.com
mailto:haggai.e...@gmail.com wrote:
 
  With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
  packet are set, but the packet length is too large. Truncate the packet
  to prevent memory corruption.
 
  Signed-off-by: Haggai Eran haggai.e...@gmail.com 
mailto:haggai.e...@gmail.com
  ---
 
  Hi,
 
  I think this solves the issue for me. I'll test it more thoroughly later. I
  still don't know why a fragmented packet has such a large pkt_len value 
though.
 
  Thanks,
  Haggai
 

I guess I was too quick with this patch. It prevents the kernel page faults, but
with it I still see sometimes the connectivity disappear for a minute or two.


Is anything logged when that happens?

I'm still trying to see where that magic number of 1658 comes from, and how that 
affects the RX buffer size.


When I unconditionally set alloc_sz to tmp_len as in the attached patch (I 
remembered to refresh it this time), nothing bad has happened here yet. What 
happens on your box?


Larry


X-Account-Key: account11
X-UIDL: GmailId14d6ab65e24957d3
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys: 

Delivered-To: larry.fin...@gmail.com
Received: by 10.27.210.194 with SMTP id j185csp164052wlg;
Mon, 18 May 2015 22:47:26 -0700 (PDT)
X-Received: by 10.55.20.87 with SMTP id e84mr55051574qkh.43.1432014446155;
Mon, 18 May 2015 22:47:26 -0700 (PDT)
Return-Path: haggai.e...@gmail.com
Received: from atl4mhob18.myregisteredsite.com 
(atl4mhob18.myregisteredsite.com. [209.17.115.111])
by mx.google.com with ESMTP id 4si10409743qku.71.2015.05.18.22.47.25
for larry.fin...@gmail.com;
Mon, 18 May 2015 22:47:26 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning 
haggai.e...@gmail.com does not designate 209.17.115.111 as permitted sender) 
client-ip=209.17.115.111;
Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning haggai.e...@gmail.com 
does not designate 209.17.115.111 as permitted sender) 
smtp.mail=haggai.e...@gmail.com;
   dkim=pass header.i=@gmail.com;
   dmarc=pass (p=NONE dis=NONE) header.from=gmail.com
Received: from mail.hostingplatform.com ([10.30.71.46])
by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id 
t4J5lMQg019795
for larry.fin...@gmail.com; Tue, 19 May 2015 01:47:22 -0400
Received: (qmail 1567 invoked by uid 78); 19 May 2015 05:47:22 -
Delivered-To: lwfinger.net-larry.fin...@lwfinger.net
Received: (qmail 1561 invoked by uid 0); 19 May 2015 05:47:22 -
Received: from unknown (HELO atl4mhib20.myregisteredsite.com) (209.17.115.155)
  by 0 with SMTP; 19 May 2015 05:47:22 -
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47])
by atl4mhib20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id 
t4J5lKf3002256
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=OK)
for larry.fin...@lwfinger.net; Tue, 19 May 2015 01:47:21 -0400
Received: by wgbgq6 with SMTP id gq6so4593334wgb.3
for larry.fin...@lwfinger.net; Mon, 18 May 2015 22:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=from:to:cc:subject:date:message-id;
bh=oWBsgvRoLBpwQaZnGY5Ie4JVgHGwjAGe2u5YHbwsqwI=;
b=m2VDk+dk18/ma6Z2EVonUcvbcCDBNraJdiiDg1hfcJfGAjh0c4Bf/+KrETkghZ6MAO
 WND9oBUqnpFCFYdSLtOQF2MsOXTknU1UayBFcDBTygc72n8Cz1xYQaFR9kwX+59ig5M6
 L/RSy6+Ka8hqO7I7Bw9ha0oORt121owC/QIvLQCN4J+aeIfSQMj7IgaRYFq6UNY1sg7j
 AlGGswwG0BA6T4kNb3eu9n1V+ENn4lc2qrmPRlucJXZyK7+WbB/VLmTc0yzjrb0q4Cw/
 4dbCzegSVYYOwDG1FBMgygf94fyHx/VQ8Yn6GCsQ3ByJtLuJzXDwgjBJEAdVqQVIHI7Y
 5MXg==
X-Received: by 10.180.230.199 with SMTP id ta7mr14748321wic.1.1432014439599;
Mon, 18 May 2015 22:47:19 -0700 (PDT)
Received: from localhost.localdomain ([46.121.82.195])
by mx.google.com with ESMTPSA id 9sm20018034wjr.11.2015.05.18.22.47.15
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Mon, 18 May 2015 22:47:18 -0700 (PDT)
From: Haggai Eran haggai.e...@gmail.com
To: Larry Finger larry.fin...@lwfinger.net
Cc: linux-wireless@vger.kernel.org, Haggai Eran haggai.e...@gmail.com
Subject: [PATCH] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe
Date: Tue, 19 May 2015 08:47:24 +0300
Message-Id: 143201-29039-1-git-send-email-haggai.e...@gmail.com
X-Mailer: git-send-email 1.9.1
X-SpamScore: -0.1
X-MailHub-Apparently-To: larry.fin...@lwfinger.net

With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
packet are set, but the packet length is too large. Truncate the packet
to prevent memory corruption.

Signed-off-by: Haggai Eran haggai.e...@gmail.com
---

Hi,

I think this solves the issue for me. I'll test it more thoroughly

Re: MediaTek WiFi hardware support in upstream kernel

2015-05-20 Thread poma 
On 18.05.2015 02:03, poma wrote:
 
 Preliminary test results
 
 - lsusb -d 148f:7601:
 Bus 001 Device 007: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless 
 Adapter
 
 
 - https://github.com/kuba-moo/mt7601u
 - git log -1:
 commit ad5474ecd9fd6efd4a7f03f4a8c71ea4bb57ca73
 Author: Jakub Kicinski kubak...@wp.pl
 Date:   Wed May 6 20:44:18 2015 +0200
 
 make sure .disconnect() doesn't cleanup the device if .resume() failed
 
 Signed-off-by: Jakub Kicinski kubak...@wp.pl
 
 
 - modinfo mt7601u:
 filename:   /lib/modules/4.0.3-202.fc21.x86_64/updates/mt7601u.ko
 license:GPL
 firmware:   mt7601u.bin
 alias:  usb:v7392p7710d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2A5Fp1000d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2955p1001d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2955p0001d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2717p4106d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2001p3D04d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Dd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Cd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Bd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp7601d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v13D3p3434d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v13D3p3431d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0E8Dp760Bd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0E8Dp760Ad*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0B05p17D3d*dc*dsc*dp*ic*isc*ip*in*
 depends:cfg80211,mac80211
 vermagic:   4.0.3-202.fc21.x86_64 SMP mod_unload 
 signer: Fedora kernel signing key
 sig_key:95:7D:C8:E5:9F:5D:E6:03:71:49:1A:D0:9A:C6:8F:85:16:6C:B3:94
 sig_hashalgo:   sha256
 
 
 - md5sum /lib/firmware/mt7601u.bin:
 696cedb8e76ecc0cda9f9b0d3972c64d  /lib/firmware/mt7601u.bin
 
 
 - NetworkManager --version:
 1.0.2-2.fc21
 
 
 plug in device:
 - dmesg:
 usb 1-4: new high-speed USB device number 6 using ehci-pci
 usb 1-4: New USB device found, idVendor=148f, idProduct=7601
 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-4: Product: 802.11 n WLAN
 usb 1-4: Manufacturer: MediaTek
 usb 1-4: SerialNumber: 1.0
 cfg80211: ...
 ...
 usb 1-4: reset high-speed USB device number 6 using ehci-pci
 mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
 mt7601u 1-4:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 
 201302052146
 mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
 mt7601u 1-4:1.0: EEPROM ver:0d fae:00
 ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
 usbcore: registered new interface driver mt7601u
 mt7601u 1-4:1.0 wlp0s2f1u4: renamed from wlan0
 ...
 cfg80211: ...
 ...
 wlp0s2f1u4: authenticate with BSSID
 wlp0s2f1u4: send auth to BSSID (try 1/3)
 wlp0s2f1u4: authenticated
 wlp0s2f1u4: associate with BSSID (try 1/3)
 wlp0s2f1u4: RX AssocResp from BSSID (capab=0x411 status=0 aid=1)
 wlp0s2f1u4: associated
 
 
 - iwconfig wlp0s2f1u4:
 wlp0s2f1u4  IEEE 802.11bgn  ESSID:AP  
   Mode:Managed  Frequency:2.422 GHz  Access Point: BSSID   
   Bit Rate=135 Mb/s   Tx-Power=20 dBm   
   Retry short limit:7   RTS thr:off   Fragment thr:off
   Encryption key:off
   Power Management:off
   Link Quality=67/70  Signal level=-43 dBm  
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:873   Missed beacon:0
 
 
...

Can be tested with the test compilation I share with you bona fide:
http://goo.gl/Gm4ffO
ISO/Fedora-Live-Xfce-WiFi.iso

Runs on baremetal  QEMU/KVM/Libvirt/Virtual Machine Manager
http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest


With the script 'mt7601u-fw-install' can be initiated the download and 
installation of the required firmware,
though it would be optimal to resolve it in the following manner:

In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
https://github.com/openwrt/mt76

there is a license file together with firmwares:
https://github.com/openwrt/mt76/blob/master/firmware


Whether the same can be done with:
mt7601u -  Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi dongle
https://github.com/kuba-moo/mt7601u
?


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

2015-05-20 Thread Jakub Kiciński 
On Wed, 20 May 2015 19:06:04 +0200, poma wrote:
 With the script 'mt7601u-fw-install' can be initiated the download and 
 installation of the required firmware,
 though it would be optimal to resolve it in the following manner:
 
 In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
 https://github.com/openwrt/mt76
 
 there is a license file together with firmwares:
 https://github.com/openwrt/mt76/blob/master/firmware
 
 
 Whether the same can be done with:
 mt7601u -  Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi 
 dongle
 https://github.com/kuba-moo/mt7601u
 ?

I will ask MediaTek to send firmware to linux-firmware.git once the
driver passes review and is accepted to mainline.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread One Thousand Gnomes 
On Wed, 20 May 2015 09:04:26 -0500
Seth Forshee seth.fors...@canonical.com wrote:

 On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
  This begs the question on how we'd manage keys for firmware signing on
  linux-firmare. Since the keys are x509 keys we need a CA. Based on some 
  initial
  discussions it would seem we'd need the Linux Foundation to create a key, 
  this
  would be embedded in the kernel and that key would be used to sign Kyle's 
  key.
  Kyle would in turn use his key for signing linux-firmware files. David, 
  Kyle,
  did I summarize this correctly ?
 
 I raised the question of key revocation when we discussed this on irc,
 but it wasn't answered to my satisfaction. If a key signed by the
 kernel-embedded key is compromised, how can that key be revoked so that
 it is no longer trusted?
 
 Someone mentioned UEFI blacklists, which I don't know much about, but
 not all systems have UEFI. The only reliable option that comes to mind
 for me is an in-kernel blacklist of keys which should no longer be
 trusted.

More to the point why do you want to sign firmware files ? Leaving aside
the fact that someone will produce a device with GPLv3 firmware just to
p*ss you off there's the rather more relevant fact that firmware for
devices on a so called trusted platform already have signed firmware.

For external devices I don't normally have access to read system memory
anyway, and signing firmware would achieve nothing unless you start doing
crazy DRM style key exchanges to prove the endpoint is trusted. Any NSA
trojan wifi stick is simply going to nod as the correct firmware is
uploaded, and then ignore it. And if I'm just out to be a pain I can
already just plug in a fake device claiming to be a usb disk with 256
bytes per sector (boom... exit machine stage right), or for that matter
wire a USB stick with 5v connected to the mains at the nearest wall
socket.

So I don't think I understand the threat model your signing hopes to fix ?

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Petko Manolov 
On 15-05-19 17:22:59, Luis R. Rodriguez wrote:

 I have a series of reasons find IMA unsuitable for the current goals at hand:
 
   1) IMA is a pretty big kitchen sink, we want this to work well for
 even embedded systems, or architectures that do not have or require
 TPMs

No, it isn't.  I've profiled it and performance hit is negligible.  All hash 
algorithms used have been optimized for most cpu architectures.

   2) The appraisal is also done for to account for a specific state of
 affairs, you appraise to the user of the integrity of the system at a
 specific point in time, firmware signing can provide integrity /
 authorship vetting of files directly from the authors. In the case of
 regulatory.bin that was the whole point of it, and firmware signing as
 is being provided is intended to generalize that but by sharing code
 in-kernel with module signing infrastructure

This is weird English to me, but since i am no native speaker either i'll blame 
myself. :)  Could you please rephrase?

 If we go with IMA, I however do not think this would be appropriate and 
 overkill at this point in time.

Depends on what your needs are.  If you need authenticity then IMA-appraise is 
definitely your way to go.  For anything less secure you may go with LSM of 
choice to apply whatever policy you may have in mind.

Again, security and convenience do not play well together.


Petko
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Petko Manolov 
On 15-05-20 17:24:46, One Thousand Gnomes wrote:
 
 More to the point why do you want to sign firmware files ? Leaving aside the 
 fact that someone will produce a device with GPLv3 firmware just to p*ss you 
 off there's the rather more relevant fact that firmware for devices on a so 
 called trusted platform already have signed firmware.

For trusted systems one would like to make sure everything that goes in has 
known provenance.  Maybe this was the idea?

 For external devices I don't normally have access to read system memory 
 anyway, and signing firmware would achieve nothing unless you start doing 
 crazy DRM style key exchanges to prove the endpoint is trusted. Any NSA 
 trojan 
 wifi stick is simply going to nod as the correct firmware is uploaded, and 
 then ignore it. And if I'm just out to be a pain I can already just plug in a 
 fake device claiming to be a usb disk with 256 bytes per sector (boom... exit 
 machine stage right), or for that matter wire a USB stick with 5v connected 
 to 
 the mains at the nearest wall socket.

Yep, gaining physical access to the system is a game over.  It is arguable how 
trusted a networked machine could be and i guess the answer is not much...


Petko
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: allow NVRAM values to contain space and '#' chars

2015-05-20 Thread Rafał Miłecki 
Both chars often require special handling (and brcmf_nvram_handle_idle
already takes care of them) but they should be allowed when parsing
entry value. Some example entries from SR400ac device NVRAM:
1:ccode=#a
wl_realmlist=mail.example.com+0+21=2,4#5,7?cisco.com+0+21=2,4#5,7

Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 45d7191..64e2491 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
@@ -66,14 +66,15 @@ struct nvram_parser {
bool multi_dev_v2;
 };
 
-static bool is_nvram_char(char c)
+/**
+ * is_printable_char() - check if char is ASCII printable one
+ *
+ * Please note that '#' may require different handling depending on the 
context.
+ * It's used as comment beginning and it's not allowed in key name.
+ */
+static bool is_printable_char(char c)
 {
-   /* comment marker excluded */
-   if (c == '#')
-   return false;
-
-   /* key and value may have any other readable character */
-   return (c  0x20  c  0x7f);
+   return (c = 0x20  c  0x7f);
 }
 
 static bool is_whitespace(char c)
@@ -92,7 +93,7 @@ static enum nvram_parser_state brcmf_nvram_handle_idle(struct 
nvram_parser *nvp)
goto proceed;
if (c == '#')
return COMMENT;
-   if (is_nvram_char(c)) {
+   if (is_printable_char(c)) {
nvp-entry = nvp-pos;
return KEY;
}
@@ -120,7 +121,7 @@ static enum nvram_parser_state 
brcmf_nvram_handle_key(struct nvram_parser *nvp)
nvp-multi_dev_v1 = true;
if (strncmp(nvp-fwnv-data[nvp-entry], pcie/, 5) == 0)
nvp-multi_dev_v2 = true;
-   } else if (!is_nvram_char(c)) {
+   } else if (!is_printable_char(c) || c == ' ' || c == '#') {
brcmf_dbg(INFO, warning: ln=%d:col=%d: '=' expected, skip 
invalid key entry\n,
  nvp-line, nvp-column);
return COMMENT;
@@ -140,7 +141,7 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
u32 cplen;
 
c = nvp-fwnv-data[nvp-pos];
-   if (!is_nvram_char(c)) {
+   if (!is_printable_char(c)) {
/* key,value pair complete */
ekv = (u8 *)nvp-fwnv-data[nvp-pos];
skv = (u8 *)nvp-fwnv-data[nvp-entry];
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 drops packet with old IV after rekeying - workaround patch for CCMP

2015-05-20 Thread Alexander Wetzel 

I've verified that turning off hardware encryption on the AP and the STA
is indeed preventing the issue.
As soon as one of them is using the hardware encryption I can trigger
the problem. (In my setup it seems to be mostly caused by the AP, since
I needed sometimes as much as three rekeys to get the freeze when the AP
was using Software and the STA hardware encryption.)

So confident that we finally found the root of the evil I tried to write
some code catching the races, see the attachment.

It's probably not the best fix, but the only one I could think of and
deploy myself with the knowledge I gathered here and the last days.

It's only for CCMP for now and I've not checked on assumptions what some
parts of the code are for.
This is just works for me. (It survived now 30 rekeys under my test
load, when previously nearly every rekey did freeze it.)

I think there is no need any longer to generate captures, but if you
want them anyway I can of course still work on that.


The decision to check if the pn is = 10 as indicator to switch over to
the correct pn counter is at best questionable. (Using 1 does not
work. I have problems with the inital key here and the code was not
switching over to the correct rx_pn counter and I expect that we also
may lose some frames here.) I'm not even sure that it's safe to assume
that pn is always starting at one, since wpa_supplicant is dumping some
sequence number on rekey I would have assumed to be a more or less
random start value. But in the debug prints the real value is always
starting at one. So I'm using that for now.

I'll now try that in my environment, keeping the insane low rekey
interval at two minutes for at least some weeks.

What was really surprising me here is, that this is such a generic issue
and I'm finding that in my home environment. For my understanding that
should break many (all?) EAP Wlan's. (I'm using EAP-TLS and that did
make the WLAN basically unusable and any sane person would have switched
back to PSK...)

For completeness, here is the original openwrt bug report I opened:
https://dev.openwrt.org/ticket/18966


Alexander
diff -ur linux-4.0.4-gentoo/net/mac80211/key.h linux-4.0.4-gentoo_patched/net/mac80211/key.h
--- linux-4.0.4-gentoo/net/mac80211/key.h	2015-04-13 00:12:50.0 +0200
+++ linux-4.0.4-gentoo_patched/net/mac80211/key.h	2015-05-20 13:16:06.370256697 +0200
@@ -84,12 +84,14 @@
 			 * Management frames.
 			 */
 			u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
+			u8 rx_pn_old[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
 			struct crypto_aead *tfm;
 			u32 replays; /* dot11RSNAStatsCCMPReplays */
 		} ccmp;
 		struct {
 			atomic64_t tx_pn;
 			u8 rx_pn[IEEE80211_CMAC_PN_LEN];
+			u8 rx_pn_old[IEEE80211_CMAC_PN_LEN];
 			struct crypto_cipher *tfm;
 			u32 replays; /* dot11RSNAStatsCMACReplays */
 			u32 icverrors; /* dot11RSNAStatsCMACICVErrors */
@@ -97,6 +99,7 @@
 		struct {
 			atomic64_t tx_pn;
 			u8 rx_pn[IEEE80211_GMAC_PN_LEN];
+			u8 rx_pn_old[IEEE80211_GMAC_PN_LEN];
 			struct crypto_aead *tfm;
 			u32 replays; /* dot11RSNAStatsCMACReplays */
 			u32 icverrors; /* dot11RSNAStatsCMACICVErrors */
@@ -109,12 +112,14 @@
 			 * Management frames.
 			 */
 			u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_GCMP_PN_LEN];
+			u8 rx_pn_old[IEEE80211_NUM_TIDS + 1][IEEE80211_GCMP_PN_LEN];
 			struct crypto_aead *tfm;
 			u32 replays; /* dot11RSNAStatsGCMPReplays */
 		} gcmp;
 		struct {
 			/* generic cipher scheme */
 			u8 rx_pn[IEEE80211_NUM_TIDS + 1][MAX_PN_LEN];
+			u8 rx_pn_old[IEEE80211_NUM_TIDS + 1][MAX_PN_LEN];
 		} gen;
 	} u;
 
diff -ur linux-4.0.4-gentoo/net/mac80211/wpa.c linux-4.0.4-gentoo_patched/net/mac80211/wpa.c
--- linux-4.0.4-gentoo/net/mac80211/wpa.c	2015-04-13 00:12:50.0 +0200
+++ linux-4.0.4-gentoo_patched/net/mac80211/wpa.c	2015-05-20 21:43:25.529721066 +0200
@@ -495,6 +495,7 @@
 	struct sk_buff *skb = rx-skb;
 	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
 	u8 pn[IEEE80211_CCMP_PN_LEN];
+	static u8 zero[IEEE80211_CCMP_PN_LEN];
 	int data_len;
 	int queue;
 
@@ -525,6 +526,31 @@
 		return RX_DROP_UNUSABLE;
 	}
 
+	/* HACK: try to work around race when replacing PSK with enabled hardware offload on AP or STA */
+	if (unlikely(memcmp(key-u.ccmp.rx_pn[queue], zero, IEEE80211_CCMP_PN_LEN) == 0 )) {
+
+		printk (DDD - rx_pn is zero, virgin key detected! pl=%x\n, pn[IEEE80211_CCMP_PN_LEN-1]);
+		print_hex_dump_debug(cnt: , DUMP_PREFIX_OFFSET, IEEE80211_CCMP_PN_LEN, 1, key-u.ccmp.rx_pn[queue], IEEE80211_CCMP_PN_LEN, false);
+		print_hex_dump_debug(pn : , DUMP_PREFIX_OFFSET, IEEE80211_CCMP_PN_LEN, 1, pn, IEEE80211_CCMP_PN_LEN, false);
+
+		if ((memcmp(pn, zero, IEEE80211_CCMP_PN_LEN -1) == 0)  pn[IEEE80211_CCMP_PN_LEN-1] = 10) {
+			/* pn is =10 , we can start using the new counter */
+			printk (DDD - set new pn\n);
+			memcpy(key-u.ccmp.rx_pn[queue], pn, IEEE80211_CCMP_PN_LEN);
+		} else if (memcmp(pn, key-u.ccmp.rx_pn_old[queue], IEEE80211_CCMP_PN_LEN) = 0) {
+			printk

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

2015-05-20 Thread Luis R. Rodriguez 
On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
 On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
  On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
   Well that's be true if FW_LOADER was easy to disable, but its not. You
   really gotta try hard to disable it. Not only does it require EXPERT
   but also EMBEDDED.
 
 How does that require EMBEDDED?

Sorry not embedded, not sure where I got that from, for some reason
I though you had mentioned that.

   I think its fair to say if you disable FW_LOADER
   you know what you are doing and its fair for us then to remove such
   selects or depends. Thoughts?
  
  Sure.  I can live with killing all selects/depends on FW_LOADER.
 
 (Having reread my mail from the day before yesterday once more, I note
 that my suggestion to drop the selects is rather circular. Because it's
 the selects that also make it hard to disable FW_LOADER.)
 
 So the message is something like: If you set EXPERT and disable
 FW_LOADER you're on your own. You have to figure out yourself whether
 the configuration you chose builds

I think we can attest that it will build, otherwise we should fix.

 or actually runs correctly.

Whether it will run in this case will depend on whether or not
the firmware was needed or not, if it was it won't. Note that
there is a FW API call which implies this is optional firmware,
its the request_firmware_direct() call but this call is synchronous,
we have no option for asynchronous behaviour. I intend to add support
for that but that requires a bit of changes. Also, based on my review
its a fair assumption that most calls to the FW APIs mean they need
it. The only ones we can be sure are optional are the ones using
request_firmware_direct().

 Don't
 expect us to care about the issues you run into. And that goes for
 randconfig builds that happen to do that too.

I think its fair to expect us to fix randconfig build issues, but not
runtime issues.

 That might be an acceptable thing to say. The help for EXPERT is pretty
 clear. But I do wonder if this is a first or if this has been done
 before (ie, whether there's a precedent). Because, generally speaking,
 people try rather hard to prevent pointless configurations.

Yeah sure, we even let your system go out of regulatory compliance,
see CFG80211_CERTIFICATION_ONUS, and CFG80211_REG_CELLULAR_HINTS.
Then with CFG80211_INTERNAL_REGDB the parser right now lacks support
for a few new bells and whistles and requires expert knowledge how
to properly build and integrate all new bells and whistles. It seemed
folks were OK with this.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2] brcmfmac: allow NVRAM values to contain space and '#' chars

2015-05-20 Thread Rafał Miłecki 
Both chars often require special handling (and brcmf_nvram_handle_idle
already takes care of them) but they should be allowed when parsing
entry value. Some example entries from SR400ac device NVRAM:
1:ccode=#a
wl0_version=7.14.43.16 (r)

Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: Minor change in commit message only. Provide an example of NVRAM entry
using space (not just a '#'). It's unprefixed (shouldn't be uploaded to
hardware anyway), but proves it's allowed in general.
---
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 45d7191..64e2491 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
@@ -66,14 +66,15 @@ struct nvram_parser {
bool multi_dev_v2;
 };
 
-static bool is_nvram_char(char c)
+/**
+ * is_printable_char() - check if char is ASCII printable one
+ *
+ * Please note that '#' may require different handling depending on the 
context.
+ * It's used as comment beginning and it's not allowed in key name.
+ */
+static bool is_printable_char(char c)
 {
-   /* comment marker excluded */
-   if (c == '#')
-   return false;
-
-   /* key and value may have any other readable character */
-   return (c  0x20  c  0x7f);
+   return (c = 0x20  c  0x7f);
 }
 
 static bool is_whitespace(char c)
@@ -92,7 +93,7 @@ static enum nvram_parser_state brcmf_nvram_handle_idle(struct 
nvram_parser *nvp)
goto proceed;
if (c == '#')
return COMMENT;
-   if (is_nvram_char(c)) {
+   if (is_printable_char(c)) {
nvp-entry = nvp-pos;
return KEY;
}
@@ -120,7 +121,7 @@ static enum nvram_parser_state 
brcmf_nvram_handle_key(struct nvram_parser *nvp)
nvp-multi_dev_v1 = true;
if (strncmp(nvp-fwnv-data[nvp-entry], pcie/, 5) == 0)
nvp-multi_dev_v2 = true;
-   } else if (!is_nvram_char(c)) {
+   } else if (!is_printable_char(c) || c == ' ' || c == '#') {
brcmf_dbg(INFO, warning: ln=%d:col=%d: '=' expected, skip 
invalid key entry\n,
  nvp-line, nvp-column);
return COMMENT;
@@ -140,7 +141,7 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
u32 cplen;
 
c = nvp-fwnv-data[nvp-pos];
-   if (!is_nvram_char(c)) {
+   if (!is_printable_char(c)) {
/* key,value pair complete */
ekv = (u8 *)nvp-fwnv-data[nvp-pos];
skv = (u8 *)nvp-fwnv-data[nvp-entry];
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

2015-05-20 Thread Haggai Eran 
On 20 May 2015 at 19:39, Larry Finger larry.fin...@lwfinger.net wrote:
 On 05/20/2015 01:17 AM, Haggai Eran wrote:

 On May 19, 2015 08:47, Haggai Eran haggai.e...@gmail.com
 mailto:haggai.e...@gmail.com wrote:
  
   With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
   packet are set, but the packet length is too large. Truncate the packet
   to prevent memory corruption.
  
   Signed-off-by: Haggai Eran haggai.e...@gmail.com
 mailto:haggai.e...@gmail.com
   ---
  
   Hi,
  
   I think this solves the issue for me. I'll test it more thoroughly
 later. I
   still don't know why a fragmented packet has such a large pkt_len value
 though.
  
   Thanks,
   Haggai
  

 I guess I was too quick with this patch. It prevents the kernel page
 faults, but
 with it I still see sometimes the connectivity disappear for a minute or
 two.


 Is anything logged when that happens?
No. I get once in a while the other corrupted entries I told you
about, but nothing special to these freezes

 I'm still trying to see where that magic number of 1658 comes from, and how
 that affects the RX buffer size.

I tried to look at the new driver (rtl8192su), but it doesn't seem to
handle this more-fragment bit at all.

 When I unconditionally set alloc_sz to tmp_len as in the attached patch (I
 remembered to refresh it this time), nothing bad has happened here yet. What
 happens on your box?

The same freezes still occur.

Thanks,
Haggai
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] amth10k: fix promisc handling

2015-05-20 Thread Michal Kazior 
On 12 May 2015 at 14:45, Michal Kazior michal.kaz...@tieto.com wrote:
 Patch df1404650ccb (mac80211: remove support for
 IFF_PROMISC) removed promiscuous flag propagation
 to drivers.

 However the patch was designed against ath10k
 without 548462133d98 (ath10k: fix interrupt
 storm).

 After merge the code drifted into being no longer
 correct and due to monitor vdev being
 overzealously started caused IBSS to crash on
 999.999.0.636 for QCA988X (this firmware revision
 is known to have issues with monitor vdev).

 This patch keeps expectations of commit
 548462133d98 (i.e. reduce irq storm by not
 enabling monitor vdev for AP) and doesn't break
 existing (known) setups that imply promiscuous
 mode on network interfaces.

 Contrary to what it looks like 548462133d98
 functionality is not reverted since the intention
 was a subset of what df1404650ccb did.

 Fixes: c17c997d5613 (Merge 
 git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next)
 Signed-off-by: Michal Kazior michal.kaz...@tieto.com

Apparently this also fixes some weird issues with qca6174 hw2.1 notably:
 - ath10k causing disconnecting of other devices in a BSS
 - random Fw crashes

Both problems started to happen because c17c997d5613 enabled monitor
vdev by default on STA interfaces. It seems that qca6174 hw2.1
firmware has issues similar to those of qca988x 999.999.0.636
regarding monitor vdev opration.

Also, I've made a typo in the subject.

I'll post v2 with subject fixed and extended commit log later.


Michał
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Petko Manolov 
On 15-05-20 21:41:04, Greg Kroah-Hartman wrote:
 On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
  On 15-05-20 17:24:46, One Thousand Gnomes wrote:
   
   More to the point why do you want to sign firmware files ? Leaving aside 
   the 
   fact that someone will produce a device with GPLv3 firmware just to p*ss 
   you 
   off there's the rather more relevant fact that firmware for devices on a 
   so 
   called trusted platform already have signed firmware.
  
  For trusted systems one would like to make sure everything that goes in 
  has 
  known provenance.  Maybe this was the idea?
 
 If so, then just do what people do today, verify their known valid disk image 
 before mounting it and then they know they can trust the data on it to be use 
 for whatever (including firmware.)  No kernel changes needed, distro support 
 is already there for this.

I do agree, the infrastructure is already in place.  The project i am working 
on 
has very strict security requirements, quite unlike regular Linux box.  I was 
pleasantly surprised that it didn't take much kernel hacking to get to the 
point 
where stuff is working to our liking.

 I too don't understand this need to sign something that you don't really know 
 what it is from some other company, just to send it to a separate device that 
 is going to do whatever it wants with it if it is signed or not.

This is not the point.  What you need to know is _where_ the firmware came 
from, 
not _what_ it does once it reach your system.  If you don't care about such 
things, just ignore the signature. :)


Petko
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread David Howells 
Seth Forshee seth.fors...@canonical.com wrote:

  This begs the question on how we'd manage keys for firmware signing on
  linux-firmare. Since the keys are x509 keys we need a CA. Based on some
  initial discussions it would seem we'd need the Linux Foundation to create
  a key, this would be embedded in the kernel and that key would be used to
  sign Kyle's key.  Kyle would in turn use his key for signing
  linux-firmware files. David, Kyle, did I summarize this correctly ?
 
 I raised the question of key revocation when we discussed this on irc,
 but it wasn't answered to my satisfaction. If a key signed by the
 kernel-embedded key is compromised, how can that key be revoked so that
 it is no longer trusted?
 
 Someone mentioned UEFI blacklists, which I don't know much about, but
 not all systems have UEFI. The only reliable option that comes to mind
 for me is an in-kernel blacklist of keys which should no longer be
 trusted.

Key revocation is generally an unpleasant problem.  How do you inform a system
that a key of any sort is revoked?  With PGP, for instance, you might be able
to connect to the net and consult a server.

UEFI has a blacklist that can theoretically be used to prevent both usage of a
key and usage of a particular object.  As I understand it, the blacklist in
UEFI is just a table of SHA256 hashes.

Relying on UEFI presents three problems, though: (1) the system admin has to
manually, as far as I'm aware, inform the BIOS; (2) the UEFI storage is
limited; and (3) not all systems have UEFI.

What you do on a non-UEFI system, I'm not sure.  If the kernel isn't verified
by the loader or the system firmware then you don't have a 'fully' secure
system anyway and the blacklist may be of questionable value.

David
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html