* Re: cfg80211 / libertas: an unusual race
From: Johannes Berg @ 2009-10-16 9:57 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910131055.31739.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Tue, 2009-10-13 at 10:55 +0200, Holger Schurig wrote:
> But at step "3. b)", which now happens at a later time,
> wdev_current_bss is no longer set. This triggers a
> WARN_ON(!done) warning in __cfg80211_send_deauth(),
> file net/wireless/mlme.c
>
> Would it be O.K. to simply remove the WARN_ON(!done) ?
> After all, wdev>current_bss was put'ted and cleared correctly.
I don't see this happening that way -- how are you even getting to
__cfg80211_disconnected() if not through _send_deauth()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wl1251: rename spi device to wl1251
From: Johannes Berg @ 2009-10-16 9:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: linville, linux-wireless
In-Reply-To: <20091013174119.15796.81021.stgit@tikku>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Tue, 2009-10-13 at 20:41 +0300, Kalle Valo wrote:
> -MODULE_ALIAS("spi:wl12xx");
> +MODULE_ALIAS("spi:wl1251");
> diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c b/drivers/net/wireless/wl12xx/wl1251_spi.c
> index 14eff2b..2cf8a21 100644
> --- a/drivers/net/wireless/wl12xx/wl1251_spi.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
> @@ -307,7 +307,7 @@ static int __devexit wl1251_spi_remove(struct spi_device *spi)
>
> static struct spi_driver wl1251_spi_driver = {
> .driver = {
> - .name = "wl12xx",
> + .name = "wl1251",
> .bus = &spi_bus_type,
> .owner = THIS_MODULE,
IIRC there's a preprocessor symbol for the module name (MODULE_NAME?)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [WIP, RFC] libertas: allow scanning via "iw"
From: Johannes Berg @ 2009-10-16 9:50 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910141652.11203.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On Wed, 2009-10-14 at 16:52 +0200, Holger Schurig wrote:
> Do not apply, but please look at the code and comment harshly :-)
>
> +#ifdef TODO
> /* Scan results list */
> struct list_head network_list;
> struct list_head network_free_list;
> struct bss_descriptor *networks;
> +#endif
It'd be easier to read and see what the patch does if you actually
removed all the stuff that is no longer necessary :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: deauthentication and disassociation nl80211 commands
From: Johannes Berg @ 2009-10-16 9:36 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Maxim Levitsky, hostap@lists.shmoo.com, linux-wireless
In-Reply-To: <20091012065507.GB25578@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
On Mon, 2009-10-12 at 09:55 +0300, Jouni Malinen wrote:
> On Sat, Oct 10, 2009 at 06:24:26PM +0200, Johannes Berg wrote:
> > On the other hand, I think Jouni's argument is that you should be able
> > to authenticate (force an auth frame exchange) even while authenticated.
> > I don't really disagree with that all that much, but I'm not sure how to
> > cleanly fit it in. mac80211 would have to reset the auth state without
> > sending a deauth.
>
> Yes, this is exactly what I would like to see happening when using
> mac80211. For now, I think we can work around the issue in
> wpa_supplicant, but eventually, this change in mac80211 would allow the
> code in wpa_supplicant to be cleaned up and the need for an extra
> deauthentication frame could be removed.
This would require a change in cfg80211 too, since that keeps the BSS
list around and refuses this, mac80211 isn't necessarily involved.
However, we need to spec it out more clearly. For instance, we'd have to
not add a new work item and try for another authentication, but rather
use the old one. Right?
I'm happy to have such a change, but it needs to be clearly documented
what is expected of drivers that get an auth() call while already
authenticated with that AP. Especially since it's not just
send_auth_frame(), as we expect the driver to handle the entire
handshake for WEP SK auth.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.32-rc4-git1 -- INFO: possible circular locking dependency detected
From: Johannes Berg @ 2009-10-16 9:34 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, linux-wireless
In-Reply-To: <a44ae5cd0910120528h6d8992fcn8b6592ee799fbfc5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Mon, 2009-10-12 at 08:28 -0400, Miles Lane wrote:
> [ 823.466853] [ INFO: possible circular locking dependency detected ]
> [ 823.466866] 2.6.32-rc4-git1 #2
> [ 823.466873] -------------------------------------------------------
> [ 823.466884] swapper/0 is trying to acquire lock:
> [ 823.466893] (&sta->lock){+.-...}, at: [<f857bda4>] sta_addba_resp_timer_expired+0x1b/0x50 [mac80211]
> [ 823.466940]
> [ 823.466943] but task is already holding lock:
> [ 823.466953] (&sta->ampdu_mlme.tid_tx[tid]->addba_resp_timer){+.-...}, at: [<c1032f22>] run_timer_softirq+0x125/0x1e5
> [ 823.466984]
> [ 823.466987] which lock already depends on the new lock.
Thanks for the report, I'll have to take a look at it, but this appears
to be due to the del_timer_sync() in ieee80211_process_addba_resp().
Guess it never really happens that the AP doesn't respond quickly enough
so the timer hardly fires.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: remove warning in deauth case
From: Johannes Berg @ 2009-10-16 9:32 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John W. Linville
In-Reply-To: <200910131345.28395.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
On Tue, 2009-10-13 at 13:45 +0200, Holger Schurig wrote:
> It might be the case that __cfg80211_disconnected() has already
> cleaned up wdev->current_bss() for us. The old code didn't catch
> that situation and didn't warn needlessly.
Care to explain how that can happen?
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> ---
>
> For more info, see mail "cfg80211 / libertas: an unusual race"
> in the linux-wireless mailing list.
Oh ok, I suppose that explains it?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: fix SME warning by removing stale BSS upon assoc failure
From: Johannes Berg @ 2009-10-16 9:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ic.felix@gmail.com
In-Reply-To: <20091014233528.GA4172@tux>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
On Wed, 2009-10-14 at 16:35 -0700, Luis R. Rodriguez wrote:
> Well sure, but why do we want to keep the authentication present if
> association failed? And as a matter of fact it lingers there forever.
> Is that desired behaviour?
Yes, well, the SME is supposed to clean it up or try the association
again (possibly with different parameters in the IEs, e.g. different WPA
settings). The cfg80211 SME certainly does so (it deauthenticates).
> > > +++ b/net/mac80211/mlme.c
> > > @@ -1463,11 +1463,11 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
> > > if (status_code != WLAN_STATUS_SUCCESS) {
> > > printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
> > > sdata->dev->name, status_code);
> > > list_del(&wk->list);
> > > kfree(wk);
> > > - return RX_MGMT_CFG80211_ASSOC;
> > > + return RX_MGMT_CFG80211_DEAUTH;
> >
> > I'm sure this is correct. Maybe cfg80211 doesn't react properly to
> > getting an assoc frame with non-zero status?
>
> I see, will have to take a look when I get a chance then, not now though.
> Actually can you elaborate a little on the logic here as to why
> we want to issue an association command with non-zero status to
> cfg80211 instead of just knocking off the current authentication
> and killing the BSS?
Is the above sufficient? Btw, please don't talk about "killing the BSS",
you're not talking about a BSS struct but rather one of the mlme work
structs.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Xose Vazquez Perez @ 2009-10-16 11:12 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: users, Simon Raffeiner, linux-wireless
In-Reply-To: <200910161255.54644.IvDoorn@gmail.com>
On Fri, Oct 16, 2009 at 12:55, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> Well the main PCI and DEVICE id's should be listed in the PCI_DEVICE table,
> the SUBSYS ID should only be added in case there can be different drivers
> based on that ID.
>
> As far as the ID 1432:7728, that one was send by Xose who got the ID from
> the Windows driver, I don't know if he has mistakenly grabbed the subsystem ID or not...
> Xose, could you give an update about this?
It came from ralink linux driver.
See 2009_0918_RT2860_Linux_STA_v2.2.0.0/os/linux/pci_main_dev.c:
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2860_PCI_DEVICE_ID)},
//RT28602.4G
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2860_PCIe_DEVICE_ID)},
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2760_PCI_DEVICE_ID)},
{PCI_DEVICE(NIC_PCI_VENDOR_ID, NIC2790_PCIe_DEVICE_ID)},
{PCI_DEVICE(VEN_AWT_PCI_VENDOR_ID, VEN_AWT_PCIe_DEVICE_ID)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7708)},
->>>>> {PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7728)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7758)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7727)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7738)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7748)},
{PCI_DEVICE(EDIMAX_PCI_VENDOR_ID, 0x7768)},
regards,
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Ivo van Doorn @ 2009-10-16 10:55 UTC (permalink / raw)
To: users; +Cc: Simon Raffeiner, linux-wireless, Xose Vazquez Perez
In-Reply-To: <200910161149.11661.sturmflut@lieberbiber.de>
Hi,
> I was comparing rt2800pci and the INF file of the original RT2860 windows
> driver out curiosity. The original INF file contains 108 PCI id entries,
> rt2800pci.c only 20. At first I thought that an entry like
>
> PCI\VEN_1814&DEV_0601&SUBSYS_77281432
>
> (Edimax card) in the INF file will be automatically matched by rt2800pci for
> the "1814:0601" vendor/device id, but then I found an additional entry for
> "1432:7728" (the susbsystem id) in the rt2800pci pci_device_id table.
>
> I am a bit confused: Should every entry from the INF file have a PCI_DEVICE()
> counterpart in our driver (resulting in 108 entries), or is this a special
> case where the Manufacturer (Edimax) produces cards that actually have
> "1432:7728" as vendor/device id.
>
> You can probably tell that I don't have much experience developing kernel
> drivers, but I am willing to get it right.
Well the main PCI and DEVICE id's should be listed in the PCI_DEVICE table,
the SUBSYS ID should only be added in case there can be different drivers
based on that ID.
As far as the ID 1432:7728, that one was send by Xose who got the ID from
the Windows driver, I don't know if he has mistakenly grabbed the subsystem ID or not...
Xose, could you give an update about this?
Ivo
^ permalink raw reply
* Re: [PATCH 7/8] trivial: fix many typos s/untill/until/
From: Ivo van Doorn @ 2009-10-16 10:04 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: trivial, linux-rdma, linux-kernel, bonding-devel, netdev,
linux-wireless, users, linux-scsi, devel, linux-ext4,
linux-bluetooth, linux-sctp
In-Reply-To: <1255638072-6236-1-git-send-email-cascardo@holoscopio.com>
On Thursday 15 October 2009, Thadeu Lima de Souza Cascardo wrote:
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
For rt2800usb
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
> drivers/net/bonding/bond_alb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
> drivers/scsi/bnx2i/bnx2i_iscsi.c | 2 +-
> drivers/staging/rtl8187se/r8180.h | 2 +-
> fs/ext4/balloc.c | 2 +-
> net/bluetooth/bnep/core.c | 2 +-
> net/sctp/sm_statefuns.c | 2 +-
> 8 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c
> index ea9e155..8579f32 100644
> --- a/drivers/infiniband/ulp/iser/iser_verbs.c
> +++ b/drivers/infiniband/ulp/iser/iser_verbs.c
> @@ -499,7 +499,7 @@ void iser_conn_init(struct iser_conn *ib_conn)
>
> /**
> * starts the process of connecting to the target
> - * sleeps untill the connection is established or rejected
> + * sleeps until the connection is established or rejected
> */
> int iser_connect(struct iser_conn *ib_conn,
> struct sockaddr_in *src_addr,
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index 9b5936f..a1e7eb9 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -559,7 +559,7 @@ static void rlb_update_rx_clients(struct bonding *bond)
> }
> }
>
> - /* do not update the entries again untill this counter is zero so that
> + /* do not update the entries again until this counter is zero so that
> * not to confuse the clients.
> */
> bond_info->rlb_update_delay_counter = RLB_UPDATE_DELAY;
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index a084077..449886c 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -1257,7 +1257,7 @@ static int rt2800usb_init_registers(struct rt2x00_dev *rt2x00dev)
> unsigned int i;
>
> /*
> - * Wait untill BBP and RF are ready.
> + * Wait until BBP and RF are ready.
> */
> for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
> rt2x00usb_register_read(rt2x00dev, MAC_CSR0, ®);
> diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
> index cafb888..10110be 100644
> --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
> +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
> @@ -1883,7 +1883,7 @@ static void bnx2i_ep_disconnect(struct iscsi_endpoint *ep)
>
> bnx2i_ep = ep->dd_data;
>
> - /* driver should not attempt connection cleanup untill TCP_CONNECT
> + /* driver should not attempt connection cleanup until TCP_CONNECT
> * completes either successfully or fails. Timeout is 9-secs, so
> * wait for it to complete
> */
> diff --git a/drivers/staging/rtl8187se/r8180.h b/drivers/staging/rtl8187se/r8180.h
> index 8216d7e..35ed60b 100644
> --- a/drivers/staging/rtl8187se/r8180.h
> +++ b/drivers/staging/rtl8187se/r8180.h
> @@ -521,7 +521,7 @@ typedef struct r8180_priv
> //u32 NumTxOkInPeriod; //YJ,del,080828
> u8 TxPollingTimes;
>
> - bool bApBufOurFrame;// TRUE if AP buffer our unicast data , we will keep eAwake untill receive data or timeout.
> + bool bApBufOurFrame;// TRUE if AP buffer our unicast data , we will keep eAwake until receive data or timeout.
> u8 WaitBufDataBcnCount;
> u8 WaitBufDataTimeOut;
>
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index 1d04189..2565b8c 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -519,7 +519,7 @@ void ext4_free_blocks(handle_t *handle, struct inode *inode,
> metadata = 1;
>
> /* We need to make sure we don't reuse
> - * block released untill the transaction commit.
> + * block released until the transaction commit.
> * writeback mode have weak data consistency so
> * don't force data as metadata when freeing block
> * for writeback mode.
> diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
> index 1bd9398..9ac0497 100644
> --- a/net/bluetooth/bnep/core.c
> +++ b/net/bluetooth/bnep/core.c
> @@ -629,7 +629,7 @@ int bnep_del_connection(struct bnep_conndel_req *req)
> s = __bnep_get_session(req->dst);
> if (s) {
> /* Wakeup user-space which is polling for socket errors.
> - * This is temporary hack untill we have shutdown in L2CAP */
> + * This is temporary hack until we have shutdown in L2CAP */
> s->sock->sk->sk_err = EUNATCH;
>
> /* Kill session thread */
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index c8fae19..ba2f66d 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3569,7 +3569,7 @@ sctp_disposition_t sctp_sf_do_asconf(const struct sctp_endpoint *ep,
> * To do this properly, we'll set the destination address of the chunk
> * and at the transmit time, will try look up the transport to use.
> * Since ASCONFs may be bundled, the correct transport may not be
> - * created untill we process the entire packet, thus this workaround.
> + * created until we process the entire packet, thus this workaround.
> */
> asconf_ack->dest = chunk->source;
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(asconf_ack));
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: Implement support for rt2800pci
From: Simon Raffeiner @ 2009-10-16 9:49 UTC (permalink / raw)
To: users, linux-wireless
In-Reply-To: <200910152204.16407.IvDoorn@gmail.com>
Hello List,
I was comparing rt2800pci and the INF file of the original RT2860 windows
driver out curiosity. The original INF file contains 108 PCI id entries,
rt2800pci.c only 20. At first I thought that an entry like
PCI\VEN_1814&DEV_0601&SUBSYS_77281432
(Edimax card) in the INF file will be automatically matched by rt2800pci for
the "1814:0601" vendor/device id, but then I found an additional entry for
"1432:7728" (the susbsystem id) in the rt2800pci pci_device_id table.
I am a bit confused: Should every entry from the INF file have a PCI_DEVICE()
counterpart in our driver (resulting in 108 entries), or is this a special
case where the Manufacturer (Edimax) produces cards that actually have
"1432:7728" as vendor/device id.
You can probably tell that I don't have much experience developing kernel
drivers, but I am willing to get it right.
regards,
Simon Raffeiner
Am Donnerstag, 15. Oktober 2009 22:04:14 schrieb Ivo van Doorn:
> Add support for the rt2860/rt3090 chipsets from Ralink.
>
> Includes various patches from a lot of people who helped
> getting this driver into the current shape.
>
> Signed-off-by: Alban Browaeys <prahal@yahoo.com>
> Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Luis Correia <luis.f.correia@gmail.com>
> Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
> Signed-off-by: Mark Asselstine <asselsm@gmail.com>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> http://kernel.org/pub/linux/kernel/people/ivd/patches/0003-rt2x00-Implement
> -support-for-rt2800pci.patch --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] wl1251: add support for PG11 chips.
From: Kalle Valo @ 2009-10-16 8:37 UTC (permalink / raw)
To: John Willis; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <87vdifbyao.fsf@nokia.com>
Kalle Valo <kalle.valo@iki.fi> writes:
> John Willis <John.Willis@Distant-earth.com> writes:
>
>> From: David-John Willis <John.Willis@Distant-earth.com>
>>
>> This simple patch adds support for the PG11 variant of the WL1251 chip as
>> used on the OpenPandora OMAP3 device.
>>
>> Signed-off-by: David-John Willis <John.Willis@Distant-earth.com>
[...]
> This patch also enables PG10 support, but as that hardware revision is
> untested I think it's better not to enable it. I'll edit the patch a bit
> regarding this and then send it to John.
Oh, I noticed that Linville had already applied your patch. I'll send
a patch on top of this to fix the issue.
Linville, is this ok for you?
Too many Johns here :)
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] WL1251: Very crude EEPROM reading support for the WL1251 driver
From: Kalle Valo @ 2009-10-16 7:52 UTC (permalink / raw)
To: John Willis; +Cc: me, linux-wireless
In-Reply-To: <01c901ca4daf$6e3d7f20$4ab87d60$@Willis@Distant-earth.com>
"John Willis" <John.Willis@Distant-earth.com> writes:
> Gents,
>
> Attached are some very hacky (even after a quick cleanup) patches that add
> something like support for reading the EEPROM NVS calibration data into the
> WL1251 driver. It seems just good enough to get the driver up and playing
> nicely.
Thanks a lot, this is good stuff. Now we have all hardware
configurations (known by me) supported in wl1251: SPI, SDIO, without
EEPROM and with EEPROM.
> I quickly rebased the patches on the top of wireless-testing, with any luck
> they still work however I can't test as there is something badly borked for
> OMAP3 in the mainline tree feeding WT at the moment. I have left out a lot
> of my development chaff and rubbish from the patches.
In cases like this I usually merge linux-omap to wireless-testing,
it's quite simple and fast thing to do. That way I get the omap
hardware booting with latest wireless stuff.
> They have only been tested on OMAP3 OpenPandora boards using SDIO. I still
> think timing needs tweaking but I have not had a chance to look into that.
I have few comments about the patch. I think it's better to configure
EEPROM support runtime and not via Kconfig. Also I don't like
hungarian notation :)
Is it okay if I clean it up a bit and then send it to John Linville?
Better to have the patch in the tree as early as possible, as long as it
doesn't break existing functionality. We can always fix it later if
there's something broken.
Thanks again for your patches and please keep on sending them :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wl1251: add support for PG11 chips.
From: Kalle Valo @ 2009-10-16 7:19 UTC (permalink / raw)
To: John Willis; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <01c201ca4d9c$c2c44500$484ccf00$@Willis@Distant-earth.com>
John Willis <John.Willis@Distant-earth.com> writes:
> From: David-John Willis <John.Willis@Distant-earth.com>
>
> This simple patch adds support for the PG11 variant of the WL1251 chip as
> used on the OpenPandora OMAP3 device.
>
> Signed-off-by: David-John Willis <John.Willis@Distant-earth.com>
Thanks for the patch. And excellent news that it's working on your
device.
Minor comment:
> --- a/drivers/net/wireless/wl12xx/wl1251_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_main.c
> @@ -185,6 +185,9 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
> break;
> case CHIP_ID_1251_PG10:
> case CHIP_ID_1251_PG11:
> + wl1251_debug(DEBUG_BOOT, "chip id 0x%x (1251 PG11)",
> + wl->chip_id);
> + break;
> default:
> wl1251_error("unsupported chip id: 0x%x", wl->chip_id);
> ret = -ENODEV;
This patch also enables PG10 support, but as that hardware revision is
untested I think it's better not to enable it. I'll edit the patch a bit
regarding this and then send it to John.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/1] staging/stlc45xx: Fix compile error
From: Kalle Valo @ 2009-10-16 7:13 UTC (permalink / raw)
To: Greg KH
Cc: Javier Martinez Canillas, devel@driverdev.osuosl.org,
linux-wireless
In-Reply-To: <20091015031138.GB16633@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Oct 14, 2009 at 11:03:45PM -0400, Javier Martinez Canillas wrote:
>> I got the following compile error with today linux-next tree.
>>
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_reset’:
>> drivers/staging/stlc45xx/stlc45xx.c:1061: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_interrupt’:
>> drivers/staging/stlc45xx/stlc45xx.c:1492: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_wq_tx’:
>> drivers/staging/stlc45xx/stlc45xx.c:1571: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: In function ‘stlc45xx_op_tx’:
>> drivers/staging/stlc45xx/stlc45xx.c:2135: error: ‘struct ieee80211_hw’ has no member named ‘workqueue’
>> drivers/staging/stlc45xx/stlc45xx.c: At top level:
>> drivers/staging/stlc45xx/stlc45xx.c:2351: warning: initialization from incompatible pointer type
>>
>> The driver was trying to access directly to mac80211 workqueue. Use the helper functions instead.
>>
>> I think this patch solves the issue. Also fix a compile warning due a change in configure_filter() handler params.
>
> ah, good catch, I had that driver disabled in my builds for some stupid
> reason. I'll queue this up in my tree.
I think it's better to drop stlc45xx. As I haven't sent any patches for
few months is obvious that I don't have time to work on it anymore. And
p54spi should work now, at least I have seen positive reports on mailing
lists.
Greg, if you want I can send a patch removing stlc45xx.
--
Kalle Valo
^ permalink raw reply
* [PATCH 16/16] iwmc3200wifi: handle coexistence radio notification
From: Zhu Yi @ 2009-10-16 5:19 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1255670340-22565-16-git-send-email-yi.zhu@intel.com>
Handle WiFi/WiMax coexistence radio preemption notification event.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 95deb0a..bdb1d7e 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -733,6 +733,19 @@ static int iwm_mlme_update_sta_table(struct iwm_priv *iwm, u8 *buf,
return 0;
}
+static int iwm_mlme_medium_lost(struct iwm_priv *iwm, u8 *buf,
+ unsigned long buf_size,
+ struct iwm_wifi_cmd *cmd)
+{
+ struct wiphy *wiphy = iwm_to_wiphy(iwm);
+
+ IWM_DBG_NTF(iwm, DBG, "WiFi/WiMax coexistence radio is OFF\n");
+
+ wiphy_rfkill_set_hw_state(wiphy, true);
+
+ return 0;
+}
+
static int iwm_mlme_update_bss_table(struct iwm_priv *iwm, u8 *buf,
unsigned long buf_size,
struct iwm_wifi_cmd *cmd)
@@ -919,6 +932,8 @@ static int iwm_ntf_mlme(struct iwm_priv *iwm, u8 *buf,
case WIFI_IF_NTFY_EXTENDED_IE_REQUIRED:
IWM_DBG_MLME(iwm, DBG, "Extended IE required\n");
break;
+ case WIFI_IF_NTFY_RADIO_PREEMPTION:
+ return iwm_mlme_medium_lost(iwm, buf, buf_size, cmd);
case WIFI_IF_NTFY_BSS_TRK_TABLE_CHANGED:
return iwm_mlme_update_bss_table(iwm, buf, buf_size, cmd);
case WIFI_IF_NTFY_BSS_TRK_ENTRIES_REMOVED:
--
1.6.0.4
^ permalink raw reply related
* [PATCH 15/16] iwmc3200wifi: Set wiphy firmware version
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-15-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
Our wiphy firmware version is a combination of the UMAC and LMAC ones.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/fw.c | 7 +++++++
drivers/net/wireless/iwmc3200wifi/iwm.h | 2 ++
drivers/net/wireless/iwmc3200wifi/main.c | 4 ++++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/fw.c b/drivers/net/wireless/iwmc3200wifi/fw.c
index f02d571..4906709 100644
--- a/drivers/net/wireless/iwmc3200wifi/fw.c
+++ b/drivers/net/wireless/iwmc3200wifi/fw.c
@@ -217,6 +217,13 @@ static int iwm_load_img(struct iwm_priv *iwm, const char *img_name)
IWM_BUILD_YEAR(build_date), IWM_BUILD_MONTH(build_date),
IWM_BUILD_DAY(build_date));
+ if (!strcmp(img_name, iwm->bus_ops->umac_name))
+ sprintf(iwm->umac_version, "%02X.%02X",
+ ver->major, ver->minor);
+
+ if (!strcmp(img_name, iwm->bus_ops->lmac_name))
+ sprintf(iwm->lmac_version, "%02X.%02X",
+ ver->major, ver->minor);
err_release_fw:
release_firmware(fw);
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index c4a01f2..a9bf6bc 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -294,6 +294,8 @@ struct iwm_priv {
int resp_ie_len;
struct iwm_fw_error_hdr *last_fw_err;
+ char umac_version[8];
+ char lmac_version[8];
char private[0] __attribute__((__aligned__(NETDEV_ALIGN)));
};
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index 97c6f5a..75f105a 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -629,6 +629,7 @@ static int __iwm_up(struct iwm_priv *iwm)
{
int ret;
struct iwm_notif *notif_reboot, *notif_ack = NULL;
+ struct wiphy *wiphy = iwm_to_wiphy(iwm);
ret = iwm_bus_enable(iwm);
if (ret) {
@@ -690,6 +691,9 @@ static int __iwm_up(struct iwm_priv *iwm)
goto err_disable;
}
+ snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "L%s_U%s",
+ iwm->lmac_version, iwm->umac_version);
+
/* We configure the UMAC and enable the wifi module */
ret = iwm_send_umac_config(iwm,
cpu_to_le32(UMAC_RST_CTRL_FLG_WIFI_CORE_EN) |
--
1.6.0.4
^ permalink raw reply related
* [PATCH 14/16] iwmc3200wifi: Support unexpected reboot barker
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-14-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
We can receive unexpected reboot barker at any time, and we're supposed to
reset the whole device then.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index c0fa853..95deb0a 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -1322,6 +1322,14 @@ int iwm_rx_handle(struct iwm_priv *iwm, u8 *buf, unsigned long buf_size)
switch (le32_to_cpu(hdr->cmd)) {
case UMAC_REBOOT_BARKER:
+ if (test_bit(IWM_STATUS_READY, &iwm->status)) {
+ IWM_ERR(iwm, "Unexpected BARKER\n");
+
+ schedule_work(&iwm->reset_worker);
+
+ return 0;
+ }
+
return iwm_notif_send(iwm, NULL, IWM_BARKER_REBOOT_NOTIFICATION,
IWM_SRC_UDMA, buf, buf_size);
case UMAC_ACK_BARKER:
--
1.6.0.4
^ permalink raw reply related
* [PATCH 13/16] iwmc3200wifi: Try shared auth when open WEP fails
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-13-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
When we fail to associate with an open WEP AP, we fall back to shared auth.
This allows us to support joining a shared auth WEP AP with iwconfig.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/commands.c | 2 +-
drivers/net/wireless/iwmc3200wifi/iwm.h | 1 +
drivers/net/wireless/iwmc3200wifi/main.c | 28 ++++++++++++++++++++++++++
drivers/net/wireless/iwmc3200wifi/rx.c | 28 +++++++++++++++++++++----
4 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.c b/drivers/net/wireless/iwmc3200wifi/commands.c
index 2911ace..7e12438 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.c
+++ b/drivers/net/wireless/iwmc3200wifi/commands.c
@@ -794,7 +794,7 @@ int iwm_invalidate_mlme_profile(struct iwm_priv *iwm)
return ret;
ret = wait_event_interruptible_timeout(iwm->mlme_queue,
- (iwm->umac_profile_active == 0), 2 * HZ);
+ (iwm->umac_profile_active == 0), 5 * HZ);
return ret ? 0 : -EBUSY;
}
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index fe0ab80..c4a01f2 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -285,6 +285,7 @@ struct iwm_priv {
u8 *eeprom;
struct timer_list watchdog;
struct work_struct reset_worker;
+ struct work_struct auth_retry_worker;
struct mutex mutex;
u8 *req_ie;
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index dfc8fd4..97c6f5a 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -208,6 +208,33 @@ static void iwm_reset_worker(struct work_struct *work)
mutex_unlock(&iwm->mutex);
}
+static void iwm_auth_retry_worker(struct work_struct *work)
+{
+ struct iwm_priv *iwm;
+ int i, ret;
+
+ iwm = container_of(work, struct iwm_priv, auth_retry_worker);
+ if (iwm->umac_profile_active) {
+ ret = iwm_invalidate_mlme_profile(iwm);
+ if (ret < 0)
+ return;
+ }
+
+ iwm->umac_profile->sec.auth_type = UMAC_AUTH_TYPE_LEGACY_PSK;
+
+ ret = iwm_send_mlme_profile(iwm);
+ if (ret < 0)
+ return;
+
+ for (i = 0; i < IWM_NUM_KEYS; i++)
+ if (iwm->keys[i].key_len)
+ iwm_set_key(iwm, 0, &iwm->keys[i]);
+
+ iwm_set_tx_key(iwm, iwm->default_key);
+}
+
+
+
static void iwm_watchdog(unsigned long data)
{
struct iwm_priv *iwm = (struct iwm_priv *)data;
@@ -241,6 +268,7 @@ int iwm_priv_init(struct iwm_priv *iwm)
INIT_DELAYED_WORK(&iwm->disconnect, iwm_disconnect_work);
INIT_DELAYED_WORK(&iwm->ct_kill_delay, iwm_ct_kill_work);
INIT_WORK(&iwm->reset_worker, iwm_reset_worker);
+ INIT_WORK(&iwm->auth_retry_worker, iwm_auth_retry_worker);
INIT_LIST_HEAD(&iwm->bss_list);
skb_queue_head_init(&iwm->rx_list);
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 0fa3f5c..c0fa853 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -502,6 +502,18 @@ static int iwm_mlme_assoc_start(struct iwm_priv *iwm, u8 *buf,
return 0;
}
+static u8 iwm_is_open_wep_profile(struct iwm_priv *iwm)
+{
+ if ((iwm->umac_profile->sec.ucast_cipher == UMAC_CIPHER_TYPE_WEP_40 ||
+ iwm->umac_profile->sec.ucast_cipher == UMAC_CIPHER_TYPE_WEP_104) &&
+ (iwm->umac_profile->sec.ucast_cipher ==
+ iwm->umac_profile->sec.mcast_cipher) &&
+ (iwm->umac_profile->sec.auth_type == UMAC_AUTH_TYPE_OPEN))
+ return 1;
+
+ return 0;
+}
+
static int iwm_mlme_assoc_complete(struct iwm_priv *iwm, u8 *buf,
unsigned long buf_size,
struct iwm_wifi_cmd *cmd)
@@ -567,11 +579,17 @@ static int iwm_mlme_assoc_complete(struct iwm_priv *iwm, u8 *buf,
goto ibss;
if (!test_bit(IWM_STATUS_RESETTING, &iwm->status))
- cfg80211_connect_result(iwm_to_ndev(iwm),
- complete->bssid,
- NULL, 0, NULL, 0,
- WLAN_STATUS_UNSPECIFIED_FAILURE,
- GFP_KERNEL);
+ if (!iwm_is_open_wep_profile(iwm)) {
+ cfg80211_connect_result(iwm_to_ndev(iwm),
+ complete->bssid,
+ NULL, 0, NULL, 0,
+ WLAN_STATUS_UNSPECIFIED_FAILURE,
+ GFP_KERNEL);
+ } else {
+ /* Let's try shared WEP auth */
+ IWM_ERR(iwm, "Trying WEP shared auth\n");
+ schedule_work(&iwm->auth_retry_worker);
+ }
else
cfg80211_disconnected(iwm_to_ndev(iwm), 0, NULL, 0,
GFP_KERNEL);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 11/16] iwmc3200wifi: Check for cmd pointer before dereferencing it
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-11-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
The wifi_if_wrapper notification handling code uses a cmd pointer without
checking if it's valid or not. We're dereferencing it because we assume that
we only get to that point if there was a pending command for us. That's not
always true, so we'd better check.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index a6b1811..0fa3f5c 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -1058,8 +1058,14 @@ static int iwm_ntf_wifi_if_wrapper(struct iwm_priv *iwm, u8 *buf,
unsigned long buf_size,
struct iwm_wifi_cmd *cmd)
{
- struct iwm_umac_wifi_if *hdr =
- (struct iwm_umac_wifi_if *)cmd->buf.payload;
+ struct iwm_umac_wifi_if *hdr;
+
+ if (cmd == NULL) {
+ IWM_ERR(iwm, "Couldn't find expected wifi command\n");
+ return -EINVAL;
+ }
+
+ hdr = (struct iwm_umac_wifi_if *)cmd->buf.payload;
IWM_DBG_NTF(iwm, DBG, "WIFI_IF_WRAPPER cmd is delivered to UMAC: "
"oid is 0x%x\n", hdr->oid);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 12/16] iwmc3200wifi: Do not handle wifi command if the interface is not ready
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-12-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
When resetting or bringing the interface down, we should just reject any wifi
related command.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/commands.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.c b/drivers/net/wireless/iwmc3200wifi/commands.c
index 0641bc7..2911ace 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.c
+++ b/drivers/net/wireless/iwmc3200wifi/commands.c
@@ -77,6 +77,11 @@ int iwm_send_wifi_if_cmd(struct iwm_priv *iwm, void *payload, u16 payload_size,
int ret;
u8 oid = hdr->oid;
+ if (!test_bit(IWM_STATUS_READY, &iwm->status)) {
+ IWM_ERR(iwm, "Interface is not ready yet");
+ return -EAGAIN;
+ }
+
umac_cmd.id = UMAC_CMD_OPCODE_WIFI_IF_WRAPPER;
umac_cmd.resp = resp;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 10/16] iwmc3200wifi: SDIO disable race fix
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-10-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
When calling sdio->bus_disable(), we are flushing the command lists before
disabling the sdio function. We can thus potentially get a command response
after having flushed the command list.
To avoid that race, we have to call iwm_reset() after disabling the sdio
function.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/sdio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.c b/drivers/net/wireless/iwmc3200wifi/sdio.c
index 38026b7..cf86294 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.c
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.c
@@ -224,8 +224,6 @@ static int if_sdio_disable(struct iwm_priv *iwm)
struct iwm_sdio_priv *hw = iwm_to_if_sdio(iwm);
int ret;
- iwm_reset(iwm);
-
sdio_claim_host(hw->func);
sdio_writeb(hw->func, 0, IWM_SDIO_INTR_ENABLE_ADDR, &ret);
if (ret < 0)
@@ -237,6 +235,8 @@ static int if_sdio_disable(struct iwm_priv *iwm)
iwm_sdio_rx_free(hw);
+ iwm_reset(iwm);
+
IWM_DBG_SDIO(iwm, INFO, "IWM SDIO disable\n");
return 0;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 09/16] iwmc3200wifi: Tx power setting
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-9-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
We can now set the Tx power from e.g. iwconfig.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 12 +++++++++++-
drivers/net/wireless/iwmc3200wifi/commands.c | 13 +++++++++++++
drivers/net/wireless/iwmc3200wifi/commands.h | 6 ++++++
3 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/cfg80211.c b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
index ea0ed32..2e00a4b 100644
--- a/drivers/net/wireless/iwmc3200wifi/cfg80211.c
+++ b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
@@ -671,9 +671,19 @@ static int iwm_cfg80211_disconnect(struct wiphy *wiphy, struct net_device *dev,
static int iwm_cfg80211_set_txpower(struct wiphy *wiphy,
enum tx_power_setting type, int dbm)
{
+ struct iwm_priv *iwm = wiphy_to_iwm(wiphy);
+ int ret;
+
switch (type) {
case TX_POWER_AUTOMATIC:
return 0;
+ case TX_POWER_FIXED:
+ ret = iwm_umac_set_config_fix(iwm, UMAC_PARAM_TBL_CFG_FIX,
+ CFG_TX_PWR_LIMIT_USR, dbm * 2);
+ if (ret < 0)
+ return ret;
+
+ return iwm_tx_power_trigger(iwm);
default:
return -EOPNOTSUPP;
}
@@ -685,7 +695,7 @@ static int iwm_cfg80211_get_txpower(struct wiphy *wiphy, int *dbm)
{
struct iwm_priv *iwm = wiphy_to_iwm(wiphy);
- *dbm = iwm->txpower;
+ *dbm = iwm->txpower >> 1;
return 0;
}
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.c b/drivers/net/wireless/iwmc3200wifi/commands.c
index 1ba839c..0641bc7 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.c
+++ b/drivers/net/wireless/iwmc3200wifi/commands.c
@@ -794,6 +794,19 @@ int iwm_invalidate_mlme_profile(struct iwm_priv *iwm)
return ret ? 0 : -EBUSY;
}
+int iwm_tx_power_trigger(struct iwm_priv *iwm)
+{
+ struct iwm_umac_pwr_trigger pwr_trigger;
+
+ pwr_trigger.hdr.oid = UMAC_WIFI_IF_CMD_TX_PWR_TRIGGER;
+ pwr_trigger.hdr.buf_size =
+ cpu_to_le16(sizeof(struct iwm_umac_pwr_trigger) -
+ sizeof(struct iwm_umac_wifi_if));
+
+
+ return iwm_send_wifi_if_cmd(iwm, &pwr_trigger, sizeof(pwr_trigger), 1);
+}
+
int iwm_send_umac_stats_req(struct iwm_priv *iwm, u32 flags)
{
struct iwm_udma_wifi_cmd udma_cmd = UDMA_UMAC_INIT;
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.h b/drivers/net/wireless/iwmc3200wifi/commands.h
index 511b6e3..b36be2b 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.h
+++ b/drivers/net/wireless/iwmc3200wifi/commands.h
@@ -441,6 +441,11 @@ struct iwm_umac_tx_key_id {
u8 reserved[3];
} __attribute__ ((packed));
+struct iwm_umac_pwr_trigger {
+ struct iwm_umac_wifi_if hdr;
+ __le32 reseved;
+} __attribute__ ((packed));
+
struct iwm_umac_cmd_stats_req {
__le32 flags;
} __attribute__ ((packed));
@@ -467,6 +472,7 @@ int iwm_invalidate_mlme_profile(struct iwm_priv *iwm);
int iwm_send_packet(struct iwm_priv *iwm, struct sk_buff *skb, int pool_id);
int iwm_set_tx_key(struct iwm_priv *iwm, u8 key_idx);
int iwm_set_key(struct iwm_priv *iwm, bool remove, struct iwm_key *key);
+int iwm_tx_power_trigger(struct iwm_priv *iwm);
int iwm_send_umac_stats_req(struct iwm_priv *iwm, u32 flags);
int iwm_send_umac_channel_list(struct iwm_priv *iwm);
int iwm_scan_ssids(struct iwm_priv *iwm, struct cfg80211_ssid *ssids,
--
1.6.0.4
^ permalink raw reply related
* [PATCH 08/16] iwmc3200wifi: Update fixed size config definitions
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-8-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
We need to be in sync with the latest firmware API.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/commands.h | 60 +++++++++++++++++++++++++-
1 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.h b/drivers/net/wireless/iwmc3200wifi/commands.h
index e486f8e..511b6e3 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.h
+++ b/drivers/net/wireless/iwmc3200wifi/commands.h
@@ -102,7 +102,6 @@ enum {
CFG_SCAN_NUM_PASSIVE_CHAN_PER_PARTIAL_SCAN,
CFG_TLC_SUPPORTED_TX_HT_RATES,
CFG_TLC_SUPPORTED_TX_RATES,
- CFG_TLC_VALID_ANTENNA,
CFG_TLC_SPATIAL_STREAM_SUPPORTED,
CFG_TLC_RETRY_PER_RATE,
CFG_TLC_RETRY_PER_HT_RATE,
@@ -136,6 +135,10 @@ enum {
CFG_TLC_RENEW_ADDBA_DELAY,
CFG_TLC_NUM_OF_MULTISEC_TO_COUN_LOAD,
CFG_TLC_IS_STABLE_IN_HT,
+ CFG_TLC_SR_SIC_1ST_FAIL,
+ CFG_TLC_SR_SIC_1ST_PASS,
+ CFG_TLC_SR_SIC_TOTAL_FAIL,
+ CFG_TLC_SR_SIC_TOTAL_PASS,
CFG_RLC_CHAIN_CTRL,
CFG_TRK_TABLE_OP_MODE,
CFG_TRK_TABLE_RSSI_THRESHOLD,
@@ -147,6 +150,58 @@ enum {
CFG_MLME_DBG_NOTIF_BLOCK,
CFG_BT_OFF_BECONS_INTERVALS,
CFG_BT_FRAG_DURATION,
+ CFG_ACTIVE_CHAINS,
+ CFG_CALIB_CTRL,
+ CFG_CAPABILITY_SUPPORTED_HT_RATES,
+ CFG_HT_MAC_PARAM_INFO,
+ CFG_MIMO_PS_MODE,
+ CFG_HT_DEFAULT_CAPABILIES_INFO,
+ CFG_LED_SC_RESOLUTION_FACTOR,
+ CFG_PTAM_ENERGY_CCK_DET_DEFAULT,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MRC_DEFAULT,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_DEFAULT,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MRC_DEFAULT,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_DEFAULT,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MRC_DEFAULT,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_DEFAULT,
+ CFG_PTAM_ENERGY_CCK_DET_MIN_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MRC_MIN_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MIN_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MRC_MIN_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MIN_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MRC_MIN_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MIN_VAL,
+ CFG_PTAM_ENERGY_CCK_DET_MAX_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MRC_MAX_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MAX_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MRC_MAX_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MAX_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MRC_MAX_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MAX_VAL,
+ CFG_PTAM_ENERGY_CCK_DET_STEP_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_MRC_STEP_VAL,
+ CFG_PTAM_CORR40_4_TH_ADD_MIN_STEP_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_MRC_STEP_VAL,
+ CFG_PTAM_CORR32_4_TH_ADD_MIN_STEP_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_MRC_STEP_VAL,
+ CFG_PTAM_CORR32_1_TH_ADD_MIN_STEP_VAL,
+ CFG_PTAM_LINK_SENS_FA_OFDM_MAX,
+ CFG_PTAM_LINK_SENS_FA_OFDM_MIN,
+ CFG_PTAM_LINK_SENS_FA_CCK_MAX,
+ CFG_PTAM_LINK_SENS_FA_CCK_MIN,
+ CFG_PTAM_LINK_SENS_NRG_DIFF,
+ CFG_PTAM_LINK_SENS_NRG_MARGIN,
+ CFG_PTAM_LINK_SENS_MAX_NUMBER_OF_TIMES_IN_CCK_NO_FA,
+ CFG_PTAM_LINK_SENS_AUTO_CORR_MAX_TH_CCK,
+ CFG_AGG_MGG_TID_LOAD_ADDBA_THRESHOLD,
+ CFG_AGG_MGG_TID_LOAD_DELBA_THRESHOLD,
+ CFG_AGG_MGG_ADDBA_BUF_SIZE,
+ CFG_AGG_MGG_ADDBA_INACTIVE_TIMEOUT,
+ CFG_AGG_MGG_ADDBA_DEBUG_FLAGS,
+ CFG_SCAN_PERIODIC_RSSI_HIGH_THRESHOLD,
+ CFG_SCAN_PERIODIC_COEF_RSSI_HIGH,
+ CFG_11D_ENABLED,
+ CFG_11H_FEATURE_FLAGS,
/* <-- LAST --> */
CFG_TBL_FIX_LAST
@@ -155,7 +210,8 @@ enum {
/* variable size table */
enum {
CFG_NET_ADDR = 0,
- CFG_PROFILE,
+ CFG_LED_PATTERN_TABLE,
+
/* <-- LAST --> */
CFG_TBL_VAR_LAST
};
--
1.6.0.4
^ permalink raw reply related
* [PATCH 07/16] iwmc3200wifi: Update statistics notification structure
From: Zhu Yi @ 2009-10-16 5:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Samuel Ortiz, Zhu Yi
In-Reply-To: <1255670340-22565-7-git-send-email-yi.zhu@intel.com>
From: Samuel Ortiz <sameo@linux.intel.com>
The latest firmware adds a ht_rates and a chain_energy field. The latter is
needed as we want to eventually support RSSI/antenna handling.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/umac.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/umac.h b/drivers/net/wireless/iwmc3200wifi/umac.h
index c5a14ae..be90354 100644
--- a/drivers/net/wireless/iwmc3200wifi/umac.h
+++ b/drivers/net/wireless/iwmc3200wifi/umac.h
@@ -687,6 +687,9 @@ struct iwm_umac_notif_rx_ticket {
/* Tx/Rx rates window (number of max of last update window per second) */
#define UMAC_NTF_RATE_SAMPLE_NR 4
+/* Max numbers of bits required to go through all antennae in bitmasks */
+#define UMAC_PHY_NUM_CHAINS 3
+
#define IWM_UMAC_MGMT_TID 8
#define IWM_UMAC_TID_NR 8
@@ -697,9 +700,11 @@ struct iwm_umac_notif_stats {
__le16 tid_load[IWM_UMAC_TID_NR + 2]; /* 1 non-QoS + 1 dword align */
__le16 tx_rate[UMAC_NTF_RATE_SAMPLE_NR];
__le16 rx_rate[UMAC_NTF_RATE_SAMPLE_NR];
+ __le32 chain_energy[UMAC_PHY_NUM_CHAINS];
s32 rssi_dbm;
s32 noise_dbm;
__le32 supp_rates;
+ __le32 supp_ht_rates;
__le32 missed_beacons;
__le32 rx_beacons;
__le32 rx_dir_pkts;
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox