* [PATCH v2] b43: Enable LP-PHY support by default and remove Kconfig warning
From: Gábor Stefanik @ 2009-08-27 15:24 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
The most common LP-PHY device, BCM4312, is now fully functional.
So, no need to say "probably won't work for you" anymore.
It's also not "for debuggers and developers only", as it is
perfectly usable for end-users now (at least for BCM4312).
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
This replaces the "remove scary message" patch.
V2: Fix pastebin damage.
drivers/net/wireless/b43/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 237b1aa..2af3b35 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -82,15 +82,13 @@ config B43_NPHY
config B43_PHY_LP
bool "Support for low-power (LP-PHY) devices (EXPERIMENTAL)"
depends on B43 && EXPERIMENTAL
+ default y
---help---
Support for the LP-PHY.
The LP-PHY is a low-power PHY built into some notebooks
and embedded devices. It supports 802.11a/g
(802.11a support is optional, and currently disabled).
- This is heavily experimental, and probably will not work for you.
- Say N unless you want to help debug the driver.
-
# This config option automatically enables b43 LEDS support,
# if it's possible.
config B43_LEDS
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH] b43: Enable LP-PHY support by default and remove Kconfig warning
From: Gábor Stefanik @ 2009-08-27 15:19 UTC (permalink / raw)
To: Larry Finger
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <4A96A239.9000406@lwfinger.net>
2009/8/27 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>> The most common LP-PHY device, BCM4312, is now fully functional.
>> So, no need to say "probably won't work for you" anymore.
>> It's also not "for debuggers and developers only", as it is
>> perfectly usable for end-users now (at least for BCM4312).
>>
>> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
>> ---
>> This replaces the "remove scary message" patch.
>>
>> drivers/net/wireless/b43/Kconfig | 4 +---
>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/Kconfig
>> b/drivers/net/wireless/b43/Kconfig
>> index 237b1aa..2af3b35 100644
>> --- a/drivers/net/wireless/b43/Kconfig
>> +++ b/drivers/net/wireless/b43/Kconfig
>> -82,15 +82,13 @@ config B43_NPHY
> ===
>
> My copy of this patch is missing the @@ here. Is that true for everyone?
>
> Larry
>
Ah... the joy of Pastebin.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] b43: Enable LP-PHY support by default and remove Kconfig warning
From: Larry Finger @ 2009-08-27 15:11 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <4A969572.7060807@gmail.com>
Gábor Stefanik wrote:
> The most common LP-PHY device, BCM4312, is now fully functional.
> So, no need to say "probably won't work for you" anymore.
> It's also not "for debuggers and developers only", as it is
> perfectly usable for end-users now (at least for BCM4312).
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> ---
> This replaces the "remove scary message" patch.
>
> drivers/net/wireless/b43/Kconfig | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/Kconfig
> b/drivers/net/wireless/b43/Kconfig
> index 237b1aa..2af3b35 100644
> --- a/drivers/net/wireless/b43/Kconfig
> +++ b/drivers/net/wireless/b43/Kconfig
> -82,15 +82,13 @@ config B43_NPHY
===
My copy of this patch is missing the @@ here. Is that true for everyone?
Larry
^ permalink raw reply
* Re: [PATCH] iwlagn: show_version() displays confusing/wrong firmware version
From: reinette chatre @ 2009-08-27 14:57 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Zhu, Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1251379989-20728-1-git-send-email-bjorn@mork.no>
Hi Bjørn,
Which kernel/repo is your patch based on?
On Thu, 2009-08-27 at 06:33 -0700, Bjørn Mork wrote:
> The output of show_version() is confusing at best, and can also be
> considered wrong
Correct. Since this information is already printed in the system logs we
determined that the version sysfs file is not needed and has been
removed. Your patch is thus not relevant to the recent code
(wireless-testing repository).
Here is the patch for your reference:
commit 44f313c2e63dcf93b17e6a43769105e487e2e49d
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date: Fri Jul 31 14:28:09 2009 -0700
iwlwifi: remove duplicated version info from sysfs
version info in sysfs had been determined to be unnecessary as it
is already provided in syslog info. nvm version is added to syslog
version info as a debug level message to provide all info that was
in the version sysfs data.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reinette
^ permalink raw reply
* [PATCH] b43: Enable LP-PHY support by default and remove Kconfig warning
From: Gábor Stefanik @ 2009-08-27 14:17 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
The most common LP-PHY device, BCM4312, is now fully functional.
So, no need to say "probably won't work for you" anymore.
It's also not "for debuggers and developers only", as it is
perfectly usable for end-users now (at least for BCM4312).
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
This replaces the "remove scary message" patch.
drivers/net/wireless/b43/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index 237b1aa..2af3b35 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
-82,15 +82,13 @@ config B43_NPHY
config B43_PHY_LP
bool "Support for low-power (LP-PHY) devices (EXPERIMENTAL)"
depends on B43 && EXPERIMENTAL
+ default y
---help---
Support for the LP-PHY.
The LP-PHY is a low-power PHY built into some notebooks
and embedded devices. It supports 802.11a/g
(802.11a support is optional, and currently disabled).
- This is heavily experimental, and probably will not work for you.
- Say N unless you want to help debug the driver.
-
# This config option automatically enables b43 LEDS support,
# if it's possible.
config B43_LEDS
--
1.6.2.4
^ permalink raw reply
* Re: [PATCH] rndis_wlan: increase scan timer delay
From: Dan Williams @ 2009-08-27 14:09 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090827134340.190465b7qixz4wao@naisho.dyndns.info>
On Thu, 2009-08-27 at 13:43 +0300, Jussi Kivilinna wrote:
> Please, don't merge this after all. Blocks scan too long and breaks
> NetworkManager/wpa_supplicant.
Hmm, it shouldn't. I've seen other cards (ath5k a/b/g) take 5 to 8
seconds to scan when they scan all the bands. iwlwifi sometimes takes 5
seconds to scan as well. That should all be valid.
Can you get some wpa_supplicant runs with "-dddt" that show the problem
you're having? NM uses the supplicant for all scanning activity. It
shouldn't really "break" NM, so if it does I'd like to fix that.
Dan
^ permalink raw reply
* Re: libertas wext.c: IW_ENCODE_NOKEY for WEP keys [resend as plain text]
From: Dan Williams @ 2009-08-27 14:06 UTC (permalink / raw)
To: Bing Zhao
Cc: libertas-dev@lists.infradead.org, dwmw2@infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <477F20668A386D41ADCC57781B1F704306D2369E90@SC-VEXCH1.marvell.com>
On Wed, 2009-08-26 at 12:11 -0700, Bing Zhao wrote:
> Hi all,
>
> There was a commit to unset the IW_ENCODE_NOKEY flag for WEP keys.
>
> "libertas: Don't set IW_ENCODE_NOKEY when returning WEP keys."
>
>
> Without this change, the IW_ENCODE_NOKEY flag is set for WEP keys and then iwconfig command would display "****-****-**" as "Encryption key".
>
> After this change, the IW_ENCODE_NOKEY flag is NOT set for WEP keys and then iwconfig command will display plain text of the WEP key ("1234-5678-90" in my case, below).
mac82011 doesn't set NOKEY in cfg80211_wext_giwencode(). I guess we
should ask if *all* drivers should set NOKEY and then be consistent.
Dan
> eth1 IEEE 802.11b/g ESSID:"Cisco1-G"
> Mode:Managed Frequency:2.462 GHz Access Point: 00:1D:45:CE:20:D0
> Bit Rate:54 Mb/s Tx-Power=15 dBm
> Retry short limit:8 RTS thr=2347 B Fragment thr=2346 B
>
> Encryption key:1234-5678-90 Security mode:open
>
> Power Management:off
> Link Quality=92/100 Signal level=-66 dBm Noise level=-94 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
>
> Was there any reason to not set IW_ENCODE_NOKEY for WEP keys?
> Is it feasible to set IW_ENCODE_NOKEY for WEP switch case?
>
> --- a/drivers/net/wireless/libertas/wext.c
> +++ b/drivers/net/wireless/libertas/wext.c
> @@ -1165,6 +1165,7 @@ static int lbs_get_encode(struct net_device *dev,
> dwrq->flags |= (index + 1);
> /* Return WEP enabled */
> dwrq->flags &= ~IW_ENCODE_DISABLED;
> + dwrq->flags |= IW_ENCODE_NOKEY;
> } else if ((priv->secinfo.WPAenabled)
> || (priv->secinfo.WPA2enabled)) {
> /* return WPA enabled */
>
>
> Thanks for your help,
>
> Bing
>
^ permalink raw reply
* Re: Nokia N900 running mac80211
From: John W. Linville @ 2009-08-27 13:52 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87k50plbd8.fsf@nokia.com>
On Thu, Aug 27, 2009 at 02:55:31PM +0300, Kalle Valo wrote:
> Hello,
>
> wanted to tell you that just released Nokia N900 is using mac80211 and
> wl1251 driver. The kernel is 2.6.28 with few wireless related patches
> backported from newer releases and some hacks related to roaming.
>
> http://www.nokia.com/press/press-releases/showpressrelease?newsid=1337594
Hey, that is cool! Let's hope other manufacturers learn to embrace
the open code in the kernel and abandon closed-source options that
merely reimplement functionality that we already provide.
Let's also hope that this continues to motivate Nokia to support you
are your coworkers in making strong contributions to the kernel in
wireless and other areas.
Thanks!
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
* [PATCH] iwlagn: show_version() displays confusing/wrong firmware version
From: Bjørn Mork @ 2009-08-27 13:33 UTC (permalink / raw)
To: Zhu Yi, Reinette Chatre; +Cc: linux-wireless, Bjørn Mork
The output of show_version() is confusing at best, and can also be
considered wrong if you don't know that the order of the API and
SERIAL number has been switched. The unusual dotted hex is also
unecessary unreadable and different from the filename convention and
outout from iwl_read_ucode():
bjorn@nemi:~$ cat /sys/class/net/wlan0/device/version
fw version: 0x8.0x18.0xC.0x2
fw type: 0x1 0x0
EEPROM version: 0x11e
iwl_read_ucode() prints this when loading the same firmware:
[ 21.406218] iwlagn 0000:03:00.0: firmware: requesting iwlwifi-5000-2.ucode
[ 21.453118] iwlagn 0000:03:00.0: loaded firmware version 8.24.2.12
Note that I have no documentation on the intended usage of the
u8 sw_rev[8] array in struct iwl_alive_resp. sw_rev[0] and sw_rev[1]
have been switched to make the output match iwl_read_ucode(). Nothing
more, nothing less.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 355f50e..1a1ccb4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2498,10 +2498,10 @@ static ssize_t show_version(struct device *d,
if (palive->is_valid)
pos += sprintf(buf + pos,
- "fw version: 0x%01X.0x%01X.0x%01X.0x%01X\n"
+ "fw version: %u.%u.%u.%u\n"
"fw type: 0x%01X 0x%01X\n",
palive->ucode_major, palive->ucode_minor,
- palive->sw_rev[0], palive->sw_rev[1],
+ palive->sw_rev[1], palive->sw_rev[0],
palive->ver_type, palive->ver_subtype);
else
pos += sprintf(buf + pos, "fw not loaded\n");
--
1.5.6.5
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Nick Kossifidis @ 2009-08-27 13:10 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023009.21926.49329.stgit@mj.roinet.com>
2009/8/27 Pavel Roskin <proski@gnu.org>:
> AR5K_SREV is available even if the chip has been put to sleep. Relying
> on the chip register allows binding non-standard PCI IDs by
>
> echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
>
> without having to specify the driver data as well.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
> drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
> drivers/net/wireless/ath/ath5k/attach.c | 14 +++++++----
> drivers/net/wireless/ath/ath5k/base.c | 38 ++++++++++++++++---------------
> 3 files changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
> index cdc79cd..c2d4c6a 100644
> --- a/drivers/net/wireless/ath/ath5k/ath5k.h
> +++ b/drivers/net/wireless/ath/ath5k/ath5k.h
> @@ -1159,7 +1159,7 @@ struct ath5k_hw {
> */
>
> /* Attach/Detach Functions */
> -extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version);
> +extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc);
> extern void ath5k_hw_detach(struct ath5k_hw *ah);
>
> /* LED functions */
> diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
> index 109ab7b..0d789ef 100644
> --- a/drivers/net/wireless/ath/ath5k/attach.c
> +++ b/drivers/net/wireless/ath/ath5k/attach.c
> @@ -95,14 +95,13 @@ static int ath5k_hw_post(struct ath5k_hw *ah)
> * ath5k_hw_attach - Check if hw is supported and init the needed structs
> *
> * @sc: The &struct ath5k_softc we got from the driver's attach function
> - * @mac_version: The mac version id (check out ath5k.h) based on pci id
> *
> * Check if the device is supported, perform a POST and initialize the needed
> * structs. Returns -ENOMEM if we don't have memory for the needed structs,
> * -ENODEV if the device is not supported or prints an error msg if something
> * else went wrong.
> */
> -struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> +struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc)
> {
> struct ath5k_hw *ah;
> struct pci_dev *pdev = sc->pdev;
> @@ -136,9 +135,15 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> ah->ah_software_retry = false;
>
> /*
> - * Set the mac version based on the pci id
> + * Find the mac version
> */
> - ah->ah_version = mac_version;
> + srev = ath5k_hw_reg_read(ah, AR5K_SREV);
> + if (srev < AR5K_SREV_AR5311)
> + ah->ah_version = AR5K_AR5210;
> + else if (srev < AR5K_SREV_AR5212)
> + ah->ah_version = AR5K_AR5211;
> + else
> + ah->ah_version = AR5K_AR5212;
>
> /*Fill the ath5k_hw struct with the needed functions*/
> ret = ath5k_hw_init_desc_functions(ah);
> @@ -151,7 +156,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
> goto err_free;
>
> /* Get MAC, PHY and RADIO revisions */
> - srev = ath5k_hw_reg_read(ah, AR5K_SREV);
> ah->ah_mac_srev = srev;
> ah->ah_mac_version = AR5K_REG_MS(srev, AR5K_SREV_VER);
> ah->ah_mac_revision = AR5K_REG_MS(srev, AR5K_SREV_REV);
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index 94d46fd..9c6ab53 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -84,24 +84,24 @@ MODULE_VERSION("0.6.0 (EXPERIMENTAL)");
>
> /* Known PCI ids */
> static const struct pci_device_id ath5k_pci_id_table[] = {
> - { PCI_VDEVICE(ATHEROS, 0x0207), .driver_data = AR5K_AR5210 }, /* 5210 early */
> - { PCI_VDEVICE(ATHEROS, 0x0007), .driver_data = AR5K_AR5210 }, /* 5210 */
> - { PCI_VDEVICE(ATHEROS, 0x0011), .driver_data = AR5K_AR5211 }, /* 5311 - this is on AHB bus !*/
> - { PCI_VDEVICE(ATHEROS, 0x0012), .driver_data = AR5K_AR5211 }, /* 5211 */
> - { PCI_VDEVICE(ATHEROS, 0x0013), .driver_data = AR5K_AR5212 }, /* 5212 */
> - { PCI_VDEVICE(3COM_2, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 5212 */
> - { PCI_VDEVICE(3COM, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 3CRDAG675 5212 */
> - { PCI_VDEVICE(ATHEROS, 0x1014), .driver_data = AR5K_AR5212 }, /* IBM minipci 5212 */
> - { PCI_VDEVICE(ATHEROS, 0x0014), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0015), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0016), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0017), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0018), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x0019), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
> - { PCI_VDEVICE(ATHEROS, 0x001a), .driver_data = AR5K_AR5212 }, /* 2413 Griffin-lite */
> - { PCI_VDEVICE(ATHEROS, 0x001b), .driver_data = AR5K_AR5212 }, /* 5413 Eagle */
> - { PCI_VDEVICE(ATHEROS, 0x001c), .driver_data = AR5K_AR5212 }, /* PCI-E cards */
> - { PCI_VDEVICE(ATHEROS, 0x001d), .driver_data = AR5K_AR5212 }, /* 2417 Nala */
> + { PCI_VDEVICE(ATHEROS, 0x0207) }, /* 5210 early */
> + { PCI_VDEVICE(ATHEROS, 0x0007) }, /* 5210 */
> + { PCI_VDEVICE(ATHEROS, 0x0011) }, /* 5311 - this is on AHB bus !*/
> + { PCI_VDEVICE(ATHEROS, 0x0012) }, /* 5211 */
> + { PCI_VDEVICE(ATHEROS, 0x0013) }, /* 5212 */
> + { PCI_VDEVICE(3COM_2, 0x0013) }, /* 3com 5212 */
> + { PCI_VDEVICE(3COM, 0x0013) }, /* 3com 3CRDAG675 5212 */
> + { PCI_VDEVICE(ATHEROS, 0x1014) }, /* IBM minipci 5212 */
> + { PCI_VDEVICE(ATHEROS, 0x0014) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0015) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0016) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0017) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0018) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x0019) }, /* 5212 combatible */
> + { PCI_VDEVICE(ATHEROS, 0x001a) }, /* 2413 Griffin-lite */
> + { PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
> + { PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
> + { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
> { 0 }
> };
> MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
> @@ -566,7 +566,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
> }
>
> /* Initialize device */
> - sc->ah = ath5k_hw_attach(sc, id->driver_data);
> + sc->ah = ath5k_hw_attach(sc);
> if (IS_ERR(sc->ah)) {
> ret = PTR_ERR(sc->ah);
> goto err_irq;
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-27 12:58 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
2009/8/27 Pavel Roskin <proski@gnu.org>:
> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
> it:
>
> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
> eeprom.c:441: warning: 'val' may be used uninitialized in this function
>
> Comparing the code to the Atheros HAL, it's clear that the split between
> ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was
> incorrect.
>
> The Atheros HAL reads both turbo and non-turbo data from EEPROM in one
> function. Some turbo mode parameters are derived from the same EEPROM
> values as non-turbo parameters, just from different bits.
>
> Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to
> fix the warning. The actual values and offsets have been cross-checked
> against Atheros HAL.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Current code works fine (i 've checked it against various cards),
there is nothing wrong
with having another function for reading turbo modes, i find it's
cleaner that way.
Just change
u16 val;
to
u16 val = 0;
and it should be fine.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH] b43: Remove scary message from LP-PHY's Kconfig
From: Kalle Valo @ 2009-08-27 12:22 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Larry Finger, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <1251316132-392-1-git-send-email-netrolller.3d@gmail.com>
Gábor Stefanik <netrolller.3d@gmail.com> writes:
> From: root Gábor Stefanik <netrolller.3d@gmail.com>
You have extra "root" word here. You really like sudo ;)
--
Kalle Valo
^ permalink raw reply
* Nokia N900 running mac80211
From: Kalle Valo @ 2009-08-27 11:55 UTC (permalink / raw)
To: linux-wireless
Hello,
wanted to tell you that just released Nokia N900 is using mac80211 and
wl1251 driver. The kernel is 2.6.28 with few wireless related patches
backported from newer releases and some hacks related to roaming.
http://www.nokia.com/press/press-releases/showpressrelease?newsid=1337594
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-27 10:43 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090827073854.27662.68095.stgit@fate.lan>
Please, don't merge this after all. Blocks scan too long and breaks
NetworkManager/wpa_supplicant.
Quoting "Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>:
> Increase scan delay from 1 sec to 6 sec. Spec says that scan by
> OID_802_11_BSSID_LIST_SCAN completes in 6 seconds.
> Before rfkill patch too short delay was not problem as device was
> always active (radio on) and performing background scanning.
>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-27 10:40 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <f42a38140908270233r3c1aef6ne900fd3426465158@mail.gmail.com>
On Thursday 27 August 2009 11:33:12 feng tian wrote:
> Hi Michael,
> We found that broadcom drops some BCM codes which support SDIO
> interface on following url:
> "http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=summary"
> Just FYI.
> Hope this can help.
No, it's fullmac.
--
Greetings, Michael.
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Mel Gorman @ 2009-08-27 9:45 UTC (permalink / raw)
To: Zhu Yi
Cc: Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <1251364289.3704.176.camel@debian>
On Thu, Aug 27, 2009 at 05:11:29PM +0800, Zhu Yi wrote:
> On Wed, 2009-08-26 at 22:44 +0800, Andrew Morton wrote:
> >
> > It is perhaps pretty simple to make the second (GFP_ATOMIC) allocation
> > go away. The code is already conveniently structured to do this:
> >
> > do {
> > chunk = (struct fw_chunk *)(data + offset);
> > offset += sizeof(struct fw_chunk);
> > /* build DMA packet and queue up for sending */
> > /* dma to chunk->address, the chunk->length bytes from
> > data +
> > * offeset*/
> > /* Dma loading */
> > rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
> >
> > le32_to_cpu(chunk->address),
> >
> > le32_to_cpu(chunk->length));
> > if (rc) {
> > IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
> > goto out;
> > }
> >
> > offset += le32_to_cpu(chunk->length);
> > } while (offset < len);
> >
> > what is the typical/expected value of chunk->length here? If it's
> > significantly less than 4096*(2^6), could we convert this function to
> > use a separate DMAable allocation per fw_chunk?
>
> Unfortunately, the largest chunk size for the latest 3.1 firmware is
> 0x20040, which also requires order 6 page allocation. I'll try to use
> the firmware DMA command block (64 slots) to handle the image (each for
> 4k, totally 256k).
>
That would be preferable as trying to make alloc-6 atomic allocations isn't
going to pan out. As I noted, doing it as GFP_KERNEL is possible but it'll
manifest as weird stalls periodically when the driver is loaded due to
reclaim and if the system is swapless, it might not work at all if memory
is mostly anonymous.
If the DMA command block doesn't work out, what is the feasibility of holding
onto the order-6 allocation once the module is loaded instead of allocing
for the duration of the firmware loading and then freeing it again?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-27 9:43 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <1251357267.20531.4.camel@johannes.local>
On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>
>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>
> Yes, but I never understood why that matters. If you've got
> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
> anyway. And their symbols would probably clash anyway if the original is
> built in, in which case you can't use compat.
>
> You haven't renamed cfg80211's sysfs either, so why rfkill?
>
> johannes
>
There are a couple of wimax drivers which depends on rfkill... or
bluetooth drivers? I think one likely reason is that there are valid
situations or hardware combinations which requires having both of them
loaded. (but that's a whole can of worms )
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-27 9:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <200908251253.48176.mb@bu3sch.de>
Hi Michael,
We found that broadcom drops some BCM codes which support SDIO
interface on following url:
"http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=summary"
Just FYI.
Hope this can help.
BR, Feng.
2009/8/25 Michael Buesch <mb@bu3sch.de>:
> On Tuesday 25 August 2009 09:16:36 feng tian wrote:
>> Dear Michael,
>>
>> Another question:
>> We can't get the actual "datasheet" of BCM 4325. The pdf from broadcom
>> is so rough, and we also sent email to ask more detailed spec, but no
>> feedback.
>> What kind of datasheet of BCM4325 are you using now?
>> Could you please share this with us?
>>
>> Thank you very much.
>>
>> BR, Feng
>>
>>
>
> http://bcm-v4.sipsolutions.net/
>
> --
> Greetings, Michael.
>
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Zhu Yi @ 2009-08-27 9:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090826074409.606b5124.akpm@linux-foundation.org>
On Wed, 2009-08-26 at 22:44 +0800, Andrew Morton wrote:
>
> It is perhaps pretty simple to make the second (GFP_ATOMIC) allocation
> go away. The code is already conveniently structured to do this:
>
> do {
> chunk = (struct fw_chunk *)(data + offset);
> offset += sizeof(struct fw_chunk);
> /* build DMA packet and queue up for sending */
> /* dma to chunk->address, the chunk->length bytes from
> data +
> * offeset*/
> /* Dma loading */
> rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
>
> le32_to_cpu(chunk->address),
>
> le32_to_cpu(chunk->length));
> if (rc) {
> IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
> goto out;
> }
>
> offset += le32_to_cpu(chunk->length);
> } while (offset < len);
>
> what is the typical/expected value of chunk->length here? If it's
> significantly less than 4096*(2^6), could we convert this function to
> use a separate DMAable allocation per fw_chunk?
Unfortunately, the largest chunk size for the latest 3.1 firmware is
0x20040, which also requires order 6 page allocation. I'll try to use
the firmware DMA command block (64 slots) to handle the image (each for
4k, totally 256k).
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] rt2x00: Cleanup rt2x00mac_bss_info_changed()
From: Johannes Berg @ 2009-08-27 7:40 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: John Linville, linux-wireless
In-Reply-To: <200908262104.09230.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Wed, 2009-08-26 at 21:04 +0200, Ivo van Doorn wrote:
> Since patch "rt2x00: bss_info_changed() callback is allowed to sleep" the
> variable delayed wasn't used anymore. This means it can be removed
> along with the call to schedule_work which depended on that variable.
I just wanted to say thanks for doing all the cleanups. It's really nice
to see all my work on making callbacks non-atomic pay off in that way :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-27 7:38 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Increase scan delay from 1 sec to 6 sec. Spec says that scan by
OID_802_11_BSSID_LIST_SCAN completes in 6 seconds.
Before rfkill patch too short delay was not problem as device was
always active (radio on) and performing background scanning.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index f181b00..6d49e80 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1599,7 +1599,7 @@ static int rndis_get_tx_power(struct wiphy *wiphy, int *dbm)
}
-#define SCAN_DELAY_JIFFIES (HZ)
+#define SCAN_DELAY_JIFFIES (HZ * 6)
static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_scan_request *request)
{
^ permalink raw reply related
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Johannes Berg @ 2009-08-27 7:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Hin-Tak Leung, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261645n24a040cds84f012095a40c15b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
Yes, but I never understood why that matters. If you've got
compat-wireless "rfkill" loaded then the original rfkill can't be loaded
anyway. And their symbols would probably clash anyway if the original is
built in, in which case you can't use compat.
You haven't renamed cfg80211's sysfs either, so why rfkill?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rndis_wlan: set cipher suites for cfg80211
From: Holger Schurig @ 2009-08-27 6:52 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20090826211551.14002pzogxthwfk0@hayate.sektori.org>
On Wednesday 26 August 2009 20:15:51 Jussi Kivilinna wrote:
> Reason is that rndis_wlan should really check device
> capabilities and set cipher suites
> depending by theim
Ahh. I was under the impression that chips since two or three
year always support WEP, WPA and WPA2. And that only the orinoco
driver (or drivers for similar old chips) need to check the
firmware/chip to see what is available.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Bob Copeland @ 2009-08-27 3:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023009.21926.49329.stgit@mj.roinet.com>
On Wed, Aug 26, 2009 at 10:30 PM, Pavel Roskin<proski@gnu.org> wrote:
> AR5K_SREV is available even if the chip has been put to sleep. Relying
> on the chip register allows binding non-standard PCI IDs by
>
> echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
>
> without having to specify the driver data as well.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Looks good, thanks!
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Bob Copeland @ 2009-08-27 3:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
On Wed, Aug 26, 2009 at 10:30 PM, Pavel Roskin<proski@gnu.org> wrote:
> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
> it:
>
> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
> eeprom.c:441: warning: 'val' may be used uninitialized in this function
Thanks!
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
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