Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: [PATCH] b43: Always use block-I/O for the PIO data registers
From: Albert Herranz @ 2009-09-28 22:30 UTC (permalink / raw)
  To: Michael Buesch, John W. Linville; +Cc: Broadcom Wireless, linux-wireless
In-Reply-To: <200909231851.22110.mb@bu3sch.de>

Michael Buesch wrote:
> On SDIO the PIO data register seems to be hardwired to LE. So
> the MACCTL bit has no effect on the endianness.
> So also use block-I/O for the last word of the packet. block-I/O is always LE.
> 
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
> 
> ---
> 
> 
> Index: wireless-testing/drivers/net/wireless/b43/pio.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/pio.c    2009-09-10 20:14:37.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/b43/pio.c    2009-09-10 21:08:11.000000000 +0200
> @@ -340,10 +340,15 @@ static u16 tx_write_2byte_queue(struct b
>              q->mmio_base + B43_PIO_TXDATA,
>              sizeof(u16));
>      if (data_len & 1) {
> +        u8 tail[2] = { 0, };
> +
>          /* Write the last byte. */
>          ctl &= ~B43_PIO_TXCTL_WRITEHI;
>          b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
> -        b43_piotx_write16(q, B43_PIO_TXDATA, data[data_len - 1]);
> +        tail[0] = data[data_len - 1];
> +        ssb_block_write(dev->dev, tail, 2,
> +                q->mmio_base + B43_PIO_TXDATA,
> +                sizeof(u16));
>      }
>  
>      return ctl;
> @@ -386,26 +391,31 @@ static u32 tx_write_4byte_queue(struct b
>              q->mmio_base + B43_PIO8_TXDATA,
>              sizeof(u32));
>      if (data_len & 3) {
> -        u32 value = 0;
> +        u8 tail[4] = { 0, };
>  
>          /* Write the last few bytes. */
>          ctl &= ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
>               B43_PIO8_TXCTL_24_31);
> -        data = &(data[data_len - 1]);
>          switch (data_len & 3) {
>          case 3:
> -            ctl |= B43_PIO8_TXCTL_16_23;
> -            value |= (u32)(*data) << 16;
> -            data--;
> +            ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
> +            tail[0] = data[data_len - 3];
> +            tail[1] = data[data_len - 2];
> +            tail[2] = data[data_len - 1];
> +            break;
>          case 2:
>              ctl |= B43_PIO8_TXCTL_8_15;
> -            value |= (u32)(*data) << 8;
> -            data--;
> +            tail[0] = data[data_len - 2];
> +            tail[1] = data[data_len - 1];
> +            break;
>          case 1:
> -            value |= (u32)(*data);
> +            tail[0] = data[data_len - 1];
> +            break;
>          }
>          b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
> -        b43_piotx_write32(q, B43_PIO8_TXDATA, value);
> +        ssb_block_write(dev->dev, tail, 4,
> +                q->mmio_base + B43_PIO8_TXDATA,
> +                sizeof(u32));
>      }
>  
>      return ctl;
> @@ -693,21 +703,25 @@ data_ready:
>                     q->mmio_base + B43_PIO8_RXDATA,
>                     sizeof(u32));
>          if (len & 3) {
> -            u32 value;
> -            char *data;
> +            u8 tail[4] = { 0, };
>  
>              /* Read the last few bytes. */
> -            value = b43_piorx_read32(q, B43_PIO8_RXDATA);
> -            data = &(skb->data[len + padding - 1]);
> +            ssb_block_read(dev->dev, tail, 4,
> +                       q->mmio_base + B43_PIO8_RXDATA,
> +                       sizeof(u32));
>              switch (len & 3) {
>              case 3:
> -                *data = (value >> 16);
> -                data--;
> +                skb->data[len + padding - 3] = tail[0];
> +                skb->data[len + padding - 2] = tail[1];
> +                skb->data[len + padding - 1] = tail[2];
> +                break;
>              case 2:
> -                *data = (value >> 8);
> -                data--;
> +                skb->data[len + padding - 2] = tail[0];
> +                skb->data[len + padding - 1] = tail[1];
> +                break;
>              case 1:
> -                *data = value;
> +                skb->data[len + padding - 1] = tail[0];
> +                break;
>              }
>          }
>      } else {
> @@ -715,11 +729,13 @@ data_ready:
>                     q->mmio_base + B43_PIO_RXDATA,
>                     sizeof(u16));
>          if (len & 1) {
> -            u16 value;
> +            u8 tail[2] = { 0, };
>  
>              /* Read the last byte. */
> -            value = b43_piorx_read16(q, B43_PIO_RXDATA);
> -            skb->data[len + padding - 1] = value;
> +            ssb_block_read(dev->dev, tail, 2,
> +                       q->mmio_base + B43_PIO_RXDATA,
> +                       sizeof(u16));
> +            skb->data[len + padding - 1] = tail[0];
>          }
>      }
>  
> 

Without this patch, the last bytes of data sent/received to/from PIO FIFOs on SDIO-based cards get "swizzled" when its length is not multiple of 4 bytes.

Tested-by: Albert Herranz <albert_herranz@yahoo.es>


      

^ permalink raw reply

* ath5k, wifi enable hotkeys
From: Richard Zidlicky @ 2009-09-28 22:23 UTC (permalink / raw)
  To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090705123105.GE2132@hash.localnet>

On Sun, Jul 05, 2009 at 08:31:05AM -0400, Bob Copeland wrote:

Hi,


> Try latest wireless-testing or 2.6.31-rc1; there may already be a fix
> for your hardware thanks to recently added rfkill support.

got around to give 2.6.30* more testing. LED now works nicely but that is about the
only thing that works.

Tried computers linked in Ad-Hoc mode with WEP. 2.6.30 and 2.6.31.1 work nicely
on the other end.

On the ath5k end it seems like 2.6.31 choked after resume from suspend or when interface 
was reconfigured. 

2.6.31.1 does not work at all on this netbook. LED indicates activity but network does
not get associated. "iwlist scan" does display available networks.

After having tried 2.6.31.1 I have to cold-boot 2.6.30.x to get the ath5k working again,
simple reboot does not do it.

> 
> > Also, while the hotkey works how do query the current on/off status of it 
> > in Linux?
> 
> There's the /dev/rfkill device (see http://git.sipsolutions.net/rfkill.git)
> and I believe there are files under /sys/ as well which show the state but
> I don't have the details handy (/sys/class/rfkill/xxx/state?).

has that been merged into 2.6.31* ? 

The /sys/.../rfkill files are there but could not figure out anything that changes 
when hitting the hotkey.

Besides, I would think the LED will indicate rfkill status?

Richard

^ permalink raw reply

* Firmware versioning best practices
From: Luis R. Rodriguez @ 2009-09-28 22:17 UTC (permalink / raw)
  To: linux-wireless
  Cc: reinette chatre, Kalle Valo, Johannes Berg, Christian Lamparter,
	Bob Copeland

The ath_hif_usb driver will require the ar9271 firmware file but in
the future an open firmware might become available. The ar9170 driver
already is under the same situation already: a closed firmware is
available but an open firmware can be used, only thing is ar9170 uses
the same firmware name for both. We *could* change ar9170 to use the
Intel practice of tagging a version at the end of each firmware
release, like ar9170-1.fw but ar9170 originally was implemented with a
2-stage firmware requirement and so ar9170-1.fw is already taken.

ar9170 still needs a solution for the different firmwares, once we
start supporting the open firmware through some sort of release but
I'd like to address ath_hif_usb now early so that we don't run into
these snags and use some decent convention that is easy to follow.

As I noted above, Intel seems to use the device-1.fw, device-2.fw
naming convention. Is this the best approach? Or shall we have the
same firmware filename and simply query the firmware for a map of
capabilities? Any other ideas?

  Luis

^ permalink raw reply

* Re: Question on general wireless testing tree compilation.
From: Hin-Tak Leung @ 2009-09-28 21:52 UTC (permalink / raw)
  To: Balaji Ravindran; +Cc: Linux Wireless
In-Reply-To: <16D9C5FD-4A2A-4061-9C26-FF5C0B0CDFBA@w1an.in>

On Fri, Sep 25, 2009 at 6:21 AM, Balaji Ravindran <b@w1an.in> wrote:
> Hi Everyone,
>
> Sorry for a very amateur question. Could anyone just help me get started
> with compiling the linux kernel from the wireless-testing tree? I just
> pulled the local wireless-testing repo, trying to navigate through the code,
> and wanted to compile the kernel, and to boot up to it. Could anyone just
> help me get started?
>
> I followed the instructions from
> http://www.cyberciti.biz/tips/compiling-linux-kernel-26.html
> and ended up with a compile error in 'make', while trying to create the
> bzimage. (error is on make: initramfs_data.cpi.o failed)
>
> Is there any other easy way to compile the kernel/debug.
>
>
> Thanks
>
> Balaji R
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

As the other replier has already stated, including the last few lines
of the message before the error would be nice.

Also, if you haven't built your own kernel before, it is probably
better to start from a known configuration rather than from scratch.
While all the tutorial, etc tells you to do 'make mrproper ; make
menuconfig/xconfig; make' , there are occasionally some missing
dependencies which aren't explicitly hooked up, so it might be easier
to do, instead of make menuconfig/xconfig, in the middle, copy your
distro's config (or your current running kernel's config) from either
/boot/config-* (packaged from your distro) or /proc/config.gz (for a
kernel which remembers its own config - it is a kernel config opton),
to .config in your source tree, run make oldconfig (which only ask
your questions about *difference* between the tree and the running
kernel), before running make menuconfig/xconfig. This way, you are
starting from a valid and know-working configuration for your
hardware/archecture.

Also, compat-wireless (which just replaces the wireless-related kernel
modules) is sometimes a quicker/easier alternative to the whole
wireless-testing.

^ permalink raw reply

* Re: pull request: wireless-2.6 2009-09-28
From: David Miller @ 2009-09-28 21:51 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090928214047.GF4737@tuxdriver.com>

From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 28 Sep 2009 17:40:48 -0400

> There are number of small fixes to core wireless infrastructure from
> Johannes Berg.  These have been bounced around on the list quite a bit
> during the last several days, so I think they are solid.  Also included
> is one that improves some debugging messages. 
> 
> There are a few fixes for the iwlwifi family of drivers, including a
> buffer overrun, a memory leak, and another debugging message fix.
> 
> Arjan showed-up with a bounds checking fix in some ancient wext code.  I
> included it due to the potential security implications.
> 
> The sony-laptop fixes may seem a bit out of place, but they are related
> to rfkill.  Also, they are "Acked-by: Mattia Dongili <malattia@linux.it>",
> who is the listed maintainer for that code.  I put them at the end, so
> if you want you can pull from 8f1546cadf7ac5e9a40d54089a1c7302264ec49b
> instead of master.
> 
> Please let me know if there are problems!

Pulled, thanks a lot John!

^ permalink raw reply

* pull request: wireless-2.6 2009-09-28
From: John W. Linville @ 2009-09-28 21:40 UTC (permalink / raw)
  To: davem; +Cc: linux-wireless, netdev, linux-kernel

Dave,

This group of fixes is intended for the 2.6.32 train...

There are number of small fixes to core wireless infrastructure from
Johannes Berg.  These have been bounced around on the list quite a bit
during the last several days, so I think they are solid.  Also included
is one that improves some debugging messages. 

There are a few fixes for the iwlwifi family of drivers, including a
buffer overrun, a memory leak, and another debugging message fix.

Arjan showed-up with a bounds checking fix in some ancient wext code.  I
included it due to the potential security implications.

The sony-laptop fixes may seem a bit out of place, but they are related
to rfkill.  Also, they are "Acked-by: Mattia Dongili <malattia@linux.it>",
who is the listed maintainer for that code.  I put them at the end, so
if you want you can pull from 8f1546cadf7ac5e9a40d54089a1c7302264ec49b
instead of master.

Please let me know if there are problems!

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/

---

The following changes since commit d1f8297a96b0d70f17704296a6666468f2087ce6:
  Sascha Hlusiak (1):
        Revert "sit: stateless autoconf for isatap"

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master

Alan Jenkins (2):
      sony-laptop: check for rfkill hard block at load time
      sony-laptop: re-read the rfkill state when resuming from suspend

Arjan van de Ven (1):
      wext: Add bound checks for copy_from_user

Johannes Berg (5):
      cfg80211: wext: don't display BSSID unless associated
      cfg80211: don't set privacy w/o key
      cfg80211: always get BSS
      mac80211: improve/fix mlme messages
      wext: add back wireless/ dir in sysfs for cfg80211 interfaces

Reinette Chatre (3):
      iwlwifi: fix debugfs buffer handling
      iwlwifi: fix memory leak in command queue handling
      iwlwifi: fix 3945 ucode info retrieval after failure

 drivers/net/wireless/iwlwifi/iwl-1000.c     |    2 +
 drivers/net/wireless/iwlwifi/iwl-3945.c     |    2 +
 drivers/net/wireless/iwlwifi/iwl-3945.h     |    2 +
 drivers/net/wireless/iwlwifi/iwl-4965.c     |    2 +
 drivers/net/wireless/iwlwifi/iwl-5000.c     |    4 +
 drivers/net/wireless/iwlwifi/iwl-6000.c     |    2 +
 drivers/net/wireless/iwlwifi/iwl-agn.c      |  185 ++++++++++++++++++++++++++
 drivers/net/wireless/iwlwifi/iwl-core.c     |  187 +--------------------------
 drivers/net/wireless/iwlwifi/iwl-core.h     |   14 ++
 drivers/net/wireless/iwlwifi/iwl-debugfs.c  |    8 +-
 drivers/net/wireless/iwlwifi/iwl-tx.c       |    6 +
 drivers/net/wireless/iwlwifi/iwl3945-base.c |   31 ++---
 drivers/platform/x86/sony-laptop.c          |    9 ++
 include/net/wext.h                          |    1 +
 net/core/net-sysfs.c                        |   12 +-
 net/mac80211/mlme.c                         |   18 ++--
 net/wireless/sme.c                          |    5 +-
 net/wireless/wext-sme.c                     |    8 +-
 net/wireless/wext.c                         |   11 +-
 19 files changed, 274 insertions(+), 235 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index a95caa0..2716b91 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -99,6 +99,8 @@ static struct iwl_lib_ops iwl1000_lib = {
 	.setup_deferred_work = iwl5000_setup_deferred_work,
 	.is_valid_rtc_data_addr = iwl5000_hw_valid_rtc_data_addr,
 	.load_ucode = iwl5000_load_ucode,
+	.dump_nic_event_log = iwl_dump_nic_event_log,
+	.dump_nic_error_log = iwl_dump_nic_error_log,
 	.init_alive_start = iwl5000_init_alive_start,
 	.alive_notify = iwl5000_alive_notify,
 	.send_tx_power = iwl5000_send_tx_power,
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index e9a685d..e70c5b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2839,6 +2839,8 @@ static struct iwl_lib_ops iwl3945_lib = {
 	.txq_free_tfd = iwl3945_hw_txq_free_tfd,
 	.txq_init = iwl3945_hw_tx_queue_init,
 	.load_ucode = iwl3945_load_bsm,
+	.dump_nic_event_log = iwl3945_dump_nic_event_log,
+	.dump_nic_error_log = iwl3945_dump_nic_error_log,
 	.apm_ops = {
 		.init = iwl3945_apm_init,
 		.reset = iwl3945_apm_reset,
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.h b/drivers/net/wireless/iwlwifi/iwl-3945.h
index f240369..21679bf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.h
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.h
@@ -209,6 +209,8 @@ extern int __must_check iwl3945_send_cmd(struct iwl_priv *priv,
 					 struct iwl_host_cmd *cmd);
 extern unsigned int iwl3945_fill_beacon_frame(struct iwl_priv *priv,
 					struct ieee80211_hdr *hdr,int left);
+extern void iwl3945_dump_nic_event_log(struct iwl_priv *priv);
+extern void iwl3945_dump_nic_error_log(struct iwl_priv *priv);
 
 /*
  * Currently used by iwl-3945-rs... look at restructuring so that it doesn't
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 3259b88..a22a050 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2298,6 +2298,8 @@ static struct iwl_lib_ops iwl4965_lib = {
 	.alive_notify = iwl4965_alive_notify,
 	.init_alive_start = iwl4965_init_alive_start,
 	.load_ucode = iwl4965_load_bsm,
+	.dump_nic_event_log = iwl_dump_nic_event_log,
+	.dump_nic_error_log = iwl_dump_nic_error_log,
 	.apm_ops = {
 		.init = iwl4965_apm_init,
 		.reset = iwl4965_apm_reset,
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index a6391c7..eb08f44 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -1535,6 +1535,8 @@ struct iwl_lib_ops iwl5000_lib = {
 	.rx_handler_setup = iwl5000_rx_handler_setup,
 	.setup_deferred_work = iwl5000_setup_deferred_work,
 	.is_valid_rtc_data_addr = iwl5000_hw_valid_rtc_data_addr,
+	.dump_nic_event_log = iwl_dump_nic_event_log,
+	.dump_nic_error_log = iwl_dump_nic_error_log,
 	.load_ucode = iwl5000_load_ucode,
 	.init_alive_start = iwl5000_init_alive_start,
 	.alive_notify = iwl5000_alive_notify,
@@ -1585,6 +1587,8 @@ static struct iwl_lib_ops iwl5150_lib = {
 	.rx_handler_setup = iwl5000_rx_handler_setup,
 	.setup_deferred_work = iwl5000_setup_deferred_work,
 	.is_valid_rtc_data_addr = iwl5000_hw_valid_rtc_data_addr,
+	.dump_nic_event_log = iwl_dump_nic_event_log,
+	.dump_nic_error_log = iwl_dump_nic_error_log,
 	.load_ucode = iwl5000_load_ucode,
 	.init_alive_start = iwl5000_init_alive_start,
 	.alive_notify = iwl5000_alive_notify,
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 82b9c93..c295b8e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -100,6 +100,8 @@ static struct iwl_lib_ops iwl6000_lib = {
 	.setup_deferred_work = iwl5000_setup_deferred_work,
 	.is_valid_rtc_data_addr = iwl5000_hw_valid_rtc_data_addr,
 	.load_ucode = iwl5000_load_ucode,
+	.dump_nic_event_log = iwl_dump_nic_event_log,
+	.dump_nic_error_log = iwl_dump_nic_error_log,
 	.init_alive_start = iwl5000_init_alive_start,
 	.alive_notify = iwl5000_alive_notify,
 	.send_tx_power = iwl5000_send_tx_power,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 00457bf..cdc07c4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1526,6 +1526,191 @@ static int iwl_read_ucode(struct iwl_priv *priv)
 	return ret;
 }
 
+#ifdef CONFIG_IWLWIFI_DEBUG
+static const char *desc_lookup_text[] = {
+	"OK",
+	"FAIL",
+	"BAD_PARAM",
+	"BAD_CHECKSUM",
+	"NMI_INTERRUPT_WDG",
+	"SYSASSERT",
+	"FATAL_ERROR",
+	"BAD_COMMAND",
+	"HW_ERROR_TUNE_LOCK",
+	"HW_ERROR_TEMPERATURE",
+	"ILLEGAL_CHAN_FREQ",
+	"VCC_NOT_STABLE",
+	"FH_ERROR",
+	"NMI_INTERRUPT_HOST",
+	"NMI_INTERRUPT_ACTION_PT",
+	"NMI_INTERRUPT_UNKNOWN",
+	"UCODE_VERSION_MISMATCH",
+	"HW_ERROR_ABS_LOCK",
+	"HW_ERROR_CAL_LOCK_FAIL",
+	"NMI_INTERRUPT_INST_ACTION_PT",
+	"NMI_INTERRUPT_DATA_ACTION_PT",
+	"NMI_TRM_HW_ER",
+	"NMI_INTERRUPT_TRM",
+	"NMI_INTERRUPT_BREAK_POINT"
+	"DEBUG_0",
+	"DEBUG_1",
+	"DEBUG_2",
+	"DEBUG_3",
+	"UNKNOWN"
+};
+
+static const char *desc_lookup(int i)
+{
+	int max = ARRAY_SIZE(desc_lookup_text) - 1;
+
+	if (i < 0 || i > max)
+		i = max;
+
+	return desc_lookup_text[i];
+}
+
+#define ERROR_START_OFFSET  (1 * sizeof(u32))
+#define ERROR_ELEM_SIZE     (7 * sizeof(u32))
+
+void iwl_dump_nic_error_log(struct iwl_priv *priv)
+{
+	u32 data2, line;
+	u32 desc, time, count, base, data1;
+	u32 blink1, blink2, ilink1, ilink2;
+
+	if (priv->ucode_type == UCODE_INIT)
+		base = le32_to_cpu(priv->card_alive_init.error_event_table_ptr);
+	else
+		base = le32_to_cpu(priv->card_alive.error_event_table_ptr);
+
+	if (!priv->cfg->ops->lib->is_valid_rtc_data_addr(base)) {
+		IWL_ERR(priv, "Not valid error log pointer 0x%08X\n", base);
+		return;
+	}
+
+	count = iwl_read_targ_mem(priv, base);
+
+	if (ERROR_START_OFFSET <= count * ERROR_ELEM_SIZE) {
+		IWL_ERR(priv, "Start IWL Error Log Dump:\n");
+		IWL_ERR(priv, "Status: 0x%08lX, count: %d\n",
+			priv->status, count);
+	}
+
+	desc = iwl_read_targ_mem(priv, base + 1 * sizeof(u32));
+	blink1 = iwl_read_targ_mem(priv, base + 3 * sizeof(u32));
+	blink2 = iwl_read_targ_mem(priv, base + 4 * sizeof(u32));
+	ilink1 = iwl_read_targ_mem(priv, base + 5 * sizeof(u32));
+	ilink2 = iwl_read_targ_mem(priv, base + 6 * sizeof(u32));
+	data1 = iwl_read_targ_mem(priv, base + 7 * sizeof(u32));
+	data2 = iwl_read_targ_mem(priv, base + 8 * sizeof(u32));
+	line = iwl_read_targ_mem(priv, base + 9 * sizeof(u32));
+	time = iwl_read_targ_mem(priv, base + 11 * sizeof(u32));
+
+	IWL_ERR(priv, "Desc                               Time       "
+		"data1      data2      line\n");
+	IWL_ERR(priv, "%-28s (#%02d) %010u 0x%08X 0x%08X %u\n",
+		desc_lookup(desc), desc, time, data1, data2, line);
+	IWL_ERR(priv, "blink1  blink2  ilink1  ilink2\n");
+	IWL_ERR(priv, "0x%05X 0x%05X 0x%05X 0x%05X\n", blink1, blink2,
+		ilink1, ilink2);
+
+}
+
+#define EVENT_START_OFFSET  (4 * sizeof(u32))
+
+/**
+ * iwl_print_event_log - Dump error event log to syslog
+ *
+ */
+static void iwl_print_event_log(struct iwl_priv *priv, u32 start_idx,
+				u32 num_events, u32 mode)
+{
+	u32 i;
+	u32 base;       /* SRAM byte address of event log header */
+	u32 event_size; /* 2 u32s, or 3 u32s if timestamp recorded */
+	u32 ptr;        /* SRAM byte address of log data */
+	u32 ev, time, data; /* event log data */
+
+	if (num_events == 0)
+		return;
+	if (priv->ucode_type == UCODE_INIT)
+		base = le32_to_cpu(priv->card_alive_init.log_event_table_ptr);
+	else
+		base = le32_to_cpu(priv->card_alive.log_event_table_ptr);
+
+	if (mode == 0)
+		event_size = 2 * sizeof(u32);
+	else
+		event_size = 3 * sizeof(u32);
+
+	ptr = base + EVENT_START_OFFSET + (start_idx * event_size);
+
+	/* "time" is actually "data" for mode 0 (no timestamp).
+	* place event id # at far right for easier visual parsing. */
+	for (i = 0; i < num_events; i++) {
+		ev = iwl_read_targ_mem(priv, ptr);
+		ptr += sizeof(u32);
+		time = iwl_read_targ_mem(priv, ptr);
+		ptr += sizeof(u32);
+		if (mode == 0) {
+			/* data, ev */
+			IWL_ERR(priv, "EVT_LOG:0x%08x:%04u\n", time, ev);
+		} else {
+			data = iwl_read_targ_mem(priv, ptr);
+			ptr += sizeof(u32);
+			IWL_ERR(priv, "EVT_LOGT:%010u:0x%08x:%04u\n",
+					time, data, ev);
+		}
+	}
+}
+
+void iwl_dump_nic_event_log(struct iwl_priv *priv)
+{
+	u32 base;       /* SRAM byte address of event log header */
+	u32 capacity;   /* event log capacity in # entries */
+	u32 mode;       /* 0 - no timestamp, 1 - timestamp recorded */
+	u32 num_wraps;  /* # times uCode wrapped to top of log */
+	u32 next_entry; /* index of next entry to be written by uCode */
+	u32 size;       /* # entries that we'll print */
+
+	if (priv->ucode_type == UCODE_INIT)
+		base = le32_to_cpu(priv->card_alive_init.log_event_table_ptr);
+	else
+		base = le32_to_cpu(priv->card_alive.log_event_table_ptr);
+
+	if (!priv->cfg->ops->lib->is_valid_rtc_data_addr(base)) {
+		IWL_ERR(priv, "Invalid event log pointer 0x%08X\n", base);
+		return;
+	}
+
+	/* event log header */
+	capacity = iwl_read_targ_mem(priv, base);
+	mode = iwl_read_targ_mem(priv, base + (1 * sizeof(u32)));
+	num_wraps = iwl_read_targ_mem(priv, base + (2 * sizeof(u32)));
+	next_entry = iwl_read_targ_mem(priv, base + (3 * sizeof(u32)));
+
+	size = num_wraps ? capacity : next_entry;
+
+	/* bail out if nothing in log */
+	if (size == 0) {
+		IWL_ERR(priv, "Start IWL Event Log Dump: nothing in log\n");
+		return;
+	}
+
+	IWL_ERR(priv, "Start IWL Event Log Dump: display count %d, wraps %d\n",
+			size, num_wraps);
+
+	/* if uCode has wrapped back to top of log, start at the oldest entry,
+	 * i.e the next one that uCode would fill. */
+	if (num_wraps)
+		iwl_print_event_log(priv, next_entry,
+					capacity - next_entry, mode);
+	/* (then/else) start at top of log */
+	iwl_print_event_log(priv, 0, next_entry, mode);
+
+}
+#endif
+
 /**
  * iwl_alive_start - called after REPLY_ALIVE notification received
  *                   from protocol/runtime uCode (initialization uCode's
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index fd26c0d..484d5c1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1309,189 +1309,6 @@ static void iwl_print_rx_config_cmd(struct iwl_priv *priv)
 	IWL_DEBUG_RADIO(priv, "u8[6] bssid_addr: %pM\n", rxon->bssid_addr);
 	IWL_DEBUG_RADIO(priv, "u16 assoc_id: 0x%x\n", le16_to_cpu(rxon->assoc_id));
 }
-
-static const char *desc_lookup_text[] = {
-	"OK",
-	"FAIL",
-	"BAD_PARAM",
-	"BAD_CHECKSUM",
-	"NMI_INTERRUPT_WDG",
-	"SYSASSERT",
-	"FATAL_ERROR",
-	"BAD_COMMAND",
-	"HW_ERROR_TUNE_LOCK",
-	"HW_ERROR_TEMPERATURE",
-	"ILLEGAL_CHAN_FREQ",
-	"VCC_NOT_STABLE",
-	"FH_ERROR",
-	"NMI_INTERRUPT_HOST",
-	"NMI_INTERRUPT_ACTION_PT",
-	"NMI_INTERRUPT_UNKNOWN",
-	"UCODE_VERSION_MISMATCH",
-	"HW_ERROR_ABS_LOCK",
-	"HW_ERROR_CAL_LOCK_FAIL",
-	"NMI_INTERRUPT_INST_ACTION_PT",
-	"NMI_INTERRUPT_DATA_ACTION_PT",
-	"NMI_TRM_HW_ER",
-	"NMI_INTERRUPT_TRM",
-	"NMI_INTERRUPT_BREAK_POINT"
-	"DEBUG_0",
-	"DEBUG_1",
-	"DEBUG_2",
-	"DEBUG_3",
-	"UNKNOWN"
-};
-
-static const char *desc_lookup(int i)
-{
-	int max = ARRAY_SIZE(desc_lookup_text) - 1;
-
-	if (i < 0 || i > max)
-		i = max;
-
-	return desc_lookup_text[i];
-}
-
-#define ERROR_START_OFFSET  (1 * sizeof(u32))
-#define ERROR_ELEM_SIZE     (7 * sizeof(u32))
-
-static void iwl_dump_nic_error_log(struct iwl_priv *priv)
-{
-	u32 data2, line;
-	u32 desc, time, count, base, data1;
-	u32 blink1, blink2, ilink1, ilink2;
-
-	if (priv->ucode_type == UCODE_INIT)
-		base = le32_to_cpu(priv->card_alive_init.error_event_table_ptr);
-	else
-		base = le32_to_cpu(priv->card_alive.error_event_table_ptr);
-
-	if (!priv->cfg->ops->lib->is_valid_rtc_data_addr(base)) {
-		IWL_ERR(priv, "Not valid error log pointer 0x%08X\n", base);
-		return;
-	}
-
-	count = iwl_read_targ_mem(priv, base);
-
-	if (ERROR_START_OFFSET <= count * ERROR_ELEM_SIZE) {
-		IWL_ERR(priv, "Start IWL Error Log Dump:\n");
-		IWL_ERR(priv, "Status: 0x%08lX, count: %d\n",
-			priv->status, count);
-	}
-
-	desc = iwl_read_targ_mem(priv, base + 1 * sizeof(u32));
-	blink1 = iwl_read_targ_mem(priv, base + 3 * sizeof(u32));
-	blink2 = iwl_read_targ_mem(priv, base + 4 * sizeof(u32));
-	ilink1 = iwl_read_targ_mem(priv, base + 5 * sizeof(u32));
-	ilink2 = iwl_read_targ_mem(priv, base + 6 * sizeof(u32));
-	data1 = iwl_read_targ_mem(priv, base + 7 * sizeof(u32));
-	data2 = iwl_read_targ_mem(priv, base + 8 * sizeof(u32));
-	line = iwl_read_targ_mem(priv, base + 9 * sizeof(u32));
-	time = iwl_read_targ_mem(priv, base + 11 * sizeof(u32));
-
-	IWL_ERR(priv, "Desc                               Time       "
-		"data1      data2      line\n");
-	IWL_ERR(priv, "%-28s (#%02d) %010u 0x%08X 0x%08X %u\n",
-		desc_lookup(desc), desc, time, data1, data2, line);
-	IWL_ERR(priv, "blink1  blink2  ilink1  ilink2\n");
-	IWL_ERR(priv, "0x%05X 0x%05X 0x%05X 0x%05X\n", blink1, blink2,
-		ilink1, ilink2);
-
-}
-
-#define EVENT_START_OFFSET  (4 * sizeof(u32))
-
-/**
- * iwl_print_event_log - Dump error event log to syslog
- *
- */
-static void iwl_print_event_log(struct iwl_priv *priv, u32 start_idx,
-				u32 num_events, u32 mode)
-{
-	u32 i;
-	u32 base;       /* SRAM byte address of event log header */
-	u32 event_size; /* 2 u32s, or 3 u32s if timestamp recorded */
-	u32 ptr;        /* SRAM byte address of log data */
-	u32 ev, time, data; /* event log data */
-
-	if (num_events == 0)
-		return;
-	if (priv->ucode_type == UCODE_INIT)
-		base = le32_to_cpu(priv->card_alive_init.log_event_table_ptr);
-	else
-		base = le32_to_cpu(priv->card_alive.log_event_table_ptr);
-
-	if (mode == 0)
-		event_size = 2 * sizeof(u32);
-	else
-		event_size = 3 * sizeof(u32);
-
-	ptr = base + EVENT_START_OFFSET + (start_idx * event_size);
-
-	/* "time" is actually "data" for mode 0 (no timestamp).
-	* place event id # at far right for easier visual parsing. */
-	for (i = 0; i < num_events; i++) {
-		ev = iwl_read_targ_mem(priv, ptr);
-		ptr += sizeof(u32);
-		time = iwl_read_targ_mem(priv, ptr);
-		ptr += sizeof(u32);
-		if (mode == 0) {
-			/* data, ev */
-			IWL_ERR(priv, "EVT_LOG:0x%08x:%04u\n", time, ev);
-		} else {
-			data = iwl_read_targ_mem(priv, ptr);
-			ptr += sizeof(u32);
-			IWL_ERR(priv, "EVT_LOGT:%010u:0x%08x:%04u\n",
-					time, data, ev);
-		}
-	}
-}
-
-void iwl_dump_nic_event_log(struct iwl_priv *priv)
-{
-	u32 base;       /* SRAM byte address of event log header */
-	u32 capacity;   /* event log capacity in # entries */
-	u32 mode;       /* 0 - no timestamp, 1 - timestamp recorded */
-	u32 num_wraps;  /* # times uCode wrapped to top of log */
-	u32 next_entry; /* index of next entry to be written by uCode */
-	u32 size;       /* # entries that we'll print */
-
-	if (priv->ucode_type == UCODE_INIT)
-		base = le32_to_cpu(priv->card_alive_init.log_event_table_ptr);
-	else
-		base = le32_to_cpu(priv->card_alive.log_event_table_ptr);
-
-	if (!priv->cfg->ops->lib->is_valid_rtc_data_addr(base)) {
-		IWL_ERR(priv, "Invalid event log pointer 0x%08X\n", base);
-		return;
-	}
-
-	/* event log header */
-	capacity = iwl_read_targ_mem(priv, base);
-	mode = iwl_read_targ_mem(priv, base + (1 * sizeof(u32)));
-	num_wraps = iwl_read_targ_mem(priv, base + (2 * sizeof(u32)));
-	next_entry = iwl_read_targ_mem(priv, base + (3 * sizeof(u32)));
-
-	size = num_wraps ? capacity : next_entry;
-
-	/* bail out if nothing in log */
-	if (size == 0) {
-		IWL_ERR(priv, "Start IWL Event Log Dump: nothing in log\n");
-		return;
-	}
-
-	IWL_ERR(priv, "Start IWL Event Log Dump: display count %d, wraps %d\n",
-			size, num_wraps);
-
-	/* if uCode has wrapped back to top of log, start at the oldest entry,
-	 * i.e the next one that uCode would fill. */
-	if (num_wraps)
-		iwl_print_event_log(priv, next_entry,
-					capacity - next_entry, mode);
-	/* (then/else) start at top of log */
-	iwl_print_event_log(priv, 0, next_entry, mode);
-
-}
 #endif
 /**
  * iwl_irq_handle_error - called for HW or SW error interrupt from card
@@ -1506,8 +1323,8 @@ void iwl_irq_handle_error(struct iwl_priv *priv)
 
 #ifdef CONFIG_IWLWIFI_DEBUG
 	if (iwl_get_debug_level(priv) & IWL_DL_FW_ERRORS) {
-		iwl_dump_nic_error_log(priv);
-		iwl_dump_nic_event_log(priv);
+		priv->cfg->ops->lib->dump_nic_error_log(priv);
+		priv->cfg->ops->lib->dump_nic_event_log(priv);
 		iwl_print_rx_config_cmd(priv);
 	}
 #endif
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 7ff9ffb..e50103a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -166,6 +166,8 @@ struct iwl_lib_ops {
 	int (*is_valid_rtc_data_addr)(u32 addr);
 	/* 1st ucode load */
 	int (*load_ucode)(struct iwl_priv *priv);
+	void (*dump_nic_event_log)(struct iwl_priv *priv);
+	void (*dump_nic_error_log)(struct iwl_priv *priv);
 	/* power management */
 	struct iwl_apm_ops apm_ops;
 
@@ -540,7 +542,19 @@ int iwl_pci_resume(struct pci_dev *pdev);
 /*****************************************************
 *  Error Handling Debugging
 ******************************************************/
+#ifdef CONFIG_IWLWIFI_DEBUG
 void iwl_dump_nic_event_log(struct iwl_priv *priv);
+void iwl_dump_nic_error_log(struct iwl_priv *priv);
+#else
+static inline void iwl_dump_nic_event_log(struct iwl_priv *priv)
+{
+}
+
+static inline void iwl_dump_nic_error_log(struct iwl_priv *priv)
+{
+}
+#endif
+
 void iwl_clear_isr_stats(struct iwl_priv *priv);
 
 /*****************************************************
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index fb84485..a198bcf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -410,7 +410,7 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
 		pos += scnprintf(buf + pos, buf_size - pos, "0x%.4x ", ofs);
 		hex_dump_to_buffer(ptr + ofs, 16 , 16, 2, buf + pos,
 				   buf_size - pos, 0);
-		pos += strlen(buf);
+		pos += strlen(buf + pos);
 		if (buf_size - pos > 0)
 			buf[pos++] = '\n';
 	}
@@ -436,7 +436,7 @@ static ssize_t iwl_dbgfs_log_event_write(struct file *file,
 	if (sscanf(buf, "%d", &event_log_flag) != 1)
 		return -EFAULT;
 	if (event_log_flag == 1)
-		iwl_dump_nic_event_log(priv);
+		priv->cfg->ops->lib->dump_nic_event_log(priv);
 
 	return count;
 }
@@ -909,7 +909,7 @@ static ssize_t iwl_dbgfs_traffic_log_read(struct file *file,
 						"0x%.4x ", ofs);
 				hex_dump_to_buffer(ptr + ofs, 16, 16, 2,
 						   buf + pos, bufsz - pos, 0);
-				pos += strlen(buf);
+				pos += strlen(buf + pos);
 				if (bufsz - pos > 0)
 					buf[pos++] = '\n';
 			}
@@ -932,7 +932,7 @@ static ssize_t iwl_dbgfs_traffic_log_read(struct file *file,
 						"0x%.4x ", ofs);
 				hex_dump_to_buffer(ptr + ofs, 16, 16, 2,
 						   buf + pos, bufsz - pos, 0);
-				pos += strlen(buf);
+				pos += strlen(buf + pos);
 				if (bufsz - pos > 0)
 					buf[pos++] = '\n';
 			}
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index a7422e5..c189075 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -197,6 +197,12 @@ void iwl_cmd_queue_free(struct iwl_priv *priv)
 		pci_free_consistent(dev, priv->hw_params.tfd_size *
 				    txq->q.n_bd, txq->tfds, txq->q.dma_addr);
 
+	/* deallocate arrays */
+	kfree(txq->cmd);
+	kfree(txq->meta);
+	txq->cmd = NULL;
+	txq->meta = NULL;
+
 	/* 0-fill queue descriptor structure */
 	memset(txq, 0, sizeof(*txq));
 }
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4f2d439..c390dbd 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1481,6 +1481,7 @@ static inline void iwl_synchronize_irq(struct iwl_priv *priv)
 	tasklet_kill(&priv->irq_tasklet);
 }
 
+#ifdef CONFIG_IWLWIFI_DEBUG
 static const char *desc_lookup(int i)
 {
 	switch (i) {
@@ -1504,7 +1505,7 @@ static const char *desc_lookup(int i)
 #define ERROR_START_OFFSET  (1 * sizeof(u32))
 #define ERROR_ELEM_SIZE     (7 * sizeof(u32))
 
-static void iwl3945_dump_nic_error_log(struct iwl_priv *priv)
+void iwl3945_dump_nic_error_log(struct iwl_priv *priv)
 {
 	u32 i;
 	u32 desc, time, count, base, data1;
@@ -1598,7 +1599,7 @@ static void iwl3945_print_event_log(struct iwl_priv *priv, u32 start_idx,
 	}
 }
 
-static void iwl3945_dump_nic_event_log(struct iwl_priv *priv)
+void iwl3945_dump_nic_event_log(struct iwl_priv *priv)
 {
 	u32 base;       /* SRAM byte address of event log header */
 	u32 capacity;   /* event log capacity in # entries */
@@ -1640,6 +1641,16 @@ static void iwl3945_dump_nic_event_log(struct iwl_priv *priv)
 	iwl3945_print_event_log(priv, 0, next_entry, mode);
 
 }
+#else
+void iwl3945_dump_nic_event_log(struct iwl_priv *priv)
+{
+}
+
+void iwl3945_dump_nic_error_log(struct iwl_priv *priv)
+{
+}
+
+#endif
 
 static void iwl3945_irq_tasklet(struct iwl_priv *priv)
 {
@@ -3683,21 +3694,6 @@ static ssize_t dump_error_log(struct device *d,
 
 static DEVICE_ATTR(dump_errors, S_IWUSR, NULL, dump_error_log);
 
-static ssize_t dump_event_log(struct device *d,
-			      struct device_attribute *attr,
-			      const char *buf, size_t count)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-	char *p = (char *)buf;
-
-	if (p[0] == '1')
-		iwl3945_dump_nic_event_log(priv);
-
-	return strnlen(buf, count);
-}
-
-static DEVICE_ATTR(dump_events, S_IWUSR, NULL, dump_event_log);
-
 /*****************************************************************************
  *
  * driver setup and tear down
@@ -3742,7 +3738,6 @@ static struct attribute *iwl3945_sysfs_entries[] = {
 	&dev_attr_antenna.attr,
 	&dev_attr_channels.attr,
 	&dev_attr_dump_errors.attr,
-	&dev_attr_dump_events.attr,
 	&dev_attr_flags.attr,
 	&dev_attr_filter_flags.attr,
 #ifdef CONFIG_IWL3945_SPECTRUM_MEASUREMENT
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index f9f68e0..afdbdaa 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1041,6 +1041,9 @@ static int sony_nc_resume(struct acpi_device *device)
 			sony_backlight_update_status(sony_backlight_device) < 0)
 		printk(KERN_WARNING DRV_PFX "unable to restore brightness level\n");
 
+	/* re-read rfkill state */
+	sony_nc_rfkill_update();
+
 	return 0;
 }
 
@@ -1078,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
 	struct rfkill *rfk;
 	enum rfkill_type type;
 	const char *name;
+	int result;
+	bool hwblock;
 
 	switch (nc_type) {
 	case SONY_WIFI:
@@ -1105,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
 	if (!rfk)
 		return -ENOMEM;
 
+	sony_call_snc_handle(0x124, 0x200, &result);
+	hwblock = !(result & 0x1);
+	rfkill_set_hw_state(rfk, hwblock);
+
 	err = rfkill_register(rfk);
 	if (err) {
 		rfkill_destroy(rfk);
diff --git a/include/net/wext.h b/include/net/wext.h
index 6d76a39..3f2b94d 100644
--- a/include/net/wext.h
+++ b/include/net/wext.h
@@ -14,6 +14,7 @@ extern int wext_handle_ioctl(struct net *net, struct ifreq *ifr, unsigned int cm
 			     void __user *arg);
 extern int compat_wext_handle_ioctl(struct net *net, unsigned int cmd,
 				    unsigned long arg);
+extern struct iw_statistics *get_wireless_stats(struct net_device *dev);
 #else
 static inline int wext_proc_init(struct net *net)
 {
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 7d4c575..821d309 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -16,7 +16,7 @@
 #include <net/sock.h>
 #include <linux/rtnetlink.h>
 #include <linux/wireless.h>
-#include <net/iw_handler.h>
+#include <net/wext.h>
 
 #include "net-sysfs.h"
 
@@ -363,15 +363,13 @@ static ssize_t wireless_show(struct device *d, char *buf,
 					       char *))
 {
 	struct net_device *dev = to_net_dev(d);
-	const struct iw_statistics *iw = NULL;
+	const struct iw_statistics *iw;
 	ssize_t ret = -EINVAL;
 
 	read_lock(&dev_base_lock);
 	if (dev_isalive(dev)) {
-		if (dev->wireless_handlers &&
-		    dev->wireless_handlers->get_wireless_stats)
-			iw = dev->wireless_handlers->get_wireless_stats(dev);
-		if (iw != NULL)
+		iw = get_wireless_stats(dev);
+		if (iw)
 			ret = (*format)(iw, buf);
 	}
 	read_unlock(&dev_base_lock);
@@ -505,7 +503,7 @@ int netdev_register_kobject(struct net_device *net)
 	*groups++ = &netstat_group;
 
 #ifdef CONFIG_WIRELESS_EXT_SYSFS
-	if (net->wireless_handlers && net->wireless_handlers->get_wireless_stats)
+	if (net->wireless_handlers || net->ieee80211_ptr)
 		*groups++ = &wireless_group;
 #endif
 #endif /* CONFIG_SYSFS */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 97a278a..8d26e9b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1388,8 +1388,8 @@ ieee80211_rx_mgmt_disassoc(struct ieee80211_sub_if_data *sdata,
 
 	reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
 
-	printk(KERN_DEBUG "%s: disassociated (Reason: %u)\n",
-			sdata->dev->name, reason_code);
+	printk(KERN_DEBUG "%s: disassociated from %pM (Reason: %u)\n",
+			sdata->dev->name, mgmt->sa, reason_code);
 
 	ieee80211_set_disassoc(sdata, false);
 	return RX_MGMT_CFG80211_DISASSOC;
@@ -1675,7 +1675,7 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
 
 	/* direct probe may be part of the association flow */
 	if (wk && wk->state == IEEE80211_MGD_STATE_PROBE) {
-		printk(KERN_DEBUG "%s direct probe responded\n",
+		printk(KERN_DEBUG "%s: direct probe responded\n",
 		       sdata->dev->name);
 		wk->tries = 0;
 		wk->state = IEEE80211_MGD_STATE_AUTH;
@@ -2502,9 +2502,6 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata,
 	struct ieee80211_mgd_work *wk;
 	const u8 *bssid = NULL;
 
-	printk(KERN_DEBUG "%s: deauthenticating by local choice (reason=%d)\n",
-	       sdata->dev->name, req->reason_code);
-
 	mutex_lock(&ifmgd->mtx);
 
 	if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
@@ -2532,6 +2529,9 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata,
 
 	mutex_unlock(&ifmgd->mtx);
 
+	printk(KERN_DEBUG "%s: deauthenticating from %pM by local choice (reason=%d)\n",
+	       sdata->dev->name, bssid, req->reason_code);
+
 	ieee80211_send_deauth_disassoc(sdata, bssid,
 			IEEE80211_STYPE_DEAUTH, req->reason_code,
 			cookie);
@@ -2545,9 +2545,6 @@ int ieee80211_mgd_disassoc(struct ieee80211_sub_if_data *sdata,
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 
-	printk(KERN_DEBUG "%s: disassociating by local choice (reason=%d)\n",
-	       sdata->dev->name, req->reason_code);
-
 	mutex_lock(&ifmgd->mtx);
 
 	/*
@@ -2561,6 +2558,9 @@ int ieee80211_mgd_disassoc(struct ieee80211_sub_if_data *sdata,
 		return -ENOLINK;
 	}
 
+	printk(KERN_DEBUG "%s: disassociating from %pM by local choice (reason=%d)\n",
+	       sdata->dev->name, req->bss->bssid, req->reason_code);
+
 	ieee80211_set_disassoc(sdata, false);
 
 	mutex_unlock(&ifmgd->mtx);
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 7fae7ee..93c3ed3 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -762,9 +762,8 @@ int __cfg80211_connect(struct cfg80211_registered_device *rdev,
 		wdev->conn->params.ssid = wdev->ssid;
 		wdev->conn->params.ssid_len = connect->ssid_len;
 
-		/* don't care about result -- but fill bssid & channel */
-		if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
-			bss = cfg80211_get_conn_bss(wdev);
+		/* see if we have the bss already */
+		bss = cfg80211_get_conn_bss(wdev);
 
 		wdev->sme_state = CFG80211_SME_CONNECTING;
 		wdev->connect_keys = connkeys;
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index bf72527..5615a88 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -30,7 +30,8 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
 	if (wdev->wext.keys) {
 		wdev->wext.keys->def = wdev->wext.default_key;
 		wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
-		wdev->wext.connect.privacy = true;
+		if (wdev->wext.default_key != -1)
+			wdev->wext.connect.privacy = true;
 	}
 
 	if (!wdev->wext.connect.ssid_len)
@@ -229,8 +230,7 @@ int cfg80211_mgd_wext_giwessid(struct net_device *dev,
 		data->flags = 1;
 		data->length = wdev->wext.connect.ssid_len;
 		memcpy(ssid, wdev->wext.connect.ssid, data->length);
-	} else
-		data->flags = 0;
+	}
 	wdev_unlock(wdev);
 
 	return 0;
@@ -306,8 +306,6 @@ int cfg80211_mgd_wext_giwap(struct net_device *dev,
 	wdev_lock(wdev);
 	if (wdev->current_bss)
 		memcpy(ap_addr->sa_data, wdev->current_bss->pub.bssid, ETH_ALEN);
-	else if (wdev->wext.connect.bssid)
-		memcpy(ap_addr->sa_data, wdev->wext.connect.bssid, ETH_ALEN);
 	else
 		memset(ap_addr->sa_data, 0, ETH_ALEN);
 	wdev_unlock(wdev);
diff --git a/net/wireless/wext.c b/net/wireless/wext.c
index 5b4a0ce..60fe577 100644
--- a/net/wireless/wext.c
+++ b/net/wireless/wext.c
@@ -470,7 +470,7 @@ static iw_handler get_handler(struct net_device *dev, unsigned int cmd)
 /*
  * Get statistics out of the driver
  */
-static struct iw_statistics *get_wireless_stats(struct net_device *dev)
+struct iw_statistics *get_wireless_stats(struct net_device *dev)
 {
 	/* New location */
 	if ((dev->wireless_handlers != NULL) &&
@@ -773,10 +773,13 @@ static int ioctl_standard_iw_point(struct iw_point *iwp, unsigned int cmd,
 			essid_compat = 1;
 		else if (IW_IS_SET(cmd) && (iwp->length != 0)) {
 			char essid[IW_ESSID_MAX_SIZE + 1];
+			unsigned int len;
+			len = iwp->length * descr->token_size;
 
-			err = copy_from_user(essid, iwp->pointer,
-					     iwp->length *
-					     descr->token_size);
+			if (len > IW_ESSID_MAX_SIZE)
+				return -EFAULT;
+
+			err = copy_from_user(essid, iwp->pointer, len);
 			if (err)
 				return -EFAULT;
 
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply related

* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-28 21:00 UTC (permalink / raw)
  To: Tim Gardner
  Cc: Luis Rodriguez, Luis R. Rodriguez, Clyde McPherson,
	Hauke Mehrtens, linux-wireless, bcm43xx-dev@lists.berlios.de
In-Reply-To: <4AC11ED6.2010706@canonical.com>

On Mon, Sep 28, 2009 at 01:38:46PM -0700, Tim Gardner wrote:
> Luis R. Rodriguez wrote:
> > On Mon, Sep 28, 2009 at 01:00:55PM -0700, Tim Gardner wrote:
> >> Luis R. Rodriguez wrote:
> >>> On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
> >>>> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
> >>>>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >>>>>>
> >>>>>>> Bryan Wu wrote:
> >>>>>>>
> >>>>>>>> Mauro Di Domenico wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
> >>>>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
> >>>>>>>>> machine with kernel version 2.6.30-6.
> >>>>>>>>>
> >>>>>>>>> During the boot I experience this problem:
> >>>>>>>>>
> >>>>>>>>> $ dmesg|egrep "b43|ssb"
> >>>>>>>>>
> >>>>>>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
> >>>>>>>>> low) -> IRQ 17
> >>>>>>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
> >>>>>>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
> >>>>>>>>> 0000:06:00.0
> >>>>>>>>> [    6.968981] b43: disagrees about version of symbol
> >>>>>>>>> ssb_device_is_enabled
> >>>>>>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
> >>>>>>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
> >>>>>>>>> [    6.969407] b43: disagrees about version of symbol
> >>>>>>>>> ssb_pcicore_dev_irqvecs_enable
> >>>>>>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
> >>>>>>>>> .....
> >>>>>>>>> ....
> >>>>>>>>> ...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
> >>>>>>>> have
> >>>>>>>> no time to take a deeper look.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
> >>>>>>> 9.04. The problem is that the ssb module is integrated into the
> >>>>>>> initramfs image. The version out of the initramfs image is loaded on
> >>>>>>> startup and not the version of compat-wireless. Running "sudo
> >>>>>>> update-initramfs -u" after installing compat-wireless and restaing the
> >>>>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
> >>>>>>> form default initramfs image or compat-wireless should update the image
> >>>>>>> with the install command. At least the compat-wireless documentation
> >>>>>>> needs an update.
> >>>>>>>
> >>>>>>> Hauke
> >>>>>>>
> >>>>>>> (adding Luis and linux-wireless list)
> >>>>>>>
> >>>>>> Tim, do you guys update the initramfs upon installation of lbm? If a
> >>>>>> user does not use lbm and uses compat-wireless I suppose we need to do
> >>>>>> something similar.
> >>>>>>
> >>>>>>  Luis
> >>>>>> _______________________________________________
> >>>>>> Bcm43xx-dev mailing list
> >>>>>> Bcm43xx-dev@lists.berlios.de
> >>>>>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> >>>>>>
> >>>>> All:
> >>>>> I have a large group that uses the ssb module along with the Broadcom 4318,
> >>>>> in a CF form factor. If the CF card is inserted before boot, and the ssb
> >>>>> module is not in the initrd process, the laptops lock up and do not become
> >>>>> operational. The solution to this problem is/was adding the ssb.ko to the
> >>>>> initrd process. So I agree with Luis on this, the ssb module will have to be
> >>>>> added/updated to the initrd process. As for PCI operations, I don't know,
> >>>>> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
> >>>>> am testing new releases of b43, I run "update-initramfs -u" to update the
> >>>>> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
> >>>>> modprobe them back in. - This saves a reboot)
> >>>> But why is ssb, b43, b44 needed upon early boot?
> >>> OK the reason seems to be netboot. Yeah the only fix for distros who want
> >>> this on the initramfs is to update it after a compat-wireless package is
> >>> installed. I suppose we can add a hook to compat-wireless for each distro.
> >>> I'm only familiar with Ubuntu way of doing this so if people are interested
> >>> in other distros you'll need to point/test how to do this on there.
> >>>
> >>> Please try this patch against compat-wireless: (also attached)
> >>>
> >>> From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
> >>> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>> Date: Sun, 27 Sep 2009 13:58:22 -0700
> >>> Subject: [PATCH] Add scripts/update-initramfs and use it
> >>>
> >>> Some distributions may ship b44 and ssb on the initramfs for
> >>> netboot. To help with this we need to update the initrafms
> >>> for those distributions.
> >>>
> >>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>> ---
> >>>  Makefile                 |    1 +
> >>>  scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
> >>>  2 files changed, 34 insertions(+), 0 deletions(-)
> >>>  create mode 100755 scripts/update-initramfs
> >>>
> >>> diff --git a/Makefile b/Makefile
> >>> index ab97de0..c7333a2 100644
> >>> --- a/Makefile
> >>> +++ b/Makefile
> >>> @@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
> >>>  install-modules: modules
> >>>       $(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
> >>>               modules_install
> >>> +     @./scripts/update-initramfs
> >>>
> >>>  install-scripts:
> >>>       @# All the scripts we can use
> >>> diff --git a/scripts/update-initramfs b/scripts/update-initramfs
> >>> new file mode 100755
> >>> index 0000000..412d885
> >>> --- /dev/null
> >>> +++ b/scripts/update-initramfs
> >>> @@ -0,0 +1,33 @@
> >>> +#!/bin/bash
> >>> +# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
> >>> +#
> >>> +# Since we provide ssb, the Ethernet module b44 some people may
> >>> +# rely on it to netboot, so update the initrafms for each
> >>> +# distribution.
> >>> +#
> >>> +# Note that in the future people may want to wireless-boot
> >>> +# so this will help with that as well.
> >>> +
> >>> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
> >>> +
> >>> +KLIB=/lib/modules/2.6.31-wl/build
> >>> +ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
> >>> +dir=/boot/
> >>> +
> >>> +case $LSB_RED_ID in
> >>> +"Ubuntu")
> >>> +     echo "Updating Ubuntu's initramfs for $ver under $dir ..."
> >>> +     mkinitramfs -o $dir/initrd.img-$ver $ver
> >>> +     echo "Will now run update-grub to ensure grub will find the new initramfs ..."
> >>> +     update-grub
> >>> +     ;;
> >>> +*)
> >>> +     echo "Warning:"
> >>> +     echo "You may or may not need to update your initframfs, you should if"
> >>> +     echo "any of the modules installed are part of your initramfs. To add"
> >>> +     echo "support for your distribution to do this automatically send a"
> >>> +     echo "patch against $0. If your distribution does not require this"
> >>> +     echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
> >>> +     echo "tag for your distribution to avoid this warning."
> >>> +        ;;
> >>> +esac
> >>>
> >> Luis - I'll do something similar in a post install script for Karmic LBM
> >
> > Great, thanks for the heads up.
> >
> >> since the install-modules target in your makefile isn't used for a
> >> debian install.
> >
> > Not sure I followed this part, what do you mean?
> >
> 
> It has to do with the way debian packages are installed. In the case of
> LBM, the .ko files from the binary package are simply copied to their
> target locations during 'apt-get install'. Therefore, a post
> installation script needs to be run that updates the initramfs.

Oh I see, the debian/rules file entry for install, got it.

  Luis

^ permalink raw reply

* Re: A problem loading ssb module
From: Tim Gardner @ 2009-09-28 20:38 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Luis R. Rodriguez, Luis Rodriguez, Clyde McPherson,
	Hauke Mehrtens, linux-wireless, bcm43xx-dev@lists.berlios.de
In-Reply-To: <20090928200759.GC7788@mosca>

Luis R. Rodriguez wrote:
> On Mon, Sep 28, 2009 at 01:00:55PM -0700, Tim Gardner wrote:
>> Luis R. Rodriguez wrote:
>>> On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
>>>> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
>>>>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>>>
>>>>>>> Bryan Wu wrote:
>>>>>>>
>>>>>>>> Mauro Di Domenico wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>>>>>> machine with kernel version 2.6.30-6.
>>>>>>>>>
>>>>>>>>> During the boot I experience this problem:
>>>>>>>>>
>>>>>>>>> $ dmesg|egrep "b43|ssb"
>>>>>>>>>
>>>>>>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>>>>>> low) -> IRQ 17
>>>>>>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>>>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>>>>>> 0000:06:00.0
>>>>>>>>> [    6.968981] b43: disagrees about version of symbol
>>>>>>>>> ssb_device_is_enabled
>>>>>>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>>>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>>>>>> [    6.969407] b43: disagrees about version of symbol
>>>>>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>>>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>>>>>> .....
>>>>>>>>> ....
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>>>>>> have
>>>>>>>> no time to take a deeper look.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>>>>>> 9.04. The problem is that the ssb module is integrated into the
>>>>>>> initramfs image. The version out of the initramfs image is loaded on
>>>>>>> startup and not the version of compat-wireless. Running "sudo
>>>>>>> update-initramfs -u" after installing compat-wireless and restaing the
>>>>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>>>>>> form default initramfs image or compat-wireless should update the image
>>>>>>> with the install command. At least the compat-wireless documentation
>>>>>>> needs an update.
>>>>>>>
>>>>>>> Hauke
>>>>>>>
>>>>>>> (adding Luis and linux-wireless list)
>>>>>>>
>>>>>> Tim, do you guys update the initramfs upon installation of lbm? If a
>>>>>> user does not use lbm and uses compat-wireless I suppose we need to do
>>>>>> something similar.
>>>>>>
>>>>>>  Luis
>>>>>> _______________________________________________
>>>>>> Bcm43xx-dev mailing list
>>>>>> Bcm43xx-dev@lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>>>>>
>>>>> All:
>>>>> I have a large group that uses the ssb module along with the Broadcom 4318,
>>>>> in a CF form factor. If the CF card is inserted before boot, and the ssb
>>>>> module is not in the initrd process, the laptops lock up and do not become
>>>>> operational. The solution to this problem is/was adding the ssb.ko to the
>>>>> initrd process. So I agree with Luis on this, the ssb module will have to be
>>>>> added/updated to the initrd process. As for PCI operations, I don't know,
>>>>> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
>>>>> am testing new releases of b43, I run "update-initramfs -u" to update the
>>>>> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
>>>>> modprobe them back in. - This saves a reboot)
>>>> But why is ssb, b43, b44 needed upon early boot?
>>> OK the reason seems to be netboot. Yeah the only fix for distros who want
>>> this on the initramfs is to update it after a compat-wireless package is
>>> installed. I suppose we can add a hook to compat-wireless for each distro.
>>> I'm only familiar with Ubuntu way of doing this so if people are interested
>>> in other distros you'll need to point/test how to do this on there.
>>>
>>> Please try this patch against compat-wireless: (also attached)
>>>
>>> From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
>>> From: Luis R. Rodriguez <lrodriguez@atheros.com>
>>> Date: Sun, 27 Sep 2009 13:58:22 -0700
>>> Subject: [PATCH] Add scripts/update-initramfs and use it
>>>
>>> Some distributions may ship b44 and ssb on the initramfs for
>>> netboot. To help with this we need to update the initrafms
>>> for those distributions.
>>>
>>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>> ---
>>>  Makefile                 |    1 +
>>>  scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
>>>  2 files changed, 34 insertions(+), 0 deletions(-)
>>>  create mode 100755 scripts/update-initramfs
>>>
>>> diff --git a/Makefile b/Makefile
>>> index ab97de0..c7333a2 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
>>>  install-modules: modules
>>>       $(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
>>>               modules_install
>>> +     @./scripts/update-initramfs
>>>
>>>  install-scripts:
>>>       @# All the scripts we can use
>>> diff --git a/scripts/update-initramfs b/scripts/update-initramfs
>>> new file mode 100755
>>> index 0000000..412d885
>>> --- /dev/null
>>> +++ b/scripts/update-initramfs
>>> @@ -0,0 +1,33 @@
>>> +#!/bin/bash
>>> +# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
>>> +#
>>> +# Since we provide ssb, the Ethernet module b44 some people may
>>> +# rely on it to netboot, so update the initrafms for each
>>> +# distribution.
>>> +#
>>> +# Note that in the future people may want to wireless-boot
>>> +# so this will help with that as well.
>>> +
>>> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
>>> +
>>> +KLIB=/lib/modules/2.6.31-wl/build
>>> +ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
>>> +dir=/boot/
>>> +
>>> +case $LSB_RED_ID in
>>> +"Ubuntu")
>>> +     echo "Updating Ubuntu's initramfs for $ver under $dir ..."
>>> +     mkinitramfs -o $dir/initrd.img-$ver $ver
>>> +     echo "Will now run update-grub to ensure grub will find the new initramfs ..."
>>> +     update-grub
>>> +     ;;
>>> +*)
>>> +     echo "Warning:"
>>> +     echo "You may or may not need to update your initframfs, you should if"
>>> +     echo "any of the modules installed are part of your initramfs. To add"
>>> +     echo "support for your distribution to do this automatically send a"
>>> +     echo "patch against $0. If your distribution does not require this"
>>> +     echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
>>> +     echo "tag for your distribution to avoid this warning."
>>> +        ;;
>>> +esac
>>>
>> Luis - I'll do something similar in a post install script for Karmic LBM
> 
> Great, thanks for the heads up.
> 
>> since the install-modules target in your makefile isn't used for a
>> debian install.
> 
> Not sure I followed this part, what do you mean?
> 

It has to do with the way debian packages are installed. In the case of
LBM, the .ko files from the binary package are simply copied to their
target locations during 'apt-get install'. Therefore, a post
installation script needs to be run that updates the initramfs.

rtg
-- 
Tim Gardner tim.gardner@canonical.com

^ permalink raw reply

* Re: Unable to create an 802.11s mesh using compat-wireless-2009-09-27
From: Andrey Yurovsky @ 2009-09-28 20:28 UTC (permalink / raw)
  To: Simon Raffeiner; +Cc: linux-wireless
In-Reply-To: <200909271541.58448.sturmflut@lieberbiber.de>

On Sun, Sep 27, 2009 at 6:41 AM, Simon Raffeiner
<sturmflut@lieberbiber.de> wrote:
> and falls back to "Managed" after about five seconds:

Is there an application like NetworkManager running?  If so, please
kill it before proceeding.  Also it's not useful/needed to run
"iwconfig", it doesn't understand mesh interfaces.  Please only use
iw.

  -Andrey

^ permalink raw reply

* Re: [PATCH] iwlagn: fix panic in iwl{5000,4965}_rx_reply_tx
From: John W. Linville @ 2009-09-28 20:14 UTC (permalink / raw)
  To: reinette chatre; +Cc: Stanislaw Gruszka, linux-wireless@vger.kernel.org
In-Reply-To: <1253828287.26521.999.camel@rc-desk>

On Thu, Sep 24, 2009 at 02:38:07PM -0700, reinette chatre wrote:
> Hi Stanislaw,
> 
> On Wed, 2009-09-23 at 01:51 -0700, Stanislaw Gruszka wrote:
> > In some cases firmware can give us bad value of index in transmit
> > buffers array. This patch add sanity check for such values and return
> > from processing function instantly when it happens.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=521931
> > 
> > Patch was tested by reporter on iwl5000. I think check can be also
> > helpful for 4965.
> > 
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > ---
> 
> I looked at the bugzilla entry and I think that there may be another fix
> required here. After the driver submitted the five frames it received a
> surprisingly large number of tx responses from firmware, with one of
> these causing the problem. The bad value from the firmware may be a
> result of something else done incorrectly by driver here since the
> firmware has been trying for more than 40 times at this point to inform
> driver about tx results.
> 
> I commented in that bugzilla and we can continue to debug this issue
> there. Until then I'd like to hold off on this patch.

Hmmm...well, I already sent it to Dave/Linus -- it's in 2.6.32-rc1...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-28 20:07 UTC (permalink / raw)
  To: Tim Gardner
  Cc: Luis R. Rodriguez, Luis Rodriguez, Clyde McPherson,
	Hauke Mehrtens, linux-wireless, bcm43xx-dev@lists.berlios.de
In-Reply-To: <4AC115F7.8020909@canonical.com>

On Mon, Sep 28, 2009 at 01:00:55PM -0700, Tim Gardner wrote:
> Luis R. Rodriguez wrote:
> > On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
> >> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
> >>>
> >>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >>>>
> >>>>> Bryan Wu wrote:
> >>>>>
> >>>>>> Mauro Di Domenico wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
> >>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
> >>>>>>> machine with kernel version 2.6.30-6.
> >>>>>>>
> >>>>>>> During the boot I experience this problem:
> >>>>>>>
> >>>>>>> $ dmesg|egrep "b43|ssb"
> >>>>>>>
> >>>>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
> >>>>>>> low) -> IRQ 17
> >>>>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
> >>>>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
> >>>>>>> 0000:06:00.0
> >>>>>>> [    6.968981] b43: disagrees about version of symbol
> >>>>>>> ssb_device_is_enabled
> >>>>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
> >>>>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
> >>>>>>> [    6.969407] b43: disagrees about version of symbol
> >>>>>>> ssb_pcicore_dev_irqvecs_enable
> >>>>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
> >>>>>>> .....
> >>>>>>> ....
> >>>>>>> ...
> >>>>>>>
> >>>>>>>
> >>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
> >>>>>> have
> >>>>>> no time to take a deeper look.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
> >>>>> 9.04. The problem is that the ssb module is integrated into the
> >>>>> initramfs image. The version out of the initramfs image is loaded on
> >>>>> startup and not the version of compat-wireless. Running "sudo
> >>>>> update-initramfs -u" after installing compat-wireless and restaing the
> >>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
> >>>>> form default initramfs image or compat-wireless should update the image
> >>>>> with the install command. At least the compat-wireless documentation
> >>>>> needs an update.
> >>>>>
> >>>>> Hauke
> >>>>>
> >>>>> (adding Luis and linux-wireless list)
> >>>>>
> >>>> Tim, do you guys update the initramfs upon installation of lbm? If a
> >>>> user does not use lbm and uses compat-wireless I suppose we need to do
> >>>> something similar.
> >>>>
> >>>>  Luis
> >>>> _______________________________________________
> >>>> Bcm43xx-dev mailing list
> >>>> Bcm43xx-dev@lists.berlios.de
> >>>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> >>>>
> >>> All:
> >>> I have a large group that uses the ssb module along with the Broadcom 4318,
> >>> in a CF form factor. If the CF card is inserted before boot, and the ssb
> >>> module is not in the initrd process, the laptops lock up and do not become
> >>> operational. The solution to this problem is/was adding the ssb.ko to the
> >>> initrd process. So I agree with Luis on this, the ssb module will have to be
> >>> added/updated to the initrd process. As for PCI operations, I don't know,
> >>> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
> >>> am testing new releases of b43, I run "update-initramfs -u" to update the
> >>> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
> >>> modprobe them back in. - This saves a reboot)
> >> But why is ssb, b43, b44 needed upon early boot?
> >
> > OK the reason seems to be netboot. Yeah the only fix for distros who want
> > this on the initramfs is to update it after a compat-wireless package is
> > installed. I suppose we can add a hook to compat-wireless for each distro.
> > I'm only familiar with Ubuntu way of doing this so if people are interested
> > in other distros you'll need to point/test how to do this on there.
> >
> > Please try this patch against compat-wireless: (also attached)
> >
> > From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
> > From: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Date: Sun, 27 Sep 2009 13:58:22 -0700
> > Subject: [PATCH] Add scripts/update-initramfs and use it
> >
> > Some distributions may ship b44 and ssb on the initramfs for
> > netboot. To help with this we need to update the initrafms
> > for those distributions.
> >
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> >  Makefile                 |    1 +
> >  scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
> >  2 files changed, 34 insertions(+), 0 deletions(-)
> >  create mode 100755 scripts/update-initramfs
> >
> > diff --git a/Makefile b/Makefile
> > index ab97de0..c7333a2 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
> >  install-modules: modules
> >       $(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
> >               modules_install
> > +     @./scripts/update-initramfs
> >
> >  install-scripts:
> >       @# All the scripts we can use
> > diff --git a/scripts/update-initramfs b/scripts/update-initramfs
> > new file mode 100755
> > index 0000000..412d885
> > --- /dev/null
> > +++ b/scripts/update-initramfs
> > @@ -0,0 +1,33 @@
> > +#!/bin/bash
> > +# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
> > +#
> > +# Since we provide ssb, the Ethernet module b44 some people may
> > +# rely on it to netboot, so update the initrafms for each
> > +# distribution.
> > +#
> > +# Note that in the future people may want to wireless-boot
> > +# so this will help with that as well.
> > +
> > +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
> > +
> > +KLIB=/lib/modules/2.6.31-wl/build
> > +ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
> > +dir=/boot/
> > +
> > +case $LSB_RED_ID in
> > +"Ubuntu")
> > +     echo "Updating Ubuntu's initramfs for $ver under $dir ..."
> > +     mkinitramfs -o $dir/initrd.img-$ver $ver
> > +     echo "Will now run update-grub to ensure grub will find the new initramfs ..."
> > +     update-grub
> > +     ;;
> > +*)
> > +     echo "Warning:"
> > +     echo "You may or may not need to update your initframfs, you should if"
> > +     echo "any of the modules installed are part of your initramfs. To add"
> > +     echo "support for your distribution to do this automatically send a"
> > +     echo "patch against $0. If your distribution does not require this"
> > +     echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
> > +     echo "tag for your distribution to avoid this warning."
> > +        ;;
> > +esac
> >
> 
> Luis - I'll do something similar in a post install script for Karmic LBM

Great, thanks for the heads up.

> since the install-modules target in your makefile isn't used for a
> debian install.

Not sure I followed this part, what do you mean?

  Luis

^ permalink raw reply

* Re: A problem loading ssb module
From: Tim Gardner @ 2009-09-28 20:00 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Luis R. Rodriguez, Clyde McPherson, Hauke Mehrtens,
	linux-wireless, bcm43xx-dev
In-Reply-To: <20090927210252.GA31472@bombadil.infradead.org>

Luis R. Rodriguez wrote:
> On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
>> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
>>>
>>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>
>>>>> Bryan Wu wrote:
>>>>>
>>>>>> Mauro Di Domenico wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>>>> machine with kernel version 2.6.30-6.
>>>>>>>
>>>>>>> During the boot I experience this problem:
>>>>>>>
>>>>>>> $ dmesg|egrep "b43|ssb"
>>>>>>>
>>>>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>>>> low) -> IRQ 17
>>>>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>>>> 0000:06:00.0
>>>>>>> [    6.968981] b43: disagrees about version of symbol
>>>>>>> ssb_device_is_enabled
>>>>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>>>> [    6.969407] b43: disagrees about version of symbol
>>>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>>>> .....
>>>>>>> ....
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>>>> have
>>>>>> no time to take a deeper look.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>> Hi,
>>>>>
>>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>>>> 9.04. The problem is that the ssb module is integrated into the
>>>>> initramfs image. The version out of the initramfs image is loaded on
>>>>> startup and not the version of compat-wireless. Running "sudo
>>>>> update-initramfs -u" after installing compat-wireless and restaing the
>>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>>>> form default initramfs image or compat-wireless should update the image
>>>>> with the install command. At least the compat-wireless documentation
>>>>> needs an update.
>>>>>
>>>>> Hauke
>>>>>
>>>>> (adding Luis and linux-wireless list)
>>>>>
>>>> Tim, do you guys update the initramfs upon installation of lbm? If a
>>>> user does not use lbm and uses compat-wireless I suppose we need to do
>>>> something similar.
>>>>
>>>>  Luis
>>>> _______________________________________________
>>>> Bcm43xx-dev mailing list
>>>> Bcm43xx-dev@lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>>>
>>> All:
>>> I have a large group that uses the ssb module along with the Broadcom 4318,
>>> in a CF form factor. If the CF card is inserted before boot, and the ssb
>>> module is not in the initrd process, the laptops lock up and do not become
>>> operational. The solution to this problem is/was adding the ssb.ko to the
>>> initrd process. So I agree with Luis on this, the ssb module will have to be
>>> added/updated to the initrd process. As for PCI operations, I don't know,
>>> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
>>> am testing new releases of b43, I run "update-initramfs -u" to update the
>>> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
>>> modprobe them back in. - This saves a reboot)
>> But why is ssb, b43, b44 needed upon early boot?
> 
> OK the reason seems to be netboot. Yeah the only fix for distros who want
> this on the initramfs is to update it after a compat-wireless package is
> installed. I suppose we can add a hook to compat-wireless for each distro.
> I'm only familiar with Ubuntu way of doing this so if people are interested
> in other distros you'll need to point/test how to do this on there.
> 
> Please try this patch against compat-wireless: (also attached)
> 
> From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Date: Sun, 27 Sep 2009 13:58:22 -0700
> Subject: [PATCH] Add scripts/update-initramfs and use it
> 
> Some distributions may ship b44 and ssb on the initramfs for
> netboot. To help with this we need to update the initrafms
> for those distributions.
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  Makefile                 |    1 +
>  scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
>  2 files changed, 34 insertions(+), 0 deletions(-)
>  create mode 100755 scripts/update-initramfs
> 
> diff --git a/Makefile b/Makefile
> index ab97de0..c7333a2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
>  install-modules: modules
>  	$(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
>  		modules_install
> +	@./scripts/update-initramfs
>  
>  install-scripts:
>  	@# All the scripts we can use
> diff --git a/scripts/update-initramfs b/scripts/update-initramfs
> new file mode 100755
> index 0000000..412d885
> --- /dev/null
> +++ b/scripts/update-initramfs
> @@ -0,0 +1,33 @@
> +#!/bin/bash
> +# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
> +#
> +# Since we provide ssb, the Ethernet module b44 some people may
> +# rely on it to netboot, so update the initrafms for each
> +# distribution.
> +#
> +# Note that in the future people may want to wireless-boot
> +# so this will help with that as well.
> +
> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
> +
> +KLIB=/lib/modules/2.6.31-wl/build
> +ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
> +dir=/boot/
> +
> +case $LSB_RED_ID in
> +"Ubuntu")
> +	echo "Updating Ubuntu's initramfs for $ver under $dir ..."
> +	mkinitramfs -o $dir/initrd.img-$ver $ver
> +	echo "Will now run update-grub to ensure grub will find the new initramfs ..."
> +	update-grub
> +	;;
> +*)
> +	echo "Warning:"
> +	echo "You may or may not need to update your initframfs, you should if"
> +	echo "any of the modules installed are part of your initramfs. To add"
> +	echo "support for your distribution to do this automatically send a"
> +	echo "patch against $0. If your distribution does not require this"
> +	echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
> +	echo "tag for your distribution to avoid this warning."
> +        ;;
> +esac
> 

Luis - I'll do something similar in a post install script for Karmic LBM
since the install-modules target in your makefile isn't used for a
debian install.

rtg
-- 
Tim Gardner tim.gardner@canonical.com

^ permalink raw reply

* Re: [PATCH] ar9170: implement frequency calibration for one-stage/openfw
From: John W. Linville @ 2009-09-28 19:50 UTC (permalink / raw)
  To: Christian Lamparter
  Cc: Joerg Albert, Andrew Morton, linux-wireless, David S. Miller
In-Reply-To: <22ee4e770909281245g3346a800n940c28199e429abf@mail.gmail.com>

On Mon, Sep 28, 2009 at 09:45:28PM +0200, Christian Lamparter wrote:
> 2009/9/28 John W. Linville <linville@tuxdriver.com>:
> > On Sat, Sep 19, 2009 at 02:21:36PM +0200, Joerg Albert wrote:
> >> On 09/19/2009 02:02 AM, Andrew Morton wrote:

> >> > How did this get all the way into mainline?
> >>
> >> Strangely it compiles without any warning for me with the latest linux-wireless:
> >
> > That is strange -- no warning here (F-11) either...
> >
> > Christian, care to propose a patch?  Or maybe just something like this?
> >
> > diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
> > index b3e5cf3..49c10cb 100644
> > --- a/drivers/net/wireless/ath/ar9170/phy.c
> > +++ b/drivers/net/wireless/ath/ar9170/phy.c
> > @@ -1220,7 +1220,7 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
> >                                                             &vpds[1][0]);
> >                        }
> >
> > -                       phy_data |= tmp << ((i & 3) << 3);
> > +                       phy_data = tmp << ((i & 3) << 3);
> >                        if ((i & 3) == 3) {
> >                                ar9170_regwrite(0x1c6280 + chain * 0x1000 +
> >                                                (i & ~3), phy_data);
> >
> > John
> no? Andrew Morton's mail included a tiny patch which initializes the
> phy_data to 0. I assumed you would pick it up right away...
> Or is there something which would prevent it from including?

Don't know what email you got, but there was no patch in my inbox...

So, I presume you have no objection to the patch above?  Initializing
phy_data just to unconditionally assign to it doesn't seem any better.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-28 19:55 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Clyde McPherson, Hauke Mehrtens, Tim Gardner, linux-wireless,
	bcm43xx-dev
In-Reply-To: <20090927210252.GA31472@bombadil.infradead.org>

On Sun, Sep 27, 2009 at 2:02 PM, Luis R. Rodriguez
<mcgrof@bombadil.infradead.org> wrote:
> On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
>> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
>> >
>> >
>> >> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> >>
>> >>>
>> >>> Bryan Wu wrote:
>> >>>
>> >>>>
>> >>>> Mauro Di Domenico wrote:
>> >>>>
>> >>>>>
>> >>>>> Hi,
>> >>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>> >>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>> >>>>> machine with kernel version 2.6.30-6.
>> >>>>>
>> >>>>> During the boot I experience this problem:
>> >>>>>
>> >>>>> $ dmesg|egrep "b43|ssb"
>> >>>>>
>> >>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>> >>>>> low) -> IRQ 17
>> >>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>> >>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
>> >>>>> 0000:06:00.0
>> >>>>> [    6.968981] b43: disagrees about version of symbol
>> >>>>> ssb_device_is_enabled
>> >>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
>> >>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>> >>>>> [    6.969407] b43: disagrees about version of symbol
>> >>>>> ssb_pcicore_dev_irqvecs_enable
>> >>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>> >>>>> .....
>> >>>>> ....
>> >>>>> ...
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>> >>>> have
>> >>>> no time to take a deeper look.
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>
>> >>> Hi,
>> >>>
>> >>> I had the same problem with the ssb module and compat-wireless in ubuntu
>> >>> 9.04. The problem is that the ssb module is integrated into the
>> >>> initramfs image. The version out of the initramfs image is loaded on
>> >>> startup and not the version of compat-wireless. Running "sudo
>> >>> update-initramfs -u" after installing compat-wireless and restaing the
>> >>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>> >>> form default initramfs image or compat-wireless should update the image
>> >>> with the install command. At least the compat-wireless documentation
>> >>> needs an update.
>> >>>
>> >>> Hauke
>> >>>
>> >>> (adding Luis and linux-wireless list)
>> >>>
>> >>
>> >> Tim, do you guys update the initramfs upon installation of lbm? If a
>> >> user does not use lbm and uses compat-wireless I suppose we need to do
>> >> something similar.
>> >>
>> >>  Luis
>> >> _______________________________________________
>> >> Bcm43xx-dev mailing list
>> >> Bcm43xx-dev@lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>> >>
>> >
>> > All:
>> > I have a large group that uses the ssb module along with the Broadcom 4318,
>> > in a CF form factor. If the CF card is inserted before boot, and the ssb
>> > module is not in the initrd process, the laptops lock up and do not become
>> > operational. The solution to this problem is/was adding the ssb.ko to the
>> > initrd process. So I agree with Luis on this, the ssb module will have to be
>> > added/updated to the initrd process. As for PCI operations, I don't know,
>> > but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
>> > am testing new releases of b43, I run "update-initramfs -u" to update the
>> > ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
>> > modprobe them back in. - This saves a reboot)
>>
>> But why is ssb, b43, b44 needed upon early boot?
>
> OK the reason seems to be netboot. Yeah the only fix for distros who want
> this on the initramfs is to update it after a compat-wireless package is
> installed. I suppose we can add a hook to compat-wireless for each distro.
> I'm only familiar with Ubuntu way of doing this so if people are interested
> in other distros you'll need to point/test how to do this on there.
>
> Please try this patch against compat-wireless: (also attached)
>
> From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Date: Sun, 27 Sep 2009 13:58:22 -0700
> Subject: [PATCH] Add scripts/update-initramfs and use it
>
> Some distributions may ship b44 and ssb on the initramfs for
> netboot. To help with this we need to update the initrafms
> for those distributions.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

I didn't see much feedback but I'm going to merge this in so that it
gets out with the 2.6.32-rc1 stable compat-wireless release.

  Luis

^ permalink raw reply

* Re: [PATCH] ar9170: implement frequency calibration for one-stage/openfw
From: Christian Lamparter @ 2009-09-28 19:45 UTC (permalink / raw)
  To: John W. Linville
  Cc: Joerg Albert, Andrew Morton, linux-wireless, David S. Miller
In-Reply-To: <20090928184111.GB4737@tuxdriver.com>

2009/9/28 John W. Linville <linville@tuxdriver.com>:
> On Sat, Sep 19, 2009 at 02:21:36PM +0200, Joerg Albert wrote:
>> On 09/19/2009 02:02 AM, Andrew Morton wrote:
>> > On Thu, 3 Sep 2009 20:25:31 +0200
>> > Christian Lamparter <chunkeey@googlemail.com> wrote:
>> >
>> >> This patch ports some code from the vendor driver, which is
>> >> supposed to upload the right calibration values for the
>> >> chosen frequency.
>> >>
>> >> In theory, this should give a better range and throughput
>> >> for all users with the open, or one-stage firmware.
>> >>
>> >> ...
>> >>
>> >> +          for (i = 0; i < 76; i++) {
>> >> +                  u32 phy_data;
>> >> +                  u8 tmp;
>> >> +
>> >> +                  if (i < 25) {
>> >> +                          tmp = ar9170_interpolate_val(i, &pwrs[0][0],
>> >> +                                                       &vpds[0][0]);
>> >> +                  } else {
>> >> +                          tmp = ar9170_interpolate_val(i - 12,
>> >> +                                                       &pwrs[1][0],
>> >> +                                                       &vpds[1][0]);
>> >> +                  }
>> >> +
>> >> +                  phy_data |= tmp << ((i & 3) << 3);
>> >
>> > Clearly buggy and the compiler warns.  The value of phy_data is unknown
>> > here.
>> >
>> > How did this get all the way into mainline?
>>
>> Strangely it compiles without any warning for me with the latest linux-wireless:
>
> That is strange -- no warning here (F-11) either...
>
> Christian, care to propose a patch?  Or maybe just something like this?
>
> diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
> index b3e5cf3..49c10cb 100644
> --- a/drivers/net/wireless/ath/ar9170/phy.c
> +++ b/drivers/net/wireless/ath/ar9170/phy.c
> @@ -1220,7 +1220,7 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
>                                                             &vpds[1][0]);
>                        }
>
> -                       phy_data |= tmp << ((i & 3) << 3);
> +                       phy_data = tmp << ((i & 3) << 3);
>                        if ((i & 3) == 3) {
>                                ar9170_regwrite(0x1c6280 + chain * 0x1000 +
>                                                (i & ~3), phy_data);
>
> John
no? Andrew Morton's mail included a tiny patch which initializes the
phy_data to 0. I assumed you would pick it up right away...
Or is there something which would prevent it from including?

Regards,
         Chr

^ permalink raw reply

* Re: [ath9k-devel] Makefile ref to non-existent CONFIG_ATHEROS_AR71XX
From: Imre Kaloz @ 2009-09-28 19:33 UTC (permalink / raw)
  To: John W. Linville, Florian Fainelli
  Cc: ath9k-devel, Robert P. J. Day, linux-wireless
In-Reply-To: <20090928182944.GA4737@tuxdriver.com>

On 2009.09.28. 20:29:45 John W. Linville <linville@tuxdriver.com> wrote:

> On Fri, Sep 18, 2009 at 08:04:51PM +0200, Florian Fainelli wrote:
>> Hi Robert,
>>
>> Le vendredi 18 septembre 2009 16:01:25, Robert P. J. Day a écrit :
>> >   searching for Makefile references to Kconfig variables that don't
>> > exist, and i find:
>> >
>> > ===== ATHEROS_AR71XX =====
>> > ./drivers/net/wireless/ath/ath9k/Makefile:ath9k-$(CONFIG_ATHEROS_AR71XX) +=
>> > ahb.o
>>
>> We need it in OpenWrt and plan to send Atheros AR71xx SoC support soon, do not
>> consider this for removal. Thanks
>
> Sure, fine...estimate when it will arrive?
>
> John

When we got access to some more info on the AR7240 so we can finish the support for it.


Imre

^ permalink raw reply

* Re: [ath9k-devel] Makefile ref to non-existent CONFIG_ATHEROS_AR71XX
From: Robert P. J. Day @ 2009-09-28 19:37 UTC (permalink / raw)
  To: Imre Kaloz
  Cc: John W. Linville, Florian Fainelli, ath9k-devel, linux-wireless
In-Reply-To: <op.u0zfaoao2s3iss@richese>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1466 bytes --]

On Mon, 28 Sep 2009, Imre Kaloz wrote:

> On 2009.09.28. 20:29:45 John W. Linville <linville@tuxdriver.com> wrote:
>
> > On Fri, Sep 18, 2009 at 08:04:51PM +0200, Florian Fainelli wrote:
> > > Hi Robert,
> > >
> > > Le vendredi 18 septembre 2009 16:01:25, Robert P. J. Day a écrit :
> > > >   searching for Makefile references to Kconfig variables that don't
> > > > exist, and i find:
> > > >
> > > > ===== ATHEROS_AR71XX =====
> > > > ./drivers/net/wireless/ath/ath9k/Makefile:ath9k-$(CONFIG_ATHEROS_AR71XX)
> > > > +=
> > > > ahb.o
> > >
> > > We need it in OpenWrt and plan to send Atheros AR71xx SoC
> > > support soon, do not consider this for removal. Thanks
> >
> > Sure, fine...estimate when it will arrive?
> >
> > John
>
> When we got access to some more info on the AR7240 so we can finish
> the support for it.

  just FYI, i wasn't pushing to have it taken out, just pointing out
its current lack of use.  what someone decides to do about it is
entirely in their hands.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

^ permalink raw reply

* Re: Problems with "cfg80211: fix SME connect" commit
From: Hin-Tak Leung @ 2009-09-28 19:22 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <1254164123.3151.10.camel@johannes.local>

On Mon, Sep 28, 2009 at 7:55 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-09-28 at 11:04 -0700, Albert Herranz wrote:
>
>> [   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
>> [   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
>> [   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79
>
>> I'm using wpa_supplicant _without_ NM.
>
> Yeah, I since figured out why that's happening, and it's not so strange
> after all. Shouldn't be a big deal. At least I see you're getting
> connected too now.
>
> johannes
>

Yes, it looks like it is similar/same as my situation - the difference
being that I had wpa_supplicant talking to NM via D-bus and get the
extra user-prompt (not anymore with the latest patches) when the first
try from wpa_supplicant fails. When wpa_supplicant is run without -u
(the d-bus/NM option) it probably tries a bit harder on its own?

Hin-Tak

^ permalink raw reply

* [PATCH] compat-2.6: adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-28 19:08 UTC (permalink / raw)
  To: linux-wireless, lrodriguez; +Cc: Hin-Tak Leung, Hin-Tak Leung

adding notes on installing to non-running kernel

Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
 README |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
 
 make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
 
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make  KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+  and to install to your system's root path for the non-running kernel:
+
+make  KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
 Bugs
 -----
 
-- 
1.6.2.5


^ permalink raw reply related

* [PATCH] compat-2.6: adding driver-select script support for rtl818x
From: Hin-Tak Leung @ 2009-09-28 19:08 UTC (permalink / raw)
  To: linux-wireless, lrodriguez; +Cc: Hin-Tak Leung, Hin-Tak Leung

adding driver-select script support for rtl818x

Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
 scripts/driver-select |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/scripts/driver-select b/scripts/driver-select
index e0d7305..dcb777c 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -44,6 +44,7 @@ function usage {
 	echo -e "\t${CYAN}ath${NORMAL} < ${PURPLE} ath5k ath9k ar9170 ${NORMAL}>"
 	echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
 	echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
+	echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
 	echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 (SPI and SDIO) wl1271 ${NORMAL}>"
 
 	echo -e "Restoring compat-wireless:"
@@ -127,6 +128,13 @@ function disable_var_01 {
 	disable_var
 }
 
+function disable_var_02 {
+	#var_01 with eeprom not disabled
+	disable_lib80211
+	disable_ssb
+	disable_usbnet
+}
+
 function select_ath_driver 
 {
 	backup_file $ATH_MAKEFILE
@@ -227,6 +235,10 @@ case $1 in
 		select_driver		CONFIG_ATH_COMMON
 		select_ath_driver	CONFIG_AR9170_USB
 		;;
+	rtl818x)
+		select_drivers		CONFIG_RTL8180 CONFIG_RTL8187
+		disable_var_02
+		;;
 	zd1211rw)
 		select_driver		CONFIG_ZD1211RW
 		disable_var_01
-- 
1.6.2.5


^ permalink raw reply related

* Re: Problems with "cfg80211: fix SME connect" commit
From: Johannes Berg @ 2009-09-28 18:55 UTC (permalink / raw)
  To: Albert Herranz; +Cc: Holger Schurig, linville, linux-wireless
In-Reply-To: <29413.68229.qm@web28307.mail.ukl.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Mon, 2009-09-28 at 11:04 -0700, Albert Herranz wrote:

> [   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
> [   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
> [   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79

> I'm using wpa_supplicant _without_ NM.

Yeah, I since figured out why that's happening, and it's not so strange
after all. Shouldn't be a big deal. At least I see you're getting
connected too now.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [PATCH] ar9170: implement frequency calibration for one-stage/openfw
From: John W. Linville @ 2009-09-28 18:41 UTC (permalink / raw)
  To: Joerg Albert
  Cc: Andrew Morton, Christian Lamparter, linux-wireless,
	David S. Miller
In-Reply-To: <4AB4CCD0.5080003@gmx.de>

On Sat, Sep 19, 2009 at 02:21:36PM +0200, Joerg Albert wrote:
> On 09/19/2009 02:02 AM, Andrew Morton wrote:
> > On Thu, 3 Sep 2009 20:25:31 +0200
> > Christian Lamparter <chunkeey@googlemail.com> wrote:
> > 
> >> This patch ports some code from the vendor driver, which is
> >> supposed to upload the right calibration values for the
> >> chosen frequency.
> >>
> >> In theory, this should give a better range and throughput
> >> for all users with the open, or one-stage firmware.
> >>
> >> ...
> >>
> >> +		for (i = 0; i < 76; i++) {
> >> +			u32 phy_data;
> >> +			u8 tmp;
> >> +
> >> +			if (i < 25) {
> >> +				tmp = ar9170_interpolate_val(i, &pwrs[0][0],
> >> +							     &vpds[0][0]);
> >> +			} else {
> >> +				tmp = ar9170_interpolate_val(i - 12,
> >> +							     &pwrs[1][0],
> >> +							     &vpds[1][0]);
> >> +			}
> >> +
> >> +			phy_data |= tmp << ((i & 3) << 3);
> > 
> > Clearly buggy and the compiler warns.  The value of phy_data is unknown
> > here.
> > 
> > How did this get all the way into mainline?
> 
> Strangely it compiles without any warning for me with the latest linux-wireless:

That is strange -- no warning here (F-11) either...

Christian, care to propose a patch?  Or maybe just something like this?

diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index b3e5cf3..49c10cb 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -1220,7 +1220,7 @@ static int ar9170_set_freq_cal_data(struct ar9170 *ar,
 							     &vpds[1][0]);
 			}
 
-			phy_data |= tmp << ((i & 3) << 3);
+			phy_data = tmp << ((i & 3) << 3);
 			if ((i & 3) == 3) {
 				ar9170_regwrite(0x1c6280 + chain * 0x1000 +
 						(i & ~3), phy_data);

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply related

* Re: Makefile ref to non-existent CONFIG_ATHEROS_AR71XX
From: John W. Linville @ 2009-09-28 18:29 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: Robert P. J. Day, linux-wireless, ath9k-devel
In-Reply-To: <200909182004.54398.florian@openwrt.org>

On Fri, Sep 18, 2009 at 08:04:51PM +0200, Florian Fainelli wrote:
> Hi Robert,
> 
> Le vendredi 18 septembre 2009 16:01:25, Robert P. J. Day a écrit :
> >   searching for Makefile references to Kconfig variables that don't
> > exist, and i find:
> >
> > ===== ATHEROS_AR71XX =====
> > ./drivers/net/wireless/ath/ath9k/Makefile:ath9k-$(CONFIG_ATHEROS_AR71XX) +=
> > ahb.o
> 
> We need it in OpenWrt and plan to send Atheros AR71xx SoC support soon, do not 
> consider this for removal. Thanks

Sure, fine...estimate when it will arrive?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: Problems with "cfg80211: fix SME connect" commit
From: Albert Herranz @ 2009-09-28 18:04 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Holger Schurig, linville, linux-wireless
In-Reply-To: <1253779538.3868.14.camel@johannes.local>

Johannes Berg wrote:
> On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
> 
>> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
>> overwrite privacy setting" fixes the connection issue, but with a
>> introduces a small difference vs the previous working version.
>> There is now an extra "deauthenticating by local choice (reason=3)"
>> message in the logs.
> 
>> [   13.969153] b43-phy0 debug: Adding Interface type 2
>> [   16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
> 
>> * master-20090916 + "cfg80211: don't overwrite privacy setting"
> 
>> [   13.218613] b43-phy0 debug: Adding Interface type 2
>> [   15.832582] wlan1: deauthenticating by local choice (reason=3)
>> [   16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
> 
> Very odd. Can you edit the deauthenticating message to show the
> BSSID/MAC address?
> 
> johannes

Hi,

Sorry if this comes too late (I was on vacation).

Here's the output showing the BSSID/MAC address for completeness.

[    1.307985] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    1.344244] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    1.372627] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
[    1.377416] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
[    1.417302] phy0: Selected rate control algorithm 'minstrel'
[    4.462416] udev: renamed network interface wlan0 to wlan1
[   11.064949] b43 ssb0:0: firmware: requesting b43/ucode5.fw
[   11.118177] b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
[   11.197385] b43 ssb0:0: firmware: requesting b43-open/pcm5.fw
[   11.268949] b43 ssb0:0: firmware: requesting b43-open/b0g0initvals5.fw
[   11.347623] b43 ssb0:0: firmware: requesting b43-open/b0g0bsinitvals5.fw
[   12.353406] b43-phy0: Loading OpenSource firmware version 410.31754
[   12.359142] b43-phy0: Hardware crypto acceleration not supported by firmware
[   12.369827] b43-phy0: QoS not supported by firmware
[   12.741767] b43-phy0 debug: Chip initialized
[   12.757540] b43-phy0 debug: PIO initialized
[   12.764455] b43-phy0 debug: QoS disabled
[   12.945116] b43-phy0 debug: Wireless interface started
[   13.053151] b43-phy0 debug: Adding Interface type 2
[   15.624121] wlan1: starting authentication with 00:12:17:15:e7:79
[   15.630717] wlan1: deauthenticating from 00:12:17:15:e7:79 by local choice (reason=3)
[   15.645151] wlan1: starting authentication with 00:12:17:15:e7:79
[   15.665811] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[   15.681132] wlan1: direct probe responded
[   15.687261] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[   15.701105] wlan1: authenticated
[   15.707860] wlan1: starting association with 00:12:17:15:e7:79
[   15.713877] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[   15.726949] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[   15.740953] wlan1: associated

I'm using wpa_supplicant _without_ NM.

Cheers,
Albert


      

^ permalink raw reply

* Re: [RFC] libertas: first stab at cfg80211 support
From: Holger Schurig @ 2009-09-28 15:24 UTC (permalink / raw)
  To: libertas-dev; +Cc: linux-wireless, Dan Williams
In-Reply-To: <200909281321.21600.h.schurig@mn-solutions.de>

Hmm, I see two problems with my code:

> +struct wireless_dev *lbs_wdev_alloc(int sizeof_priv, struct 
device *dev)
> +{
...
> +	wdev->wiphy = wiphy_new(&lbs_cfg80211_ops,
> +		sizeof(struct lbs_private) + sizeof_priv);
...

and later:

> +	wdev = lbs_wdev_alloc(sizeof(struct lbs_private), dmdev);

That's rubbish, I now allocate "sizeof(lbs_private)" bytes twice.



Another thing is that it might be necessary to unbundle the
call of "wiphy_new()" and wiphy_register().

I need lbs_private allocated and usable, e.g. in 
lbs_start_card().

Later, in lbs_start_card(), when I query the firmware about it's 
capabilites I know enought to populate wiphy->bands. Only then 
should I call wiphy_register().

-- 
http://www.holgerschurig.de

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox