* ubuntu 9.04 WLAN no
From: Arne Bahr @ 2010-07-14 15:31 UTC (permalink / raw)
To: linux-wireless
Hi,
I have a problem with my Laptop Samsung x10:
WLAN card: IEEE 802.11b
my Laptop allways says: no IP-Adress obtained
I´m pretty new with Linux and need help. All drivers are known.
Arne
--
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Guy, Wey-Yi @ 2010-07-14 15:28 UTC (permalink / raw)
To: Florian Klink; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <e5d3a4df03d6582ddc18af249ed3a2f2@imap.flokli.de>
Hi Florian,
On Wed, 2010-07-14 at 03:06 -0700, Florian Klink wrote:
> Thanks ;-)
>
> On Wed, 14 Jul 2010 12:00:55 +0200, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > [correct wey-yi's address, remove reinette]
> >
> > On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
> >> Hi,
> >>
> >> I hope I'm writing to the right addresses, this is my first kernel bug
> >> report :-)
> >>
> >> I regulary build linus' tree from git. One day, my wireless card was
> >> unable to connect to the access point. dmesg showed something like this:
> >>
> >> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
> >> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
> >> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
> >> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
> >>
> >> At first, I thought is was some link quality problem and tried it next
> >> to the access point, but it still didn't work.
> >> I booted another (older) kernel and with this one, the card was able to
> >> connect without any problems.
> >>
> >> I bisected the problem and came to commit
> >> 062bee448bd539580ef9f64efe50fdfe04eeb103
> >> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
> >>
> >> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
> >>
> >> Will provide more info if needed.
> >>
Could you please load the iwlagn module with module parameter
debug=0x43fff and forward us the dmesg log
Thanks
Wey
>
^ permalink raw reply
* Re: [PATCH] iwlwifi: convert new uses of __attribute__ ((packed)) to __packed
From: Guy, Wey-Yi @ 2010-07-14 15:25 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1279118252-10258-1-git-send-email-linville@tuxdriver.com>
Hi John,
On Wed, 2010-07-14 at 07:37 -0700, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-commands.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
> index 8d2db9d..f1c0e68 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-commands.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
> @@ -1245,7 +1245,7 @@ struct iwl_txfifo_flush_cmd {
> __le32 fifo_control;
> __le16 flush_control;
> __le16 reserved;
> -} __attribute__ ((packed));
> +} __packed;
>
> /*
> * REPLY_WEP_KEY = 0x20
> @@ -3547,7 +3547,7 @@ struct iwl_sensitivity_cmd {
> struct iwl_enhance_sensitivity_cmd {
> __le16 control; /* always use "1" */
> __le16 enhance_table[ENHANCE_HD_TABLE_SIZE]; /* use HD_* as index */
> -} __attribute__ ((packed));
> +} __packed;
>
>
> /**
Thanks
Wey
^ permalink raw reply
* [PATCH] libertas: convert new uses of __attribute__ ((packed)) to __packed
From: John W. Linville @ 2010-07-14 14:37 UTC (permalink / raw)
To: linux-wireless
Cc: Dan Williams, Holger Schurig, Amitkumar Karwar, libertas-dev,
John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas/cfg.c | 6 +++---
drivers/net/wireless/libertas/host.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index f36cc97..7e07416 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -891,7 +891,7 @@ struct cmd_key_material {
__le16 action;
struct MrvlIEtype_keyParamSet param;
-} __attribute__ ((packed));
+} __packed;
static int lbs_set_key_material(struct lbs_private *priv,
int key_type,
@@ -1395,7 +1395,7 @@ struct cmd_monitor_mode {
__le16 action;
__le16 mode;
-} __attribute__ ((packed));
+} __packed;
static int lbs_enable_monitor_mode(struct lbs_private *priv, int mode)
{
@@ -1450,7 +1450,7 @@ struct cmd_rssi {
__le16 nf;
__le16 avg_snr;
__le16 avg_nf;
-} __attribute__ ((packed));
+} __packed;
static int lbs_get_signal(struct lbs_private *priv, s8 *signal, s8 *noise)
{
diff --git a/drivers/net/wireless/libertas/host.h b/drivers/net/wireless/libertas/host.h
index db8e209..43d020c 100644
--- a/drivers/net/wireless/libertas/host.h
+++ b/drivers/net/wireless/libertas/host.h
@@ -398,12 +398,12 @@ struct mrvl_ie_domain_param_set {
u8 countrycode[COUNTRY_CODE_LEN];
struct ieee80211_country_ie_triplet triplet[1];
-} __attribute__ ((packed));
+} __packed;
struct cmd_ds_802_11d_domain_info {
__le16 action;
struct mrvl_ie_domain_param_set domain;
-} __attribute__ ((packed));
+} __packed;
struct lbs_802_11d_domain_reg {
/** Country code*/
@@ -411,7 +411,7 @@ struct lbs_802_11d_domain_reg {
/** No. of triplet*/
u8 no_triplet;
struct ieee80211_country_ie_triplet triplet[MRVDRV_MAX_TRIPLET_802_11D];
-} __attribute__ ((packed));
+} __packed;
/*
* Define data structure for CMD_GET_HW_SPEC
--
1.7.1.1
^ permalink raw reply related
* [PATCH] iwlwifi: convert new uses of __attribute__ ((packed)) to __packed
From: John W. Linville @ 2010-07-14 14:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Wey-Yi Guy, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-commands.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index 8d2db9d..f1c0e68 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -1245,7 +1245,7 @@ struct iwl_txfifo_flush_cmd {
__le32 fifo_control;
__le16 flush_control;
__le16 reserved;
-} __attribute__ ((packed));
+} __packed;
/*
* REPLY_WEP_KEY = 0x20
@@ -3547,7 +3547,7 @@ struct iwl_sensitivity_cmd {
struct iwl_enhance_sensitivity_cmd {
__le16 control; /* always use "1" */
__le16 enhance_table[ENHANCE_HD_TABLE_SIZE]; /* use HD_* as index */
-} __attribute__ ((packed));
+} __packed;
/**
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Felix Fietkau @ 2010-07-14 14:44 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo Van Doorn, Christoph Egger, Gertjan van Wingerde,
Bartlomiej Zolnierkiewicz, Helmut Schaa, linux-wireless, users,
netdev, linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <20100714131527.GB2352@tuxdriver.com>
On 2010-07-14 3:15 PM, John W. Linville wrote:
> On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
>> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
>> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
>> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
>> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>> >> so all Code depending on that can't ever be selected and, if there's
>> >> no plan to add these options, should be cleaned up
>> >>
>> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>> >
>> > NAK,
>> >
>> > this is not dead code, it is needed for the Ralink System-on-Chip
>> > Platform devices.
>> >
>> > While I can't fix Kconfig errors and the current KConfig file may be
>> > wrong, this code cannot and will not be deleted.
>>
>> When the config option was introduced, the config options RALINK_RT288X and
>> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>>
>> But since testing is done on SoC boards by Helmut and Felix, I assume the code
>> isn't dead but actually in use.
>
> Perhaps Helmut and Felix can send us the missing code?
The missing code is a MIPS platform port, which is currently being
maintained in OpenWrt, but is not ready for upstream submission yet.
I'm not working on this code at the moment, but I think it will be
submitted once it's ready.
- Felix
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Bartlomiej Zolnierkiewicz @ 2010-07-14 14:14 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Egger, Gertjan van Wingerde, John W. Linville, Felix Fietkau,
Helmut Schaa, linux-wireless, users, netdev, linux-kernel,
vamos-dev, Luis Correia
In-Reply-To: <AANLkTikCeDys9e1EnE9GdiJtDRcbqW3gzvsmjzvB_yDs@mail.gmail.com>
On Wednesday 14 July 2010 02:52:14 pm Ivo Van Doorn wrote:
> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> so all Code depending on that can't ever be selected and, if there's
> >> no plan to add these options, should be cleaned up
> >>
> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >
> > NAK,
> >
> > this is not dead code, it is needed for the Ralink System-on-Chip
> > Platform devices.
> >
> > While I can't fix Kconfig errors and the current KConfig file may be
> > wrong, this code cannot and will not be deleted.
>
> When the config option was introduced, the config options RALINK_RT288X and
> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>
> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> isn't dead but actually in use.
>
> Ivo
I fully agree with Luis and Ivo that the proposed patch is invalid and
shouldn't be applied (the "code cannot and will not be deleted" anyway)..
[ Under "The New Normal" rules the code doesn't even have to work to be
merged and/or stay in the kernel so 9 months of code not being used by
any real user doesn't matter a tiny bit.. ]
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: John W. Linville @ 2010-07-14 13:15 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Christoph Egger, Gertjan van Wingerde, Bartlomiej Zolnierkiewicz,
Felix Fietkau, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTikCeDys9e1EnE9GdiJtDRcbqW3gzvsmjzvB_yDs@mail.gmail.com>
On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> so all Code depending on that can't ever be selected and, if there's
> >> no plan to add these options, should be cleaned up
> >>
> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >
> > NAK,
> >
> > this is not dead code, it is needed for the Ralink System-on-Chip
> > Platform devices.
> >
> > While I can't fix Kconfig errors and the current KConfig file may be
> > wrong, this code cannot and will not be deleted.
>
> When the config option was introduced, the config options RALINK_RT288X and
> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>
> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> isn't dead but actually in use.
Perhaps Helmut and Felix can send us the missing code?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Ivo Van Doorn @ 2010-07-14 12:52 UTC (permalink / raw)
To: Christoph Egger
Cc: Gertjan van Wingerde, John W. Linville, Bartlomiej Zolnierkiewicz,
Felix Fietkau, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTinO32CIe0HBTXjP_bcAz0nMEw6wvcZwcob1fX3r@mail.gmail.com>
On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
>> While RT2800PCI_SOC exists in Kconfig, it depends on either
>> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>> so all Code depending on that can't ever be selected and, if there's
>> no plan to add these options, should be cleaned up
>>
>> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>
> NAK,
>
> this is not dead code, it is needed for the Ralink System-on-Chip
> Platform devices.
>
> While I can't fix Kconfig errors and the current KConfig file may be
> wrong, this code cannot and will not be deleted.
When the config option was introduced, the config options RALINK_RT288X and
RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
But since testing is done on SoC boards by Helmut and Felix, I assume the code
isn't dead but actually in use.
Ivo
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Luis Correia @ 2010-07-14 12:46 UTC (permalink / raw)
To: Christoph Egger
Cc: Ivo van Doorn, Gertjan van Wingerde, John W. Linville,
Bartlomiej Zolnierkiewicz, Felix Fietkau, Helmut Schaa,
linux-wireless, users, netdev, linux-kernel, vamos-dev
In-Reply-To: <29013fb6eab9e95e95d61df894797d2455dfa10c.1279110894.git.siccegge@cs.fau.de>
On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> While RT2800PCI_SOC exists in Kconfig, it depends on either
> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> so all Code depending on that can't ever be selected and, if there's
> no plan to add these options, should be cleaned up
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
NAK,
this is not dead code, it is needed for the Ralink System-on-Chip
Platform devices.
While I can't fix Kconfig errors and the current KConfig file may be
wrong, this code cannot and will not be deleted.
Luis Correia
rt2x00 project admin
> ---
> drivers/net/wireless/rt2x00/Kconfig | 5 ----
> drivers/net/wireless/rt2x00/rt2800pci.c | 39 -------------------------------
> 2 files changed, 0 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
> index eea1ef2..d59195a 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -58,11 +58,6 @@ config RT2800PCI_PCI
> depends on PCI
> default y
>
> -config RT2800PCI_SOC
> - boolean
> - depends on RALINK_RT288X || RALINK_RT305X
> - default y
> -
> config RT2800PCI
> tristate "Ralink rt28xx/rt30xx/rt35xx (PCI/PCIe/PCMCIA) support (EXPERIMENTAL)"
> depends on (RT2800PCI_PCI || RT2800PCI_SOC) && EXPERIMENTAL
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index b2f2327..1445038 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -85,18 +85,9 @@ static void rt2800pci_mcu_status(struct rt2x00_dev *rt2x00dev, const u8 token)
> rt2800_register_write(rt2x00dev, H2M_MAILBOX_CID, ~0);
> }
>
> -#ifdef CONFIG_RT2800PCI_SOC
> -static void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
> -{
> - u32 *base_addr = (u32 *) KSEG1ADDR(0x1F040000); /* XXX for RT3052 */
> -
> - memcpy_fromio(rt2x00dev->eeprom, base_addr, EEPROM_SIZE);
> -}
> -#else
> static inline void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
> {
> }
> -#endif /* CONFIG_RT2800PCI_SOC */
>
> #ifdef CONFIG_RT2800PCI_PCI
> static void rt2800pci_eepromregister_read(struct eeprom_93cx6 *eeprom)
> @@ -1160,25 +1151,6 @@ MODULE_DEVICE_TABLE(pci, rt2800pci_device_table);
> #endif /* CONFIG_RT2800PCI_PCI */
> MODULE_LICENSE("GPL");
>
> -#ifdef CONFIG_RT2800PCI_SOC
> -static int rt2800soc_probe(struct platform_device *pdev)
> -{
> - return rt2x00soc_probe(pdev, &rt2800pci_ops);
> -}
> -
> -static struct platform_driver rt2800soc_driver = {
> - .driver = {
> - .name = "rt2800_wmac",
> - .owner = THIS_MODULE,
> - .mod_name = KBUILD_MODNAME,
> - },
> - .probe = rt2800soc_probe,
> - .remove = __devexit_p(rt2x00soc_remove),
> - .suspend = rt2x00soc_suspend,
> - .resume = rt2x00soc_resume,
> -};
> -#endif /* CONFIG_RT2800PCI_SOC */
> -
> #ifdef CONFIG_RT2800PCI_PCI
> static struct pci_driver rt2800pci_driver = {
> .name = KBUILD_MODNAME,
> @@ -1194,17 +1166,9 @@ static int __init rt2800pci_init(void)
> {
> int ret = 0;
>
> -#ifdef CONFIG_RT2800PCI_SOC
> - ret = platform_driver_register(&rt2800soc_driver);
> - if (ret)
> - return ret;
> -#endif
> #ifdef CONFIG_RT2800PCI_PCI
> ret = pci_register_driver(&rt2800pci_driver);
> if (ret) {
> -#ifdef CONFIG_RT2800PCI_SOC
> - platform_driver_unregister(&rt2800soc_driver);
> -#endif
> return ret;
> }
> #endif
> @@ -1217,9 +1181,6 @@ static void __exit rt2800pci_exit(void)
> #ifdef CONFIG_RT2800PCI_PCI
> pci_unregister_driver(&rt2800pci_driver);
> #endif
> -#ifdef CONFIG_RT2800PCI_SOC
> - platform_driver_unregister(&rt2800soc_driver);
> -#endif
> }
>
> module_init(rt2800pci_init);
> --
> 1.7.0.4
>
> --
> 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: Bug#588196: b43: does not join multicast groups
From: Michael Büsch @ 2010-07-14 12:41 UTC (permalink / raw)
To: Simon Richter
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <20100714075037.GA6128@richter>
On 07/14/2010 09:50 AM, Simon Richter wrote:
> Hi,
>
> On Tue, Jul 13, 2010 at 04:05:10PM +0200, Michael Büsch wrote:
>
>> So it is up to the upper layer to detect the failure. I don't think
>> it's possible to automatically detect such incidents for multicast
>> transmissions. So the mechanism fails here.
>
> Well, it is about *receiving* a multicast transmission
The same applies to receiving. The RX queue is also dropped on switch
from DMA to PIO.
> advertisement, sent to 33:33:00:00:00:01). I have no idea where the
> packet is dropped; from my somewhat limited understanding of 802.11, I'd
> expect the frames to be treated like broadcast frames by the AP, so it'd
> be the receiver dropping them in the MAC filter.
The actual switch from DMA to PIO mode completely reinitializes
the hardware and drops all queues.
--
Greetings Michael.
^ permalink raw reply
* [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Christoph Egger @ 2010-07-14 12:39 UTC (permalink / raw)
To: Ivo van Doorn, Gertjan van Wingerde, John W. Linville,
Bartlomiej Zolnierkiewicz, Felix Fietkau, Helmut Schaa,
linux-wireless, users, netdev, linux-kernel
Cc: vamos-dev
In-Reply-To: <cover.1279110894.git.siccegge@cs.fau.de>
While RT2800PCI_SOC exists in Kconfig, it depends on either
RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
so all Code depending on that can't ever be selected and, if there's
no plan to add these options, should be cleaned up
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
---
drivers/net/wireless/rt2x00/Kconfig | 5 ----
drivers/net/wireless/rt2x00/rt2800pci.c | 39 -------------------------------
2 files changed, 0 insertions(+), 44 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index eea1ef2..d59195a 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -58,11 +58,6 @@ config RT2800PCI_PCI
depends on PCI
default y
-config RT2800PCI_SOC
- boolean
- depends on RALINK_RT288X || RALINK_RT305X
- default y
-
config RT2800PCI
tristate "Ralink rt28xx/rt30xx/rt35xx (PCI/PCIe/PCMCIA) support (EXPERIMENTAL)"
depends on (RT2800PCI_PCI || RT2800PCI_SOC) && EXPERIMENTAL
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index b2f2327..1445038 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -85,18 +85,9 @@ static void rt2800pci_mcu_status(struct rt2x00_dev *rt2x00dev, const u8 token)
rt2800_register_write(rt2x00dev, H2M_MAILBOX_CID, ~0);
}
-#ifdef CONFIG_RT2800PCI_SOC
-static void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
-{
- u32 *base_addr = (u32 *) KSEG1ADDR(0x1F040000); /* XXX for RT3052 */
-
- memcpy_fromio(rt2x00dev->eeprom, base_addr, EEPROM_SIZE);
-}
-#else
static inline void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
{
}
-#endif /* CONFIG_RT2800PCI_SOC */
#ifdef CONFIG_RT2800PCI_PCI
static void rt2800pci_eepromregister_read(struct eeprom_93cx6 *eeprom)
@@ -1160,25 +1151,6 @@ MODULE_DEVICE_TABLE(pci, rt2800pci_device_table);
#endif /* CONFIG_RT2800PCI_PCI */
MODULE_LICENSE("GPL");
-#ifdef CONFIG_RT2800PCI_SOC
-static int rt2800soc_probe(struct platform_device *pdev)
-{
- return rt2x00soc_probe(pdev, &rt2800pci_ops);
-}
-
-static struct platform_driver rt2800soc_driver = {
- .driver = {
- .name = "rt2800_wmac",
- .owner = THIS_MODULE,
- .mod_name = KBUILD_MODNAME,
- },
- .probe = rt2800soc_probe,
- .remove = __devexit_p(rt2x00soc_remove),
- .suspend = rt2x00soc_suspend,
- .resume = rt2x00soc_resume,
-};
-#endif /* CONFIG_RT2800PCI_SOC */
-
#ifdef CONFIG_RT2800PCI_PCI
static struct pci_driver rt2800pci_driver = {
.name = KBUILD_MODNAME,
@@ -1194,17 +1166,9 @@ static int __init rt2800pci_init(void)
{
int ret = 0;
-#ifdef CONFIG_RT2800PCI_SOC
- ret = platform_driver_register(&rt2800soc_driver);
- if (ret)
- return ret;
-#endif
#ifdef CONFIG_RT2800PCI_PCI
ret = pci_register_driver(&rt2800pci_driver);
if (ret) {
-#ifdef CONFIG_RT2800PCI_SOC
- platform_driver_unregister(&rt2800soc_driver);
-#endif
return ret;
}
#endif
@@ -1217,9 +1181,6 @@ static void __exit rt2800pci_exit(void)
#ifdef CONFIG_RT2800PCI_PCI
pci_unregister_driver(&rt2800pci_driver);
#endif
-#ifdef CONFIG_RT2800PCI_SOC
- platform_driver_unregister(&rt2800soc_driver);
-#endif
}
module_init(rt2800pci_init);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 00/11] Removing dead code
From: Christoph Egger @ 2010-07-14 12:39 UTC (permalink / raw)
To: David S. Miller, Alexey Dobriyan, Jiri Pirko, Joe Perches,
Stephen Hemminger, Eric Dumazet, Jesper Nilsson, Tejun Heo,
Dongdong Deng, Jiri Kosina, Samuel Ortiz, Andrew Morton,
Roel Kluin, Nicolas Pitre, Tony Lindgren, Daniel Walker,
Alessandro Rubini, Ivo van Doorn, Gertjan van Wingerde,
John W. Linville, Bartlomiej Zolnierkiewicz, Felix Fietkau,
Helmut Schaa, netdev, linux-kernel, linux-wireless, users
Cc: vamos-dev
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.
I've been running a check on the drivers/net sourcetree for
config Items not defined in Kconfig and found 11 such
cases. Sourcecode blocks depending on these Items are not reachable
from a vanilla kernel -- dead code. I've seen such dead blocks made on
purpose e.g. while integrating new features into the kernel but
generally they're just useless.
Each of the patches in this patchset removes on such dead
config Item, I'd be glad if you consider applying them. I've been
doing deeper analysis of such issues before and can do so again but
I'm not so sure they were fastly usefull.
I build the patches against a vanilla kernel in order to
try if the kernel compiles with this patches
Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.
Regards
Christoph Egger
[0] http://vamos1.informatik.uni-erlangen.de/
Christoph Egger (11):
Removing dead RT2800PCI_SOC
Removing dead {AR,WAVE}LAN
Removing dead CASSINI_QGE_DEBUG
Removing dead CASSINI_MULTICAST_REG_WRITE
Removing dead CASSINI_NAPI
Removing dead CHELSIO_T1_COUGAR
Removing dead ARCH_PNX010X
Removing dead SH_HICOSH4
Removing dead ETRAX_NETWORK_RED_ON_NO_CONNECTION
Removing dead NETWINDER_{T,R}X_DMA_PROBLEMS
Removing dead REDWOOD_{5,6}
drivers/net/Space.c | 6 --
drivers/net/cassini.c | 25 +--------
drivers/net/cassini.h | 4 -
drivers/net/chelsio/subr.c | 48 +---------------
drivers/net/cris/eth_v10.c | 4 -
drivers/net/cs89x0.c | 96 +------------------------------
drivers/net/cs89x0.h | 4 -
drivers/net/irda/w83977af_ir.c | 33 +---------
drivers/net/smc91x.h | 37 ------------
drivers/net/wireless/rt2x00/Kconfig | 5 --
drivers/net/wireless/rt2x00/rt2800pci.c | 39 -------------
11 files changed, 9 insertions(+), 292 deletions(-)
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-14 10:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Guy, Wey-Yi W
In-Reply-To: <1279101655.3719.12.camel@jlt3.sipsolutions.net>
Thanks ;-)
On Wed, 14 Jul 2010 12:00:55 +0200, Johannes Berg
<johannes@sipsolutions.net> wrote:
> [correct wey-yi's address, remove reinette]
>
> On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
>> Hi,
>>
>> I hope I'm writing to the right addresses, this is my first kernel bug
>> report :-)
>>
>> I regulary build linus' tree from git. One day, my wireless card was
>> unable to connect to the access point. dmesg showed something like this:
>>
>> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
>> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
>> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
>> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
>>
>> At first, I thought is was some link quality problem and tried it next
>> to the access point, but it still didn't work.
>> I booted another (older) kernel and with this one, the card was able to
>> connect without any problems.
>>
>> I bisected the problem and came to commit
>> 062bee448bd539580ef9f64efe50fdfe04eeb103
>> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
>>
>> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
>>
>> Will provide more info if needed.
>>
>> Florian
>>
>> PS: Please CC me, i'm not on linux-wireless.
>>
>> --
>> 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: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Johannes Berg @ 2010-07-14 10:00 UTC (permalink / raw)
To: Florian Klink; +Cc: linux-wireless, Guy, Wey-Yi W
In-Reply-To: <1279100021.7275.24.camel@flokli-laptop>
[correct wey-yi's address, remove reinette]
On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
> Hi,
>
> I hope I'm writing to the right addresses, this is my first kernel bug
> report :-)
>
> I regulary build linus' tree from git. One day, my wireless card was
> unable to connect to the access point. dmesg showed something like this:
>
> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
>
> At first, I thought is was some link quality problem and tried it next
> to the access point, but it still didn't work.
> I booted another (older) kernel and with this one, the card was able to
> connect without any problems.
>
> I bisected the problem and came to commit
> 062bee448bd539580ef9f64efe50fdfe04eeb103
> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
>
> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
>
> Will provide more info if needed.
>
> Florian
>
> PS: Please CC me, i'm not on linux-wireless.
>
> --
> 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
* commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-14 9:33 UTC (permalink / raw)
To: linux-wireless; +Cc: ey-yi.w.guy, reinette.chatre, flokli
Hi,
I hope I'm writing to the right addresses, this is my first kernel bug
report :-)
I regulary build linus' tree from git. One day, my wireless card was
unable to connect to the access point. dmesg showed something like this:
[ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
[ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
[ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
[ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
At first, I thought is was some link quality problem and tried it next
to the access point, but it still didn't work.
I booted another (older) kernel and with this one, the card was able to
connect without any problems.
I bisected the problem and came to commit
062bee448bd539580ef9f64efe50fdfe04eeb103
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
My wireless card is a Intel Corporation Wireless WiFi Link 5100.
Will provide more info if needed.
Florian
PS: Please CC me, i'm not on linux-wireless.
^ permalink raw reply
* Re: Bug#588196: b43: does not join multicast groups
From: Simon Richter @ 2010-07-14 7:50 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <4C3C7296.3070700@bu3sch.de>
Hi,
On Tue, Jul 13, 2010 at 04:05:10PM +0200, Michael Büsch wrote:
> So it is up to the upper layer to detect the failure. I don't think
> it's possible to automatically detect such incidents for multicast
> transmissions. So the mechanism fails here.
Well, it is about *receiving* a multicast transmission (IPv6 router
advertisement, sent to 33:33:00:00:00:01). I have no idea where the
packet is dropped; from my somewhat limited understanding of 802.11, I'd
expect the frames to be treated like broadcast frames by the AP, so it'd
be the receiver dropping them in the MAC filter.
Simon
^ permalink raw reply
* [PATCH 2/3] ath9k_htc: implement mac80211 flush op
From: Sujith @ 2010-07-14 3:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1279070845-29442-3-git-send-email-lrodriguez@atheros.com>
Luis R. Rodriguez wrote:
> This implements the mac80211 flush callback to let mac80211
> flush the hardware queues when it deems appropriate.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> index e38ca66..fc234a7 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> @@ -1803,6 +1803,29 @@ static void ath9k_htc_set_coverage_class(struct ieee80211_hw *hw,
> mutex_unlock(&priv->mutex);
> }
>
> +static void ath9k_htc_flush(struct ieee80211_hw *hw, bool drop)
> +{
> + struct ath9k_htc_priv *priv = hw->priv;
> + u8 cmd_rsp;
> + int ret;
> +
> + mutex_lock(&priv->mutex);
> +
> + if (priv->op_flags & OP_INVALID)
> + goto err;
> +
> + ath9k_htc_ps_wakeup(priv);
> +
> + WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
> + if (drop)
> + skb_queue_purge(&priv->tx_queue);
> +
> + ath9k_htc_ps_restore(priv);
> +
> +err:
> + mutex_unlock(&priv->mutex);
> +}
> +
I don't think this would work.
Queuing of packets is done in the HIF (USB) layer.
Flushing would require dropping (or not) the buffered packets in the
USB layer. Also, we don't actually require this, since IDLE state
is handled in radio_disable(), where everything is flushed properly ...
Sujith
^ permalink raw reply
* Re: Rate control & USB
From: Julian Calaby @ 2010-07-14 1:53 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Helmut Schaa, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTikP6mK-S5kLVrRDiQGX9MAgOt-uyUn0A1Z-593A@mail.gmail.com>
On Wed, Jul 14, 2010 at 05:51, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
>> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
>>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
>>> <helmut.schaa@googlemail.com> wrote:
>>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
>>> >> I am currently looking into the old problem of the mac80211 rate
>>> >> control algorithms
>>> >> and USB devices. The Ralink USB devices (and as far as I know, the
>>> >> other USB devices
>>> >> as well), do not work well with the PID and Minstrel algorithms. This
>>> >> is caused by the
>>> >> fact that USB devices do not report the TX status to mac80211.
>>> >
>>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
>>> > register like the PCI variants? Does it contain useful data or just crap?
>>>
>>> Well I guess he has the registers (we don't have rt2870 specific specsheets,
>>> but the register definitions from the original Ralink driver to
>>> suggest the register
>>> is there). However, even if it contains valid data, how do you want to match
>>> the contents of that register with the sent frames in the queue?
>>
>> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
>> contain the same ID alongside the TX status after the frame was processed
>> by the hw.
>
> True, but we would have the same problem in rt2800pci, that the number
> of bits is too limited to completely identify a queue + queue index correctly.
We could have a table that matches queue and queue index to the
packet's ID. So if we're sending packet #47 from queue #1, and it gets
assigned id #9, then we drop that information into the table - so when
the hardware tells us the status of packet id #9 we can look up which
queue it is and send it to the right place.
Of course, this means storing a stack of extra data in system memory,
as well as having the complexity of looking up the queue data when we
get the status back, but if we've only got limited bits, then that'll
set a hard limit on the amount of data and time to retrieve, and we
may not even need all of it unless the hardware's running at full
capacity. We could reduce it further if we don't need a status of
*every* packet - we could potentially get away with only storing data
for, let's say, every fourth packet or something.
As we're likely to see similarly crippled devices elsewhere, maybe we
could incorporate this type of accounting into mac80211 somewhere.
Of course, this could just be a huge stack of overhead for a problem
that could be solved much more elegantly, but yeah.
*hands over $0.02*
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [PATCH] ath5k: clean up rxlink handling
From: Bruno Randolf @ 2010-07-14 1:53 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cpu 0: cpu 1:
ath5k_rx_stop
ath5k_tasklet_rx
sc->rxlink = NULL; /* just in case */
// following doesn't link used
// buffer to prev.
ath5k_rxbuf_setup()
In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.
In ath5k_intr() we seem to try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.
After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/base.c | 7 ++-----
drivers/net/wireless/ath/ath5k/base.h | 1 +
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index b0e1ca9..0d5de25 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1728,8 +1728,6 @@ ath5k_rx_stop(struct ath5k_softc *sc)
ath5k_hw_stop_rx_dma(ah); /* disable DMA engine */
ath5k_debug_printrxbuffs(sc, ah);
-
- sc->rxlink = NULL; /* just in case */
}
static unsigned int
@@ -2633,8 +2631,7 @@ ath5k_stop_locked(struct ath5k_softc *sc)
if (!test_bit(ATH_STAT_INVALID, sc->status)) {
ath5k_rx_stop(sc);
ath5k_hw_phy_disable(ah);
- } else
- sc->rxlink = NULL;
+ }
return 0;
}
@@ -2771,7 +2768,7 @@ ath5k_intr(int irq, void *dev_id)
* RXE bit is written, but it doesn't work at
* least on older hardware revs.
*/
- sc->rxlink = NULL;
+ sc->stats.rxeol_intr++;
}
if (status & AR5K_INT_TXURN) {
/* bump tx trigger level */
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 86c90f4..dc1241f 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -137,6 +137,7 @@ struct ath5k_statistics {
unsigned int mib_intr;
unsigned int rxorn_intr;
+ unsigned int rxeol_intr;
};
#if CHAN_DEBUG
^ permalink raw reply related
* Re: [PATCH 2/2] ath5k: disable tasklets during reset
From: Bruno Randolf @ 2010-07-14 1:35 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, ath5k-devel, jirislaby, mickflemm,
lrodriguez
In-Reply-To: <1279035161-10802-2-git-send-email-me@bobcopeland.com>
On Wed July 14 2010 00:32:41 Bob Copeland wrote:
> Based on a patch from Bruno Randolf, attempting useful
> work while we are resetting the chip just leads to interface
> lockups and bad descriptor data, and possibly DMAing to
> freed buffers. Let's suspend all tasklets while
> reprogramming the registers in the card to avoid such
> problems.
>
> In the future we can convert the tasklets to threaded
> interrupt handlers to simplify things.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 20 ++++++++++++++------
> 1 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index b290cc6..b0e1ca9 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -2639,6 +2639,15 @@ ath5k_stop_locked(struct ath5k_softc *sc)
> return 0;
> }
>
> +static void stop_tasklets(struct ath5k_softc *sc)
> +{
> + tasklet_kill(&sc->rxtq);
> + tasklet_kill(&sc->txtq);
> + tasklet_kill(&sc->calib);
> + tasklet_kill(&sc->beacontq);
> + tasklet_kill(&sc->ani_tasklet);
> +}
> +
> /*
> * Stop the device, grabbing the top-level lock to protect
> * against concurrent entry through ath5k_init (which can happen
> @@ -2683,11 +2692,7 @@ ath5k_stop_hw(struct ath5k_softc *sc)
> mmiowb();
> mutex_unlock(&sc->lock);
>
> - tasklet_kill(&sc->rxtq);
> - tasklet_kill(&sc->txtq);
> - tasklet_kill(&sc->calib);
> - tasklet_kill(&sc->beacontq);
> - tasklet_kill(&sc->ani_tasklet);
> + stop_tasklets(sc);
>
> ath5k_rfkill_hw_stop(sc->ah);
>
> @@ -2937,8 +2942,11 @@ ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan)
>
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
>
> + ath5k_hw_set_imr(ah, 0);
> + synchronize_irq(sc->pdev->irq);
> + stop_tasklets(sc);
> +
> if (chan) {
> - ath5k_hw_set_imr(ah, 0);
> ath5k_txq_cleanup(sc);
> ath5k_rx_stop(sc);
please get this into 2.6.36...
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: move reset to mac80211 workqueue
From: Bruno Randolf @ 2010-07-14 1:35 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, ath5k-devel, jirislaby, mickflemm,
lrodriguez
In-Reply-To: <1279035161-10802-1-git-send-email-me@bobcopeland.com>
On Wed July 14 2010 00:32:40 Bob Copeland wrote:
> We currently trigger a reset via a tasklet when certain error
> conditions are detected so that the card will (eventually)
> restart. Unfortunately this makes locking complicated since
> reset can also be called in process context (e.g. for channel
> change). Currently nothing protects against concurrent resets,
> which can be the source of corruption bugs.
>
> Reset takes too long to spinlock the whole thing, so this
> patch moves deferred resets into the mac80211 workqueue to
> enable use of sc->lock mutex.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 38
> +++++++++++++++++-------------- drivers/net/wireless/ath/ath5k/base.h |
> 3 +-
> drivers/net/wireless/ath/ath5k/debug.c | 2 +-
> 3 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 20328bd..b290cc6 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -388,7 +388,7 @@ static int ath5k_init(struct ath5k_softc *sc);
> static int ath5k_stop_locked(struct ath5k_softc *sc);
> static int ath5k_stop_hw(struct ath5k_softc *sc);
> static irqreturn_t ath5k_intr(int irq, void *dev_id);
> -static void ath5k_tasklet_reset(unsigned long data);
> +static void ath5k_reset_work(struct work_struct *work);
>
> static void ath5k_tasklet_calibrate(unsigned long data);
>
> @@ -831,11 +831,12 @@ ath5k_attach(struct pci_dev *pdev, struct
> ieee80211_hw *hw)
>
> tasklet_init(&sc->rxtq, ath5k_tasklet_rx, (unsigned long)sc);
> tasklet_init(&sc->txtq, ath5k_tasklet_tx, (unsigned long)sc);
> - tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long)sc);
> tasklet_init(&sc->calib, ath5k_tasklet_calibrate, (unsigned long)sc);
> tasklet_init(&sc->beacontq, ath5k_tasklet_beacon, (unsigned long)sc);
> tasklet_init(&sc->ani_tasklet, ath5k_tasklet_ani, (unsigned long)sc);
>
> + INIT_WORK(&sc->reset_work, ath5k_reset_work);
> +
> ret = ath5k_eeprom_read_mac(ah, mac);
> if (ret) {
> ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
> @@ -2294,8 +2295,8 @@ err_unmap:
> * frame contents are done as needed and the slot time is
> * also adjusted based on current state.
> *
> - * This is called from software irq context (beacontq or restq
> - * tasklets) or user context from ath5k_beacon_config.
> + * This is called from software irq context (beacontq tasklets)
> + * or user context from ath5k_beacon_config.
> */
> static void
> ath5k_beacon_send(struct ath5k_softc *sc)
> @@ -2328,7 +2329,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> sc->bmisscount);
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "stuck beacon, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> return;
> }
> @@ -2684,7 +2685,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
>
> tasklet_kill(&sc->rxtq);
> tasklet_kill(&sc->txtq);
> - tasklet_kill(&sc->restq);
> tasklet_kill(&sc->calib);
> tasklet_kill(&sc->beacontq);
> tasklet_kill(&sc->ani_tasklet);
> @@ -2737,7 +2737,7 @@ ath5k_intr(int irq, void *dev_id)
> */
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "fatal int, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> } else if (unlikely(status & AR5K_INT_RXORN)) {
> /*
> * Receive buffers are full. Either the bus is busy or
> @@ -2752,7 +2752,7 @@ ath5k_intr(int irq, void *dev_id)
> if (ah->ah_mac_srev < AR5K_SREV_AR5212) {
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "rx overrun, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> else
> tasklet_schedule(&sc->rxtq);
> @@ -2799,14 +2799,6 @@ ath5k_intr(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -static void
> -ath5k_tasklet_reset(unsigned long data)
> -{
> - struct ath5k_softc *sc = (void *)data;
> -
> - ath5k_reset(sc, sc->curchan);
> -}
> -
> /*
> * Periodically recalibrate the PHY to account
> * for temperature/environment changes.
> @@ -2830,7 +2822,7 @@ ath5k_tasklet_calibrate(unsigned long data)
> * to load new gain values.
> */
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
> - ath5k_reset(sc, sc->curchan);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> if (ath5k_hw_phy_calibrate(ah, sc->curchan))
> ATH5K_ERR(sc, "calibration of channel %u failed\n",
> @@ -2934,6 +2926,8 @@ drop_packet:
> /*
> * Reset the hardware. If chan is not NULL, then also pause rx/tx
> * and change to the given channel.
> + *
> + * This should be called with sc->lock.
> */
> static int
> ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> @@ -2990,6 +2984,16 @@ err:
> return ret;
> }
>
> +static void ath5k_reset_work(struct work_struct *work)
> +{
> + struct ath5k_softc *sc = container_of(work, struct ath5k_softc,
> + reset_work);
> +
> + mutex_lock(&sc->lock);
> + ath5k_reset(sc, sc->curchan);
> + mutex_unlock(&sc->lock);
> +}
> +
> static int ath5k_start(struct ieee80211_hw *hw)
> {
> return ath5k_init(hw->priv);
> diff --git a/drivers/net/wireless/ath/ath5k/base.h
> b/drivers/net/wireless/ath/ath5k/base.h index 56221bc..86c90f4 100644
> --- a/drivers/net/wireless/ath/ath5k/base.h
> +++ b/drivers/net/wireless/ath/ath5k/base.h
> @@ -47,6 +47,7 @@
> #include <linux/if_ether.h>
> #include <linux/leds.h>
> #include <linux/rfkill.h>
> +#include <linux/workqueue.h>
>
> #include "ath5k.h"
> #include "debug.h"
> @@ -189,7 +190,7 @@ struct ath5k_softc {
> unsigned int led_pin, /* GPIO pin for driving LED */
> led_on; /* pin setting for LED on */
>
> - struct tasklet_struct restq; /* reset tasklet */
> + struct work_struct reset_work; /* deferred chip reset */
>
> unsigned int rxbufsize; /* rx size based on mtu */
> struct list_head rxbuf; /* receive buffer */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index 8c63886..ebb9c23 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -279,7 +279,7 @@ static ssize_t write_file_reset(struct file *file,
> {
> struct ath5k_softc *sc = file->private_data;
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "debug file triggered reset\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> return count;
> }
please get this into 2.6.36...
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* [PATCH 0/3] ath9k: flush patches
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
These patchs add the mac8021 flush op to both ath9k and ath9k_htc.
Tested with AR9003 and AR9271.
Luis R. Rodriguez (3):
ath9k: implement mac80211 flush op
ath9k_htc: implement mac80211 flush op
ath9k_htc: make ath9k_htc_tx_aggr_oper() static
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 33 ++++++++++++++++++++++---
drivers/net/wireless/ath/ath9k/main.c | 19 ++++++++++++++
2 files changed, 48 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/3] ath9k_htc: implement mac80211 flush op
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-1-git-send-email-lrodriguez@atheros.com>
This implements the mac80211 flush callback to let mac80211
flush the hardware queues when it deems appropriate.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index e38ca66..fc234a7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1803,6 +1803,29 @@ static void ath9k_htc_set_coverage_class(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
}
+static void ath9k_htc_flush(struct ieee80211_hw *hw, bool drop)
+{
+ struct ath9k_htc_priv *priv = hw->priv;
+ u8 cmd_rsp;
+ int ret;
+
+ mutex_lock(&priv->mutex);
+
+ if (priv->op_flags & OP_INVALID)
+ goto err;
+
+ ath9k_htc_ps_wakeup(priv);
+
+ WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
+ if (drop)
+ skb_queue_purge(&priv->tx_queue);
+
+ ath9k_htc_ps_restore(priv);
+
+err:
+ mutex_unlock(&priv->mutex);
+}
+
struct ieee80211_ops ath9k_htc_ops = {
.tx = ath9k_htc_tx,
.start = ath9k_htc_start,
@@ -1825,4 +1848,5 @@ struct ieee80211_ops ath9k_htc_ops = {
.set_rts_threshold = ath9k_htc_set_rts_threshold,
.rfkill_poll = ath9k_htc_rfkill_poll_state,
.set_coverage_class = ath9k_htc_set_coverage_class,
+ .flush = ath9k_htc_flush,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ath9k_htc: make ath9k_htc_tx_aggr_oper() static
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-1-git-send-email-lrodriguez@atheros.com>
This fixes this sparse complaint:
CHECK drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:441:5:
warning: symbol 'ath9k_htc_tx_aggr_oper'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index fc234a7..fe4c185 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -438,10 +438,11 @@ static void ath9k_htc_update_rate(struct ath9k_htc_priv *priv,
bss_conf->bssid, be32_to_cpu(trate.capflags));
}
-int ath9k_htc_tx_aggr_oper(struct ath9k_htc_priv *priv,
- struct ieee80211_vif *vif,
- struct ieee80211_sta *sta,
- enum ieee80211_ampdu_mlme_action action, u16 tid)
+static int ath9k_htc_tx_aggr_oper(struct ath9k_htc_priv *priv,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ enum ieee80211_ampdu_mlme_action action,
+ u16 tid)
{
struct ath_common *common = ath9k_hw_common(priv->ah);
struct ath9k_htc_target_aggr aggr;
--
1.7.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