Loic Poulain | 16 Sep 14:53 2014
Picon

[PATCH] net: rfkill: gpio: Fix clock status

Clock is disabled when the device is blocked.
So, clock_enabled is the logical negation of "blocked".

Signed-off-by: Loic Poulain <loic.poulain@...>
---
 net/rfkill/rfkill-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 14c98e4..408e51f 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
 <at>  <at>  -54,7 +54,7  <at>  <at>  static int rfkill_gpio_set_power(void *data, bool blocked)
 	if (blocked && !IS_ERR(rfkill->clk) && rfkill->clk_enabled)
 		clk_disable(rfkill->clk);

-	rfkill->clk_enabled = blocked;
+	rfkill->clk_enabled = !blocked;

 	return 0;
 }
--

-- 
1.8.3.2

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

(Continue reading)

Sujith Manoharan | 16 Sep 03:49 2014

[PATCH] ath9k: Fix build error

From: Sujith Manoharan <c_manoha@...>

This happens when CONFIG_ATH9K_CHANNEL_CONTEXT is
not enabled.

../drivers/net/wireless/ath/ath9k/recv.c: In function ‘ath_rx_ps_beacon’:
../drivers/net/wireless/ath/ath9k/recv.c:553:27: error: ‘struct ath_softc’ has no member
named ‘offchannel’
    if (sc->cur_chan == &sc->offchannel.chan)
                           ^
../scripts/Makefile.build:257: recipe for target 'drivers/net/wireless/ath/ath9k/recv.o' failed
make[10]: *** [drivers/net/wireless/ath/ath9k/recv.o] Error 1
../scripts/Makefile.build:404: recipe for target 'drivers/net/wireless/ath/ath9k' failed
make[9]: *** [drivers/net/wireless/ath/ath9k] Error 2

Signed-off-by: Sujith Manoharan <c_manoha@...>
---
 drivers/net/wireless/ath/ath9k/recv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 0b53b74..51a9852 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
 <at>  <at>  -549,10 +549,12  <at>  <at>  static void ath_rx_ps_beacon(struct ath_softc *sc, struct sk_buff *skb)
 		ath_dbg(common, PS,
 			"Reconfigure beacon timers based on synchronized timestamp\n");

+#ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
 		if (ath9k_is_chanctx_enabled()) {
(Continue reading)

Lorenzo Bianconi | 16 Sep 02:13 2014
Picon

[PATCHv2 00/10] add support for ACK timeout estimation in ath9k driver

This patchset adds support for estimation of the ACK timeout (dynack) in ath9k
driver. Ath9k dynack computes the ACK timeout based on ACK frame RX timestamp,
TX frame timestamp and frame duration.

Ath9k dynack has been tested in indoor environment using AR9223/AR9280 chipset
(running 3.17.0-rc5 kernel), on 9Km PtoP link using AR9280 chipset
(running OpenWRT trunk, compat-wireless-2014-05-22) and on an AP using AR9280
chipset (running OpenWRT trunk, compat-wireless-2014-05-22) serving 35 STA with
links up to 8Km

Changes since v1:
- rebase on top of "configure dynack through mac80211/cfg80211 stack" patchset
- improve documentation

Changes since RFCv2:
- disable dynack by default
- add ath9k_enable_dynack() method to enable ack timeout estimation algorithm
- remove dynack entry from ath9k debugfs

Changes since RFCv1:
- use ISC license instead of GPLv2 one
- use an inline method instead of a macro for EWMA calculation
- use powers of two weights in EWMA calculation
- fix typos
- add ath_dynack_node_init/ath_dynack_node_deinit methods
- use different logic to enable/disable dynack processing

Lorenzo Bianconi (10):
  ath9k: export methods related to ACK timeout estimation
  ath9k: add duration field to ath_tx_status
(Continue reading)

Emmanuel Grumbach | 15 Sep 21:38 2014
Picon

git request-pull gets confused?

Hi,

I have patches that rely on mac80211-next. Until now, I would wait for John to pull them from mac80211-next
into wireless-next,
then I'd merge wireless-next into my tree. On top of that I'd apply the new patches.

"git request-pull wireless-next/master iwlwifi-next HEAD" didn't get confused in this case, it would
show my patches only and not the
patches in wireless-next obviously.

This time, I did something slightly different. I merged Johannes's tag - the one he sent to John. So that I got
content from mac80211-next
before it made it to wireless-next, and on top of that I applied my new patches. I thought I could wait for John
to pull from Johannes and
then, I'd just have to fetch wireless-next and let do git request-pull do its magic... But...

"git request-pull wireless-next/master iwlwifi-next HEAD" lists my merge patch:
Emmanuel Grumbach (1):
      Merge tag 'mac80211-next-for-john-2014-09-12' into HEAD

which is perfectly fine. I can see no mac80211 patches in the patch list, but...

[snip]
 include/linux/ieee80211.h                             |  73 ++++++++++++++++++++++++++++++++++-
 include/net/cfg80211.h                                |  69 +++++++++++++++++++++++++++------
 include/net/mac80211.h                                |  34 ++++++++--------
 include/uapi/linux/nl80211.h                          | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 net/mac80211/agg-rx.c                                 |   5 ++-
 net/mac80211/cfg.c                                    | 114 ++++++++++++++++++++++++++++++++++++------------------
 net/mac80211/chan.c                                   | 191 +++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------
(Continue reading)

Seth Forshee | 15 Sep 17:49 2014

Re: BCM4313 14e4:4727 was working fine, now failing - Ubuntu Linux

On Mon, Sep 15, 2014 at 10:54:14AM -0400, Marc & Karen Vincent wrote:
> Hello Seth and Arend,
> 
> Thanks for getting back to me so quickly.
> 
> I hope that this gives some pointers - 
> 
> 
> dmesg output attached as requested. The lines 30.649061 and 30.649285 (ref brcms) appear as error
messages on the screen during the boot process. The line 23.809659 seems to confirm the presence of the
brcms and bcma modules
> From a check back through the system logs Linux updated on Friday 12th after which the wireless failed, it
was with the same 3.13.0.xx that the Ubuntu 14.04 LTS upgrade installed on Saturday 13th
> From the logs of the Saturday 13th upgrade the previous version of Linux appears to have been 3.2.0.68.81
and wireless had definitely worked without modifications prior to this. Also, no attempt was made to fix
the wireless BEFORE the LTS Ubuntu upgrade (wired), which incidentally was from 12.04 LTS and was problem free

Oh, in that case it sounds like we're talking about an upgrade from a
3.2.x kernel to a 3.13.x kernel. But I'm a bit confused - from the
original message I got the impression that you started seeing problems
before you did the LTS upgrade, but from this statement I get the
impression that the problems didn't start until after the upgrade. Can
you clarify?

Those error messages you pointed out aren't really errors in the sense
that something went wrong, they're just notifications of features which
haven't been implemented in brcmsmac. They aren't related to the
problems you're seeing.

I didn't notice anything in the dmesg which provides any clues as to
(Continue reading)

Janusz Dziedzic | 15 Sep 12:47 2014

[PATCH v2 2/2] iw: add vendor send command

This allow to send vendor data to the driver.
This command required OUI and SUBCMD parameters.

Also optional DATA parameter could be used:

cat data.bin | iw wlan0 send oui subcmd -
iw wlan0 send oui subcmd file.bin
iw wlan0 vendor send oui subcmd 0x00 0x00 0x00 0x1f
echo EOF | iw wlan0 vendor send oui subcmd -

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@...>
---
 Makefile |  2 +-
 vendor.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+), 1 deletion(-)
 create mode 100644 vendor.c

diff --git a/Makefile b/Makefile
index f042e30..802f87a 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -16,7 +16,7  <at>  <at>  OBJS = iw.o genl.o event.o info.o phy.o \
 	interface.o ibss.o station.o survey.o util.o \
 	mesh.o mpath.o scan.o reg.o version.o \
 	reason.o status.o connect.o link.o offch.o ps.o cqm.o \
-	bitrate.o wowlan.o coalesce.o roc.o p2p.o
+	bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o
 OBJS += sections.o

 OBJS-$(HWSIM) += hwsim.o
(Continue reading)

Dan Carpenter | 15 Sep 11:17 2014
Picon

re: net/usb: Add Samsung Kalmia driver for Samsung GT-B3730

I started writing a Smatch check to look for:

	skb->len - foo

where foo might be more than skb->len.  I don't know this code well
enough to say what the rules are exactly.  I chose a fairly suspect
bit of code to use as an example to get some feedback.

Hello Marius B. Kotsbak,

The patch d40261236e8e: "net/usb: Add Samsung Kalmia driver for
Samsung GT-B3730" from Jun 12, 2011, leads to the following static
checker warning:

	drivers/net/usb/kalmia.c:281 kalmia_rx_fixup()
	warn: this assumes skb->len is at least 12 bytes

drivers/net/usb/kalmia.c
   245          /* incomplete header? */
   246          if (skb->len < KALMIA_HEADER_LENGTH)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We verify that it is at least 6.

   247                  return 0;
   248  
   249          do {

This is a do while (skb->len) loop.  Shouldn't the check for invalid
skb->len be inside the loop?

(Continue reading)

Arend van Spriel | 15 Sep 10:15 2014

Re: BCM4313 14e4:4727 was working fine, now failing - Ubuntu Linux

+ linux-wireless, Seth

On 14-09-14 16:36, Karen Vincent wrote:
> Hello,
> 
> I am trying to fix a wireless connectivity problem on a Lenovo G585 which has 
> BCM4313 14e4:4727 (rev 01) running on Ubuntu 14.04
> 
> This was working fine, then following a Linux headers upgrade last week it 
> started to play up (connection failing or repeatedly dropping)

Hi Karen,

I assume the upgrade involved a kernel upgrade and not just the headers.
It would be very interesting to know the package versions before and
after this particular upgrade. I added Seth as he may know whether the
packaging software in Ubuntu keeps any log with that info.

> As a LTS Ubuntu upgrade was due anyway I decided to complete this first and then 
> see if this resolved the wireless issues. Ubuntu 14.04 successfully installed 
> (using ethernet wired connection) but the wireless problem remains

Would you happen to know the kernel version before the upgrade as this
surely looks like a regression.

> Having checked the various online forums I have
> * run the various updates including -pciids
> * purged bcmwl-kernel-source

Are you aware that this was actually used?
(Continue reading)

Sujith Manoharan | 15 Sep 07:55 2014

[PATCH 0/5] ath9k patches

From: Sujith Manoharan <c_manoha@...>

MCC fixes for 3.18

Sujith Manoharan (5):
  ath9k: Remove unnecessary tbtt assignment
  ath9k: Check beaconing mode properly
  ath9k: Set offchannel state properly
  ath9k: Remove useless opmode check
  ath9k: Fix primary station configuration

 drivers/net/wireless/ath/ath9k/ath9k.h   |  4 +-
 drivers/net/wireless/ath/ath9k/channel.c |  8 ++--
 drivers/net/wireless/ath/ath9k/main.c    | 70 ++++++++++++++++++++------------
 drivers/net/wireless/ath/ath9k/recv.c    |  2 +-
 4 files changed, 51 insertions(+), 33 deletions(-)

--

-- 
2.1.0

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

Emmanuel Grumbach | 15 Sep 07:07 2014
Picon

pull request: iwlwifi-next 2014-09-15

Hi John,

This is a pull request for 3.18. I have a few more patches for 3.18 that are not included here.
This pull request was big enough without them, and they rely on mac80211 patches that are not
in wireless-next yet. In my master branch, I merged Johannes's tag on mac80211-next to be able
to apply these patches, I'll send you another pull request once you'll pull from Johannes. Let
me know if you prefer me to merge wireless-next rather than mac80211-next. I just found it easier
for me.
I also merged iwlwifi-fixes to avoid minor conflicts.

I fix here dvm which was broken by my last pull request. Arik continues to work on TDLS
and Luca solved a few issues in CT-Kill. Eyal keeps digging into rate scaling code, more
to come soon. Besides this, nothing really special here.

Please pull, thanks!

The following changes since commit 712b24adc105518f7cbbb6f9f353efea48954bb9:

  iwlwifi: mvm: clean up AUX station handling (2014-09-03 22:49:13 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git for-john

for you to fetch changes up to f991e17ba2584e2be66476cc468f19769efd55cc:

  iwlwifi: mvm: align CSA GO NOA time event naming with the firmware (2014-09-14 22:02:24 +0300)

----------------------------------------------------------------
Arik Nemtsov (2):
(Continue reading)

Hauke Mehrtens | 14 Sep 23:09 2014
Picon

[PATCH 1/5] b43: tell the ucode the mac capabilities

This is based on code form brcmsmac.

Signed-off-by: Hauke Mehrtens <hauke@...>
---
 drivers/net/wireless/b43/b43.h  |  3 +++
 drivers/net/wireless/b43/main.c | 10 ++++++++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index 95a9433..018ed5f 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
 <at>  <at>  -45,6 +45,7  <at>  <at> 
 #define B43_MMIO_RAM_DATA		0x134
 #define B43_MMIO_PS_STATUS		0x140
 #define B43_MMIO_RADIO_HWENABLED_HI	0x158
+#define B43_MMIO_MAC_HW_CAP		0x15C	/* MAC capabilities (corerev >= 13) */
 #define B43_MMIO_SHM_CONTROL		0x160
 #define B43_MMIO_SHM_DATA		0x164
 #define B43_MMIO_SHM_DATA_UNALIGNED	0x166
 <at>  <at>  -253,6 +254,8  <at>  <at>  enum {
 #define B43_SHM_SH_CHAN			0x00A0	/* Current channel (low 8bit only) */
 #define  B43_SHM_SH_CHAN_5GHZ		0x0100	/* Bit set, if 5 Ghz channel */
 #define  B43_SHM_SH_CHAN_40MHZ		0x0200	/* Bit set, if 40 Mhz channel width */
+#define B43_SHM_SH_MACHW_L		0x00C0	/* Location where the ucode expects the MAC capabilities */
+#define B43_SHM_SH_MACHW_H		0x00C2	/* Location where the ucode expects the MAC capabilities */
 #define B43_SHM_SH_HOSTF5		0x00D4	/* Hostflags 5 for ucode options */
 #define B43_SHM_SH_BCMCFIFOID		0x0108	/* Last posted cookie to the bcast/mcast FIFO */
 /* TSSI information */
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
(Continue reading)


Gmane