* Re: Where to obtain the carl open source firmware?
From: Justin Piszcz @ 2011-09-28 15:39 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Christian Lamparter, sedat.dilek, linux-wireless
In-Reply-To: <20110928113630.35378eb9@mj>
On Wed, 28 Sep 2011, Pavel Roskin wrote:
> On Wed, 28 Sep 2011 13:59:26 +0200
> Christian Lamparter <chunkeey@googlemail.com> wrote:
>
>> As Sedat has already pointed out the 1.9.4 firmware binary is hosted
>> on the wiki-site [Thankfully, Pavel Roskin uploaded it there a while
>> ago. Who would have tought that it was a good idea... now we know it
>> sort of is.]
>
> I have put 1.9.2 on http://linuxwireless.org/en/users/Drivers/carl9170
> as well. It's still recommended for all released kernels. As I
> understand, Linux 3.1 will need 1.9.4 (according to
> CARL9170FW_VERSION_GIT in 3.1-rc8), so I'm going to add that to the
> Wiki.
Hi Pavel,
Thanks! I'll give 1.9.4 a spin with 3.1-rc8.
Justin.
^ permalink raw reply
* Regulatory revamp status
From: Zefir Kurtisi @ 2011-09-28 15:45 UTC (permalink / raw)
To: Rodriguez, Luis; +Cc: linux-wireless, Presman, Boris, Azulay, Assaf
In-Reply-To: <CAB=NE6UcT8gzVWW+stLEy2SKBCdt-wVnv6aWOZBKTurXk1W0YA@mail.gmail.com>
Hello Luis,
I am referring to your announcement for a regulatory revamp at the LinuxWireless summit in Vancouver and the patches to add DFS information to CRDA you proposed quite some time ago in [1].
For the integration of DFS that is currently being worked out by TI, we will need to have the DFS regulatory domain for the selected countrycode available -- that basically was implemented with the named patch set.
Could you please give some info on the status of the regulatory revamp and particularly if the proposed DFS information will be part of it? One detail that came up in the discussion to your patches was whether DFS regulatory domains are constant for a countrycode or might differ between bands. Has this been clarified meanwhile?
Thanks
Zefir
[1] http://marc.info/?l=linux-wireless&m=129286456607063&w=2, referenced at http://linuxwireless.org/en/developers/DFS#Map_countries_to_a_DFS_region_bit
^ permalink raw reply
* [PATCH] ath9k_hw: extend GPIO pin select mask for rfkill
From: Mohammed Shafi Shajakhan @ 2011-09-28 13:19 UTC (permalink / raw)
To: John W. Linville
Cc: Jouni Malinen, linux-wireless, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel,
Mohammed Shafi Shajakhan, Wilson Tsao, Hu, Russell
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
this extends the bits for rf kill GPIO selection to [7:2] from [4:2] as
we use GPIO pin 11 as rfkill for AR9480 and also remove few unused macros
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: "Hu, Russell" <rhu@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index a3c7d0c..9bde45c 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -104,16 +104,11 @@
#define OLC_FOR_AR9287_10_LATER (AR_SREV_9287_11_OR_LATER(ah) && \
ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
-#define AR_EEPROM_RFSILENT_GPIO_SEL 0x001c
-#define AR_EEPROM_RFSILENT_GPIO_SEL_S 2
-#define AR_EEPROM_RFSILENT_POLARITY 0x0002
-#define AR_EEPROM_RFSILENT_POLARITY_S 1
-
#define EEP_RFSILENT_ENABLED 0x0001
#define EEP_RFSILENT_ENABLED_S 0
#define EEP_RFSILENT_POLARITY 0x0002
#define EEP_RFSILENT_POLARITY_S 1
-#define EEP_RFSILENT_GPIO_SEL 0x001c
+#define EEP_RFSILENT_GPIO_SEL 0x00fc
#define EEP_RFSILENT_GPIO_SEL_S 2
#define AR5416_OPFLAGS_11A 0x01
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] ath9k_hw: extend GPIO pin select mask for rfkill
From: mohammed @ 2011-09-28 14:44 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: John W. Linville, Jouni Malinen, linux-wireless, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel, Wilson Tsao,
Hu, Russell
In-Reply-To: <1317215987-5952-1-git-send-email-mohammed@qca.qualcomm.com>
John, please drop this patch will resend a proper v2 patch, as its
better to have a unique GPIO rfkill selection mask for AR5416 family of
chip sets and AR93XX.
On Wednesday 28 September 2011 06:49 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan<mohammed@qca.qualcomm.com>
>
> this extends the bits for rf kill GPIO selection to [7:2] from [4:2] as
> we use GPIO pin 11 as rfkill for AR9480 and also remove few unused macros
>
> Cc: Wilson Tsao<wtsao@qca.qualcomm.com>
> Cc: "Hu, Russell"<rhu@qca.qualcomm.com>
> Signed-off-by: Mohammed Shafi Shajakhan<mohammed@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath9k/eeprom.h | 7 +------
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
> index a3c7d0c..9bde45c 100644
> --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> @@ -104,16 +104,11 @@
> #define OLC_FOR_AR9287_10_LATER (AR_SREV_9287_11_OR_LATER(ah)&& \
> ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
>
> -#define AR_EEPROM_RFSILENT_GPIO_SEL 0x001c
> -#define AR_EEPROM_RFSILENT_GPIO_SEL_S 2
> -#define AR_EEPROM_RFSILENT_POLARITY 0x0002
> -#define AR_EEPROM_RFSILENT_POLARITY_S 1
> -
> #define EEP_RFSILENT_ENABLED 0x0001
> #define EEP_RFSILENT_ENABLED_S 0
> #define EEP_RFSILENT_POLARITY 0x0002
> #define EEP_RFSILENT_POLARITY_S 1
> -#define EEP_RFSILENT_GPIO_SEL 0x001c
> +#define EEP_RFSILENT_GPIO_SEL 0x00fc
> #define EEP_RFSILENT_GPIO_SEL_S 2
>
> #define AR5416_OPFLAGS_11A 0x01
^ permalink raw reply
* Re: [PATCH] ath6kl: silence "invalid rate" warning
From: Kalle Valo @ 2011-09-28 16:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20110927203328.20742.30194.stgit@localhost6.localdomain6>
On 09/27/2011 11:33 PM, Kalle Valo wrote:
> For some reason firmware is sending invalid rates when we try to
> query current bitrate from ath6kl_get_station() and a warning is issued:
>
> [ 3810.415720] ath6kl: invalid rate: 1935633515
> [ 3811.105493] ath6kl: invalid rate: 1935633515
> [ 3811.556063] ath6kl: invalid rate: 1935633515
>
> As the warning happens way too often, convert the warning to a debug
> message once we have a proper fix. But to make it easy to follow
> how often the problem appears, add a debugfs to print
> various statistics about workarounds and make this issue the first WAR.
Applied.
Kalle
^ permalink raw reply
* Re: [PATCH 1/4] ath6kl: add prefix parameter to ath6kl_dbg_dump()
From: Kalle Valo @ 2011-09-28 16:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20110927113045.11592.15974.stgit@localhost6.localdomain6>
On 09/27/2011 02:30 PM, Kalle Valo wrote:
> Makes it easier to recognise longs dumps.
>
> Obligatory screenshot using "rx" prefix:
>
> ath6kl: ath6kl_rx
> rx 00000000: 10 10 00 00 00 00 08 30 00 00 00 00 00 00 f9 0b .......0........
> rx 00000010: 2c 44 08 30 00 00 f9 0b 0c a4 02 00 00 00 73 d2 ,D.0..........s.
> rx 00000020: 94 00 f9 0b 04 8c 01 00 02 00 07 02 02 00 f9 0b ................
All four applied.
Kalle
^ permalink raw reply
* Re: linux-next: build failure after merge of the moduleh tree
From: Kalle Valo @ 2011-09-28 16:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Gortmaker, linux-next, linux-kernel,
Vasanthakumar Thiagarajan, Raja Mani, Vivek Natarajan,
Suraj Sumangala, Joe Perches, Jouni Malinen, John W. Linville,
David Miller, netdev, linux-wireless
In-Reply-To: <20110928183552.cb27a2b28b02fec275bca009@canb.auug.org.au>
On 09/28/2011 11:35 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the moduleh tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
>
> Caused by commit bdcd81707973 ("Add ath6kl cleaned up driver") from the
> net tree interacting with the module.h split up.
>
> I have applied the following patch for today (which sould be applied to
> the net or wireless trees).
>
> From 1875bfc8881cca3064c7d7fad024555fe1652926 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Sep 2011 18:32:34 +1000
> Subject: [PATCH] wireless/ath6kl: use of module_param requires the inclusion
> of moduleparam.h
>
> Otheriwse the module.h split up fails like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
Thanks, I applied this to ath6kl.git (had to fix just one conflict).
Later this week I will send a pull request to John so that the patch
should get to the wireless tree soon.
Unless John wants to take the patch directly, of course.
Kalle
^ permalink raw reply
* [PATCH] compat-wireless: make patches apply again.
From: Hauke Mehrtens @ 2011-09-28 18:42 UTC (permalink / raw)
To: mcgrof, mcgrof; +Cc: linux-wireless, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/08-rename-config-options.patch | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/patches/08-rename-config-options.patch b/patches/08-rename-config-options.patch
index 5505018..605e477 100644
--- a/patches/08-rename-config-options.patch
+++ b/patches/08-rename-config-options.patch
@@ -122,15 +122,15 @@ CONFIG_BT_HIDP does not build with older kernel versions.
hidp-objs := core.o sock.o
--- a/drivers/net/wireless/wl12xx/Makefile
+++ b/drivers/net/wireless/wl12xx/Makefile
-@@ -8,9 +8,9 @@ wl12xx_sdio_test-objs = sdio_test.o
+@@ -8,9 +8,9 @@ wl12xx_sdio_test-objs = sdio_test.o
wl12xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
obj-$(CONFIG_WL12XX) += wl12xx.o
obj-$(CONFIG_WL12XX_SPI) += wl12xx_spi.o
-obj-$(CONFIG_WL12XX_SDIO) += wl12xx_sdio.o
+obj-$(CONFIG_COMPAT_WL12XX_SDIO) += wl12xx_sdio.o
--obj-$(CONFIG_WL12XX_SDIO_TEST) += wl12xx_sdio_test.o
-+obj-$(CONFIG_COMPAT_WL12XX_SDIO_TEST) += wl12xx_sdio_test.o
+-obj-$(CONFIG_WL12XX_SDIO_TEST) += wl12xx_sdio_test.o
++obj-$(CONFIG_COMPAT_WL12XX_SDIO_TEST) += wl12xx_sdio_test.o
# small builtin driver bit
obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
--
1.7.4.1
^ permalink raw reply related
* [PATCH] compat: add IS_ERR_OR_NULL()
From: Hauke Mehrtens @ 2011-09-28 18:43 UTC (permalink / raw)
To: mcgrof, mcgrof; +Cc: linux-wireless, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.33.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.33.h b/include/linux/compat-2.6.33.h
index 43f1989..386ee4c 100644
--- a/include/linux/compat-2.6.33.h
+++ b/include/linux/compat-2.6.33.h
@@ -144,6 +144,11 @@ static inline bool pci_is_pcie(struct pci_dev *dev)
#define __always_unused /* unimplemented */
#endif
+static inline long __must_check IS_ERR_OR_NULL(const void *ptr)
+{
+ return !ptr || IS_ERR_VALUE((unsigned long)ptr);
+}
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)) */
#endif /* LINUX_26_33_COMPAT_H */
--
1.7.4.1
^ permalink raw reply related
* Compat-wireless release for 2011-09-28 is baked
From: Compat-wireless cronjob account @ 2011-09-28 19:05 UTC (permalink / raw)
To: linux-wireless
>From git://github.com/sfrothwell/linux-next
+ 6a98528...e714605 akpm-end -> origin/akpm-end (forced update)
858b181..a102a9e akpm-start -> origin/akpm-start
+ 62c9781...04c7323 master -> origin/master (forced update)
858b181..a102a9e stable -> origin/stable
* [new tag] next-20110928 -> next-20110928
* [new tag] v3.1-rc8 -> v3.1-rc8
compat-wireless code metrics
812937 - Total upstream lines of code being pulled
Host key verification failed.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
^ permalink raw reply
* Re: Regulatory revamp status
From: Luis R. Rodriguez @ 2011-09-28 19:52 UTC (permalink / raw)
To: Zefir Kurtisi, Green, Michael, David Quan, Kevin Hayes,
Venkataraman, Arun
Cc: linux-wireless, Presman, Boris, Azulay, Assaf
In-Reply-To: <4E834128.2030208@neratec.com>
On Wed, Sep 28, 2011 at 8:45 AM, Zefir Kurtisi
<zefir.kurtisi@neratec.com> wrote:
> Hello Luis,
>
> I am referring to your announcement for a regulatory revamp at the LinuxWireless
> summit in Vancouver and the patches to add DFS information to CRDA you
> proposed quite some time ago in [1].
>
> For the integration of DFS that is currently being worked out by TI, we will need to have
> the DFS regulatory domain for the selected countrycode available -- that basically was
> implemented with the named patch set.
Yup, there was one pending item on that and it was to determine
whether or not a country can have different DFS regions for different
frequency bands. If this is true this also implies that a country can
have multiple DFS regions. I have found one country in our internal
regulatory updates which maps Bulgaria to different DFS regions and
have asked our regulatory folks about this. This seems odd to me and
I'd prefer to stick to one DFS region entirely for one country, but if
in the future we forsee DFS regions to be band specific this may
complicate things and we should address this now. Can you tell me if
at TI you have no multiple DFS regions for one country ? Do you guys
have Bulgaria mapping to one DFS region?
> Could you please give some info on the status of the regulatory revamp and particularly if
> the proposed DFS information will be part of it?
You should consider DFS integration into wireless-regdb as independent
of the regulatory revamp given that we have 16 bits we can use to
extend wireless-regdb for any future capabilities without having to
restructure the format of the file to require a different version of
crda. So DFS can be added as-is today. Updates below on the regulatory
revamp though and DFS.
I'm chugging along the regulatory revamp slowly given the questions
that come up with it require consulting with several different people.
The latest piece I reviewed was TPC and for that it seems we already
take into account the 3 dB difference into account into
wireless-regdb, however this can be further optimized if TPC is
implemented -- but implementing TPC is device specific in that the TPC
reports and how you use them can vary depending on the device. When
you send TPC report requests will also vary. In short I've latest
determined to stick to what we have today and assume we'll always be
reducing the 3 dB in power built-in already into the wireless-regdb
power for each country where needed. This assumes no proper TPC
implementation. It would still be nice to know when a band requires
TPC though to enable vendors to implement TPC and reduce power not by
3 dB but by whatever metrics they come up with. Given that 3 dB seems
to be the only required change we likely could stick to that as the
assumed max value and just require a TPC flag, and if the band has
this flag allow the driver / stack / etc to add 3 dB more to power if
it implements TPC. The only problem with this is we'd assume alway a
static 3 dB. Another possibility is to use a u8 value here to
represent the deducted tx power, instead of a bit value for a flag.
Technically speaking we can support both DFS and TPC in the current
file format for wireless-regdb, we have 16 bits left, we could leave
u8 for DFS region as a bitmask (left to determine about the multiple
DFS regions) and u8 for the tx power adaptation for TPC. Thoughts?
> One detail that came up in the discussion to
> your patches was whether DFS regulatory domains are constant for a countrycode or might
> differ between bands. Has this been clarified meanwhile?
Not yet! I've asked for input a while ago and today as well. What do
you guys think?
Luis
^ permalink raw reply
* Re: [PATCHv3] wireless: at76c50x: use native hex_pack_byte() method
From: Pavel Roskin @ 2011-09-28 20:40 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-wireless, John W. Linville
In-Reply-To: <e05a153fe0dfcd8f29be52eb8b8ea14a00f020dd.1317202208.git.andriy.shevchenko@linux.intel.com>
On Wed, 28 Sep 2011 12:30:59 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
Tested-by: Pavel Roskin <proski@gnu.org>
> ---
> drivers/net/wireless/at76c50x-usb.c | 18 ++++++++----------
> 1 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/at76c50x-usb.c
> b/drivers/net/wireless/at76c50x-usb.c index 2986014..39322d4 100644
> --- a/drivers/net/wireless/at76c50x-usb.c
> +++ b/drivers/net/wireless/at76c50x-usb.c
> @@ -500,10 +500,9 @@ exit:
>
> #define HEX2STR_BUFFERS 4
> #define HEX2STR_MAX_LEN 64
> -#define BIN2HEX(x) ((x) < 10 ? '0' + (x) : (x) + 'A' - 10)
>
> /* Convert binary data into hex string */
> -static char *hex2str(void *buf, int len)
> +static char *hex2str(void *buf, size_t len)
> {
> static atomic_t a = ATOMIC_INIT(0);
> static char bufs[HEX2STR_BUFFERS][3 * HEX2STR_MAX_LEN + 1];
> @@ -514,18 +513,17 @@ static char *hex2str(void *buf, int len)
> if (len > HEX2STR_MAX_LEN)
> len = HEX2STR_MAX_LEN;
>
> - if (len <= 0) {
> - ret[0] = '\0';
> - return ret;
> - }
> + if (len == 0)
> + goto exit;
>
> while (len--) {
> - *obuf++ = BIN2HEX(*ibuf >> 4);
> - *obuf++ = BIN2HEX(*ibuf & 0xf);
> + obuf = pack_hex_byte(obuf, *ibuf++);
> *obuf++ = '-';
> - ibuf++;
> }
> - *(--obuf) = '\0';
> + obuf--;
> +
> +exit:
> + *obuf = '\0';
>
> return ret;
> }
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] compat: add IS_ERR_OR_NULL()
From: Luis R. Rodriguez @ 2011-09-28 20:41 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <1317235424-14378-1-git-send-email-hauke@hauke-m.de>
On Wed, Sep 28, 2011 at 11:43 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks, applied and pushed both patches out!
Luis
^ permalink raw reply
* Re: [PATCH] wireless: at76c50x: fix multithread access to hex2str
From: Pavel Roskin @ 2011-09-28 21:19 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-wireless, John W. Linville
In-Reply-To: <21514bff06a915d2edd0a83c74ac512eb8b80b3f.1317215809.git.andriy.shevchenko@linux.intel.com>
On Wed, 28 Sep 2011 16:17:31 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> The original hex2str uses finite array of buffers to keep output
> data. It's a wrong approach, because we can't say at compile time how
> many threads will be used.
>
> This patch introduces one buffer and global mutex to access this
> function. All calls of it are wrapped by locking this mutex. It saves
> some memory as a side effect.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: "John W. Linville" <linville@tuxdriver.com>
The reason for having 4 buffers is to allow using hex2str() more than
once in the same printk() statement. As you can see, hex2str() is
never used in one statement more than once. Your solution would make
it impossible to use hex2str() twice in the same printk(), as the
buffer would be reused. Actually, wrong data would be printed with no
warning! Such code doesn't exist in the driver, but it could be added
by somebody looking for a problem. And that would hamper debugging
instead of helping it.
I think we can live with a debug function printing wrong data if it's
called by 5 callers at once.
And if you want a perfectly correct fix, I suggest that you use
buffers allocated by the callers on the stack. That's less intrusive
than mutexes, and it would allow using more than one hex2str() in one
statement as long as the buffers are different.
Or maybe hex2str() should be replaced with calls to
print_hex_dump_bytes()? That would add extra lines to the kernel
output, but it's no big deal. Of course, if you are concerned about 5
callers printing bytes in the same time, the output may be hard to
understand, but I don't think it a problem that needs addressing.
Or maybe you could develop an extension for printk() format that would
dump strings of the given length? Something like %pM, but with an
extra argument (and make sure it would not trigger a gcc warning).
This way, everybody would benefit.
Please rethink whether it's helpful to send such "fixes" for old and
little maintained drivers. There are few people who can work on them,
and they have little time for the old drivers. Their time is better
spent fixing real problems than reviewing untested or badly conceived
patches for imaginary problems and style issues. Besides, there are few
users who could test the driver and report breakage.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFT][PATCH] ath5k: Add rfkill_disable module parameter
From: Pavel Roskin @ 2011-09-28 22:07 UTC (permalink / raw)
To: Nick Kossifidis
Cc: ath5k-devel, linux-wireless, linville, me, mcgrof, jirislaby, nbd
In-Reply-To: <20110919160124.GA3218@makis.lan>
On Mon, 19 Sep 2011 19:01:24 +0300
Nick Kossifidis <mickflemm@gmail.com> wrote:
> Add a module parameter to disable hw rf kill (GPIO interrupt) because
> in some cases when the card doesn't come with the laptop, EEPROM
> configuration doesn't match laptop's configuration and rf kill
> interrupt always fires up and disables hw. I thought of moving this
> to debugfs and make it per-card but this way it's easier for users
> and distros to handle.
>
> Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Pavel Roskin <proski@.gnu.org>
Tested on 2 cards in Mikrotik RB-14 adapter. One was OK without the
patch. The other was shown as hard-blocked by rfkill and didn't work.
With the rfkill_disable=1, both cards work. Soft rfkill is still
working properly.
Please consider a parameter name that indicates that only hard rfkill is
affected, for instance "no_hw_rfkill".
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Compat-wireless release for 2011-09-28 is baked
From: Luis R. Rodriguez @ 2011-09-28 22:24 UTC (permalink / raw)
To: Compat-wireless cronjob account; +Cc: linux-wireless
In-Reply-To: <20110928190532.9ACDF40652@repository3.orbit-lab.org>
On Wed, Sep 28, 2011 at 12:05 PM, Compat-wireless cronjob account
<compat@orbit-lab.org> wrote:
> Host key verification failed.
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
> rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
This should be fixed now. Sorry for the delay.
Luis
^ permalink raw reply
* [ANN] compat-wireless for 3.1-rc8 is out
From: Luis R. Rodriguez @ 2011-09-28 22:53 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-bluetooth, netdev, linux-wireless
The world hasn't ended yet, even without kernel.org, so we get a new
compat-wireless release based on Linus' rc8 release. Given that
kernel.org is down I just sucked in Linus' tree on github into my
linux-2.6-allstable and reset it to 3.1-rc8. Please test and rant
about issues found.
http://linuxwireless.org/en/users/Download/stable (as
wireless.kernel.org DNS is bust right now)
sha1sum: db33de991c9764185707591da881963e041de9c8
Size: 4.1 MiB
http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.1/compat-wireless-3.1-rc8-1.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.1/ChangeLog-3.1-wireless
Luis
^ permalink raw reply
* [PATCH] iwlagn: iwl-agn-rs: remove unnecessary null check for sta and lq_sta
From: Gregory.Dietsche @ 2011-09-28 22:54 UTC (permalink / raw)
To: wey-yi.w.guy
Cc: ilw, linville, linux-wireless, netdev, linux-kernel,
Greg Dietsche
From: Greg Dietsche <Gregory.Dietsche@cuw.edu>
both sta and lq_sta are guaranteed to be not null in the
calling function so we don't need to check them here.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 3789ff4..e5ea33b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2269,9 +2269,6 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
info->flags & IEEE80211_TX_CTL_NO_ACK)
return;
- if (!sta || !lq_sta)
- return;
-
lq_sta->supp_rates = sta->supp_rates[lq_sta->band];
tid = rs_tl_add_packet(lq_sta, hdr);
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH] iwlagn: iwl-agn-rs: remove unnecessary null check for sta and lq_sta
From: Guy, Wey-Yi @ 2011-09-28 22:18 UTC (permalink / raw)
To: Gregory.Dietsche@cuw.edu
Cc: ilw@linux.intel.com, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1317250444-2248-1-git-send-email-Gregory.Dietsche@cuw.edu>
On Wed, 2011-09-28 at 15:54 -0700, Gregory.Dietsche@cuw.edu wrote:
> From: Greg Dietsche <Gregory.Dietsche@cuw.edu>
>
> both sta and lq_sta are guaranteed to be not null in the
> calling function so we don't need to check them here.
>
> Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
you are correct
Wey
^ permalink raw reply
* Re: [RFC] ath9k_hw: set is_pciexpress true for AR9480
From: Felix Fietkau @ 2011-09-28 23:23 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: linux-wireless, John W. Linville, Jouni Malinen, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel
In-Reply-To: <1317211660-3975-1-git-send-email-mohammed@qca.qualcomm.com>
On 2011-09-28 2:07 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan<mohammed@qca.qualcomm.com>
>
> the AR_SREV register does not seems to indicate it properly though the
> other information like macVersion etc can be obtained properly
How about using AR_SREV_9300_20_OR_LATER(ah) instead to make sure that
this works properly for future chips as well?
- Felix
^ permalink raw reply
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem
From: Stefan Zwanenburg @ 2011-09-28 23:28 UTC (permalink / raw)
To: Larry Finger; +Cc: 'Chaoming_Li', linux-wireless
In-Reply-To: <4E82A8E9.60409@lwfinger.net>
On 09/28/2011 06:56 AM, Larry Finger wrote:
> The MAC address is read from EEROM in routines found in efuse.c, and
> should always be the same. If the value read is not a valid ethernet
> address, then a random one is set, which must be what is happening on
> your system. I'll get back to you on how to dump the entire efuse
> contents so that we can see what else might be wrong in its encoding.
> I will be out tomorrow, thus it will likely be Thursday before I can
> answer. Perhaps Chaoming will answer earlier.
I had some time on my hands, so I tried to figure out how to dump the
EEPROM data myself, and have done so using the following patch (based on
linux-3.0.4):
--- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-07-22
04:17:23.000000000 +0200
+++ /home/psychotic/Desktop/rtl8192se_hw.c 2011-09-29
01:16:09.361978051 +0200
@@ -1645,6 +1645,13 @@
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"),
hwinfo, HWSET_MAX_SIZE_92S);
+ printk("RTL8192SE - got EEPROM data:");
+ for (i = 0; i < HWSET_MAX_SIZE_92S; i++) {
+ if (i % 6 == 0)
+ printk("\n ");
+ printk("%02X ", hwinfo[i]);
+ }
+
eeprom_id = *((u16 *)&hwinfo[0]);
if (eeprom_id != RTL8190_EEPROM_ID) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
And here is the output I got right after inserting the rtl8192se module:
Sep 29 01:07:02 localhost kernel: [ 1160.153407] RTL8192SE - got EEPROM
data:
Sep 29 01:07:02 localhost kernel: [ 1160.153412] 29 81 00 00 A9 16
Sep 29 01:07:02 localhost kernel: [ 1160.153419] 00 00 00 00 EC 10
Sep 29 01:07:02 localhost kernel: [ 1160.153425] 72 81 EC 10 72 81
Sep 29 01:07:02 localhost kernel: [ 1160.153431] 1C 4B D6 69 6A DC
Sep 29 01:07:02 localhost kernel: [ 1160.153437] FF FF FF FF FF FF
Sep 29 01:07:02 localhost kernel: [ 1160.153443] FF FF 01 FF 13 AA
Sep 29 01:07:02 localhost kernel: [ 1160.153449] 03 02 20 80 02 B0
Sep 29 01:07:02 localhost kernel: [ 1160.153455] 06 91 A5 78 2A E4
Sep 29 01:07:02 localhost kernel: [ 1160.153461] 00 E0 4C FF FE 22
Sep 29 01:07:02 localhost kernel: [ 1160.153467] 55 88 C3 FF 84 75
Sep 29 01:07:02 localhost kernel: [ 1160.153473] 78 39 00 00 C1 8C
Sep 29 01:07:02 localhost kernel: [ 1160.153478] 80 11 40 00 11 3C
Sep 29 01:07:02 localhost kernel: [ 1160.153484] 03 00 10 20 00 00
Sep 29 01:07:02 localhost kernel: [ 1160.153490] 00 00 28 29 27 00
Sep 29 01:07:02 localhost kernel: [ 1160.153496] 00 00 28 28 28 00
Sep 29 01:07:02 localhost kernel: [ 1160.153502] 00 00 00 00 00 00
Sep 29 01:07:02 localhost kernel: [ 1160.153508] 00 00 00 00 00 04
Sep 29 01:07:02 localhost kernel: [ 1160.153514] 03 00 00 00 00 00
Sep 29 01:07:02 localhost kernel: [ 1160.153520] 00 01 00 00 00 00
Sep 29 01:07:02 localhost kernel: [ 1160.153526] 00 00 0E 00 04 11
Sep 29 01:07:02 localhost kernel: [ 1160.153531] 00 00 00 09 02 00
Sep 29 01:07:02 localhost kernel: [ 1160.153537] 02 00
I hope that saves you the time by not having to explain to me how to
dump the EEPROM data, and that you (any of you =)) can find something
useful in there.
What I have been able to tell from this is that the MAC address my
interface currently has is indeed the one saved in the EEPROM
(1C:4B:D6:69:6A:DC). Don't know why it would ever have another one...
Greetings,
Stefan Zwanenburg
^ permalink raw reply
* Re: 答复: 答复: 答复: 3.1-rc6+ rtl8192se issue
From: Larry Finger @ 2011-09-29 1:57 UTC (permalink / raw)
To: Borislav Petkov; +Cc: 李朝明, linux-wireless, 'LKML'
In-Reply-To: <20110928131823.GA2693@gere.osrc.amd.com>
On 09/28/2011 08:18 AM, Borislav Petkov wrote:
> On Fri, Sep 23, 2011 at 11:34:12AM -0500, Larry Finger wrote:
>> On 09/23/2011 05:33 AM, Borislav Petkov wrote:
>>> On Fri, Sep 23, 2011 at 06:21:07PM +0800, 李朝明 wrote:
>>>> Please set ips =0 and try again..
>>>
>>> What does that mean?
>>>
>>> I can trigger the grinding-to-a-halt reliably with "ips=0" - it only
>>> takes a couple of hours of network traffic. Also, I don't want to try
>>> the driver you sent me because the version in the kernel needs fixing
>>> not some out-of-tree codebase.
>>
>> I got a chance to review the rtl8192se part of the changes in that
>> 08/16/2011 version. Attached is a patch to update the kernel
>> version.
>>
>> A prerequisite is:
>>
>> commit da3ba88a9996cd64c6768bed5727e02da81e2c8d
>> Author: Larry Finger<Larry.Finger@lwfinger.net>
>> Date: Mon Sep 19 14:34:10 2011 -0500
>>
>> rtlwifi: Combine instances of RTL_HAL_IS_CCK_RATE macros.
>>
>> Three drivers, rtl8192ce, rtl8192cu and rtl8192de, use the same macro
>> to check if a particular rate is in the CCK set. This common code is
>> relocated to a common header file. A distinct macro used by rtl8192se
>> with the same name is renamed.
>>
>> Signed-off-by: Larry Finger<Larry.Finger@lwfinger.net>
>> Signed-off-by: John W. Linville<linville@tuxdriver.com>
>
> Ok, here's what I did.
>
> * merge 'master' branch of
> git://git.infradead.org/users/linville/wireless-next.git with -rc8 in
> order to get da3ba88a9996.
>
> * apply your attached patch with the Realsil facelift:
>
> patching file drivers/net/wireless/rtlwifi/rtl8192se/hw.c
> patching file drivers/net/wireless/rtlwifi/rtl8192se/reg.h
> patching file drivers/net/wireless/rtlwifi/rtl8192se/sw.c
> patching file drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> Hunk #6 FAILED at 540.
> 1 out of 6 hunks FAILED -- saving rejects to file drivers/net/wireless/rtlwifi/rtl8192se/trx.c.rej
> patching file drivers/net/wireless/rtlwifi/wifi.h
> Hunk #1 succeeded at 1328 (offset 3 lines).
>
> (had to apply hunk #6 by hand though)
>
> * build
>
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c:307:8: error: `EFUSE_OOB_PROTECT_BYTES_LEN' undeclared here (not in a function)
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c:307:2: error: array index in initializer not of integer type
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c:307:2: error: (near initialization for `rtl92se_hal_cfg.maps')
> make[5]: *** [drivers/net/wireless/rtlwifi/rtl8192se/sw.o] Error 1
> make[4]: *** [drivers/net/wireless/rtlwifi/rtl8192se] Error 2
> make[3]: *** [drivers/net/wireless/rtlwifi] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
> make: *** Waiting for unfinished jobs....
>
> fix with
>
> diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
> index 615f6b4..55428f2 100644
> --- a/drivers/net/wireless/rtlwifi/wifi.h
> +++ b/drivers/net/wireless/rtlwifi/wifi.h
> @@ -450,6 +450,7 @@ enum rtl_var_map {
> EFUSE_HWSET_MAX_SIZE,
> EFUSE_MAX_SECTION_MAP,
> EFUSE_REAL_CONTENT_SIZE,
> + EFUSE_OOB_PROTECT_BYTES_LEN,
>
> /*CAM map */
> RWCAM,
>
>> I have run the new version for a couple of hours without problems.
>> Perhaps it will cure your difficulty, but I am not optimistic.
>
> Yeah, I'm sorry to confirm that your pessimism turned into realism :-).
> It froze in under 20 mins. Ran the driver with default module parameters
> though.
>
> Looks like I'll have to test the Realsil tarball after all. Question, do
> I simply overwrite the subtree under drivers/net/wireless/rtlwifi/ with
> the files from the tarball?
Asa you probably do not want to kill your standard tree, unpack the Realtek
version normally, cd to where it unpacked, and do a make. Once it builds, do the
following:
sudo modprobe -rv rtl8192se
sudo modprobe -v mac80211
sudo insmod rtlwifi.ko
sudo insmod rtl8192se/rtl8192se.ko
>
> Also, any preferred module parameters settings you want me to test?
Try it first with the default parameters. If that fails, use "ips=0".
Larry
^ permalink raw reply
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem
From: Stefan Zwanenburg @ 2011-09-29 2:32 UTC (permalink / raw)
To: Larry Finger; +Cc: 'Chaoming_Li', linux-wireless
In-Reply-To: <4E83AD85.8050005@gmail.com>
On 09/29/2011 01:28 AM, Stefan Zwanenburg wrote:
> I had some time on my hands, so I tried to figure out how to dump the
> EEPROM data myself, and have done so using the following patch (based on
> linux-3.0.4):
>
> --- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-07-22
> 04:17:23.000000000 +0200
> +++ /home/psychotic/Desktop/rtl8192se_hw.c 2011-09-29
> 01:16:09.361978051 +0200
> @@ -1645,6 +1645,13 @@
> RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"),
> hwinfo, HWSET_MAX_SIZE_92S);
>
> + printk("RTL8192SE - got EEPROM data:");
> + for (i = 0; i < HWSET_MAX_SIZE_92S; i++) {
> + if (i % 6 == 0)
> + printk("\n ");
> + printk("%02X ", hwinfo[i]);
> + }
> +
> eeprom_id = *((u16 *)&hwinfo[0]);
> if (eeprom_id != RTL8190_EEPROM_ID) {
> RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
For posterity's sake, there was a slightly smaller workaround here, and
it would be as in the following patch:
--- drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-09-29
04:20:14.660831861 +0200
+++ drivers/net/wireless/rtlwifi/rtl8192se/hw.c 2011-09-29
04:20:05.303831474 +0200
@@ -1642,7 +1642,7 @@
HWSET_MAX_SIZE_92S);
}
- RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, ("MAP\n"),
+ RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_EMERG, ("MAP\n"),
hwinfo, HWSET_MAX_SIZE_92S);
eeprom_id = *((u16 *)&hwinfo[0]);
It's rather nasty though, as it pretends that dumping the EEPROM data is
happening right before a fatal error has occurred. But there's really no
other way, as using sysfs to set the "global_debuglevel" is not good
enough because the EEPROM data is read right after the module is loaded
(making it hard to set the debuglevel in time).
If this info is useless to you, disregard it!
Stefan Zwanenburg
PS: the EEPROM data I mentioned in my previous message is still the same
though, so I won't bother to repost it.
^ permalink raw reply
* Re: 答复: 答复: 答复: RTL8192SE and 802.11n problem
From: Larry Finger @ 2011-09-29 3:28 UTC (permalink / raw)
To: Stefan Zwanenburg; +Cc: 'Chaoming_Li', linux-wireless
In-Reply-To: <4E83AD85.8050005@gmail.com>
Stefan,
I dumped my EEPROM data and compared it with yours. The diffs are as follows:
--- mine 2011-09-28 21:58:26.000000000 -0500
+++ yours 2011-09-28 21:58:27.000000000 -0500
@@ -1,9 +1,9 @@
29 81 00 00 A9 16 00 00 00 00 EC 10 72 81 EC 10 72 81
-00 E0 4C 72 02 18 FF FF FF FF FF FF FF FF 01 FF 13 AA
+1C 4B D6 69 6A DC FF FF FF FF FF FF FF FF 01 FF 13 AA
03 02 20 80 02 B0 06 91 A5 78 2A E4 00 E0 4C FF FE 22
55 88 C3 FF 84 75 78 39 00 00 C1 8C 80 11 40 00 11 3C
-03 00 10 20 00 00 00 00 2C 29 2B 00 00 00 2D 2B 2C 00
-00 00 00 00 00 00 00 00 01 01 01 03 03 00 00 00 00 00
-00 00 00 00 00 00 00 00 0A 0A 03 11 00 00 00 0A 03 00
-02 00
+03 00 10 20 00 00 00 00 28 29 27 00 00 00 28 28 28 00
+00 00 00 00 00 00 00 00 00 00 00 04 03 00 00 00 00 00
+00 01 00 00 00 00 00 00 0E 00 04 11 00 00 00 09 02 00
+02 00
The data in the first 6 bytes at the beginning of line 2 is the MAC address. It
is clearly encoded there and I do not understand how it can be misread.
Chaoming - Any ideas to test?
I think that the other differences are likely to be calibration difference
between our two devices.
BTW, --- MAP_from_mine 2011-09-28 21:58:26.000000000 -0500
+++ MAP_from_problem 2011-09-28 21:58:27.000000000 -0500
@@ -1,9 +1,9 @@
29 81 00 00 A9 16 00 00 00 00 EC 10 72 81 EC 10 72 81
-00 E0 4C 72 02 18 FF FF FF FF FF FF FF FF 01 FF 13 AA
+1C 4B D6 69 6A DC FF FF FF FF FF FF FF FF 01 FF 13 AA
03 02 20 80 02 B0 06 91 A5 78 2A E4 00 E0 4C FF FE 22
55 88 C3 FF 84 75 78 39 00 00 C1 8C 80 11 40 00 11 3C
-03 00 10 20 00 00 00 00 2C 29 2B 00 00 00 2D 2B 2C 00
-00 00 00 00 00 00 00 00 01 01 01 03 03 00 00 00 00 00
-00 00 00 00 00 00 00 00 0A 0A 03 11 00 00 00 0A 03 00
+03 00 10 20 00 00 00 00 28 29 27 00 00 00 28 28 28 00
+00 00 00 00 00 00 00 00 00 00 00 04 03 00 00 00 00 00
+00 01 00 00 00 00 00 00 0E 00 04 11 00 00 00 09 02 00
02 00
BTW, the dump sent me has 1C:4B:D6:69:6A:DC as the MAC address. Obviously, the
hardware had the correct MAC address.
Wireshark does interpret that as Azurewav_69:6A:DC. The prefix 1C:4B:D6
apparently belongs to them. My device is translated as RealtekS_72:02:18, as
00:E0:4C means Realtek.
Larry
^ permalink raw reply
* Re: [RFC] ath9k_hw: set is_pciexpress true for AR9480
From: mohammed @ 2011-09-29 5:17 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, John W. Linville, Jouni Malinen, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel
In-Reply-To: <4E83AC73.3090502@openwrt.org>
Hi Felix,
On Thursday 29 September 2011 04:53 AM, Felix Fietkau wrote:
> On 2011-09-28 2:07 PM, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan<mohammed@qca.qualcomm.com>
>>
>> the AR_SREV register does not seems to indicate it properly though the
>> other information like macVersion etc can be obtained properly
> How about using AR_SREV_9300_20_OR_LATER(ah) instead to make sure that
> this works properly for future chips as well?
this seems to be a problem specifically for AR9480 and this problem does
not seems to be observed in AR9485. but its needed as if is_pciexpress
is false ASPM won't be initialized
>
> - Felix
^ 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