* [PATCH 12/12] ath9k: Disable autosleep feature by default.
From: Sujith @ 2009-09-17 3:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vivek Natarajan <vnatarajan@atheros.com>
Autosleep needs to be disabled for AR9287 chipsets also.
Since autosleep is not used for any of the currently supported
chipsets, disable it by default and can be enabled if needed
for any of the future chipsets.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8146826..84abf30 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3700,15 +3700,7 @@ void ath9k_hw_fill_cap_info(struct ath_hw *ah)
}
#endif
- if ((ah->hw_version.macVersion == AR_SREV_VERSION_5416_PCI) ||
- (ah->hw_version.macVersion == AR_SREV_VERSION_5416_PCIE) ||
- (ah->hw_version.macVersion == AR_SREV_VERSION_9160) ||
- (ah->hw_version.macVersion == AR_SREV_VERSION_9100) ||
- (ah->hw_version.macVersion == AR_SREV_VERSION_9280) ||
- (ah->hw_version.macVersion == AR_SREV_VERSION_9285))
- pCap->hw_caps &= ~ATH9K_HW_CAP_AUTOSLEEP;
- else
- pCap->hw_caps |= ATH9K_HW_CAP_AUTOSLEEP;
+ pCap->hw_caps &= ~ATH9K_HW_CAP_AUTOSLEEP;
if (AR_SREV_9280(ah) || AR_SREV_9285(ah))
pCap->hw_caps &= ~ATH9K_HW_CAP_4KB_SPLITTRANS;
--
1.6.4.3
^ permalink raw reply related
* [PATCH 11/12] ath9k: Fix regression in PA calibration
From: Sujith @ 2009-09-17 3:58 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
The commit "ath9k: Fix bugs in programming registers during PA CAL"
removed a REG_READ of 0x7834. This resulted in incorrect
computation of the subsequent value to be written in RF2G6.
This patch fixes the regression by re-adding the REG_READ.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 22a3a69..0ad6d0b 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -936,6 +936,7 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
regVal |= (1 << (19 + i));
REG_WRITE(ah, 0x7834, regVal);
udelay(1);
+ regVal = REG_READ(ah, 0x7834);
regVal &= (~(0x1 << (19 + i)));
reg_field = MS(REG_READ(ah, 0x7840), AR9285_AN_RXTXBB1_SPARE9);
regVal |= (reg_field << (19 + i));
--
1.6.4.3
^ permalink raw reply related
* [PATCH 10/12] ath9k: Fix bug in chain handling
From: Sujith @ 2009-09-17 3:58 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Senthil Balasubramanian <senthilkumar@atheros.com>
* This patch fixes a bug in calculating the scaled
power for three chain chipsets.
* Also, a delay is needed after setting DAC low-power mode in
TOP1 RF register (Top Level Register Bits).
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom_def.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index ae7fb5d..4071fc9 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -509,6 +509,8 @@ static void ath9k_hw_def_set_board_values(struct ath_hw *ah,
REG_RMW_FIELD(ah, AR_AN_TOP1, AR_AN_TOP1_DACIPMODE,
eep->baseEepHeader.dacLpMode);
+ udelay(100);
+
REG_RMW_FIELD(ah, AR_PHY_FRAME_CTL, AR_PHY_FRAME_CTL_TX_CLIP,
pModal->miscBits >> 2);
@@ -902,7 +904,7 @@ static void ath9k_hw_set_def_power_per_rate_table(struct ath_hw *ah,
u16 powerLimit)
{
#define REDUCE_SCALED_POWER_BY_TWO_CHAIN 6 /* 10*log10(2)*2 */
-#define REDUCE_SCALED_POWER_BY_THREE_CHAIN 10 /* 10*log10(3)*2 */
+#define REDUCE_SCALED_POWER_BY_THREE_CHAIN 9 /* 10*log10(3)*2 */
struct ath_regulatory *regulatory = ath9k_hw_regulatory(ah);
struct ar5416_eeprom_def *pEepData = &ah->eeprom.def;
--
1.6.4.3
^ permalink raw reply related
* [PATCH 09/12] ath9k: Fix AHB reset for AR9280
From: Sujith @ 2009-09-17 3:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vivek Natarajan <vnatarajan@atheros.com>
The commit "ath9k: Do an AHB reset before doing RTC reset"
fixed RTC reset issue for AR9280 2.0 chipsets and above.
The fix is valid for all AR9280 chipsets.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 323df96..8146826 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1793,7 +1793,7 @@ static void ath9k_hw_set_regs(struct ath_hw *ah, struct ath9k_channel *chan,
static bool ath9k_hw_chip_reset(struct ath_hw *ah,
struct ath9k_channel *chan)
{
- if (OLC_FOR_AR9280_20_LATER) {
+ if (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL)) {
if (!ath9k_hw_set_reset_reg(ah, ATH9K_RESET_POWER_ON))
return false;
} else if (!ath9k_hw_set_reset_reg(ah, ATH9K_RESET_WARM))
--
1.6.4.3
^ permalink raw reply related
* [PATCH 08/12] ath9k: Adjust the chainmasks properly
From: Sujith @ 2009-09-17 3:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Senthil Balasubramanian <senthilkumar@atheros.com>
This is needed to account for the number of chains in use,
not just the number of chains present.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 439f2c7..22a3a69 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -609,14 +609,24 @@ void ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
AR_PHY_CH1_EXT_CCA,
AR_PHY_CH2_EXT_CCA
};
- u8 chainmask;
+ u8 chainmask, rx_chain_status;
+ rx_chain_status = REG_READ(ah, AR_PHY_RX_CHAINMASK);
if (AR_SREV_9285(ah))
chainmask = 0x9;
- else if (AR_SREV_9280(ah) || AR_SREV_9287(ah))
- chainmask = 0x1B;
- else
- chainmask = 0x3F;
+ else if (AR_SREV_9280(ah) || AR_SREV_9287(ah)) {
+ if ((rx_chain_status & 0x2) || (rx_chain_status & 0x4))
+ chainmask = 0x1B;
+ else
+ chainmask = 0x09;
+ } else {
+ if (rx_chain_status & 0x4)
+ chainmask = 0x3F;
+ else if (rx_chain_status & 0x2)
+ chainmask = 0x1B;
+ else
+ chainmask = 0x09;
+ }
h = ah->nfCalHist;
--
1.6.4.3
^ permalink raw reply related
* [PATCH 07/12] ath9k: Do a full reset for AR9280
From: Sujith @ 2009-09-17 3:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
AR9280 requires a full reset during channel change and HW reset.
Currently, a fast channel change is done. This patch fixes
this bug.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 2c904c6..323df96 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2366,8 +2366,8 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
(chan->channel != ah->curchan->channel) &&
((chan->channelFlags & CHANNEL_ALL) ==
(ah->curchan->channelFlags & CHANNEL_ALL)) &&
- (!AR_SREV_9280(ah) || (!IS_CHAN_A_5MHZ_SPACED(chan) &&
- !IS_CHAN_A_5MHZ_SPACED(ah->curchan)))) {
+ !(AR_SREV_9280(ah) || IS_CHAN_A_5MHZ_SPACED(chan) ||
+ IS_CHAN_A_5MHZ_SPACED(ah->curchan))) {
if (ath9k_hw_channel_change(ah, chan, sc->tx_chan_width)) {
ath9k_hw_loadnf(ah, ah->curchan);
--
1.6.4.3
^ permalink raw reply related
* [PATCH 06/12] ath9k: Don't read NF when chip has gone through full sleep mode
From: Sujith @ 2009-09-17 3:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
NF value may be incorrect when we read it just after the chip
has gone through a full sleep mode. Reading incorrect NF values
affects RX throughput.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 4731ad2..2c904c6 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2357,7 +2357,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
if (!ath9k_hw_setpower(ah, ATH9K_PM_AWAKE))
return -EIO;
- if (curchan)
+ if (curchan && !ah->chip_fullsleep)
ath9k_hw_getnf(ah, curchan);
if (bChannelChange &&
--
1.6.4.3
^ permalink raw reply related
* [PATCH 05/12] ath9k: Fix rx data corruption
From: Sujith @ 2009-09-17 3:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Setting bit 20 and 25 of 0x8344 can cause occasional rx data
corruption, clear them to fix this issue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index af5bb50..4731ad2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1273,6 +1273,15 @@ static void ath9k_hw_override_ini(struct ath_hw *ah,
*/
REG_SET_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT));
+ if (AR_SREV_9280_10_OR_LATER(ah)) {
+ val = REG_READ(ah, AR_PCU_MISC_MODE2) &
+ (~AR_PCU_MISC_MODE2_HWWAR1);
+
+ if (AR_SREV_9287_10_OR_LATER(ah))
+ val = val & (~AR_PCU_MISC_MODE2_HWWAR2);
+
+ REG_WRITE(ah, AR_PCU_MISC_MODE2, val);
+ }
if (!AR_SREV_5416_20_OR_LATER(ah) ||
AR_SREV_9280_10_OR_LATER(ah))
--
1.6.4.3
^ permalink raw reply related
* [PATCH 04/12] ath9k: Fix chip wakeup issue
From: Sujith @ 2009-09-17 3:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Waking up the chip after powering it down fails sometimes.
In this case the CPU is locked for 200ms. Reduce this
interval to 10ms to avoid excessive busy looping.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 75c3041..b892345 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -106,7 +106,7 @@
#define AH_TSF_WRITE_TIMEOUT 100 /* (us) */
#define AH_TIME_QUANTUM 10
#define AR_KEYTABLE_SIZE 128
-#define POWER_UP_TIME 200000
+#define POWER_UP_TIME 10000
#define SPUR_RSSI_THRESH 40
#define CAB_TIMEOUT_VAL 10
--
1.6.4.3
^ permalink raw reply related
* [PATCH 03/12] ath9k: Restore TSF after RESET
From: Sujith @ 2009-09-17 3:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
For chips requiring RTC reset, TSF has to be restored
after power on reset.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 82a2440..af5bb50 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2338,6 +2338,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
struct ath9k_channel *curchan = ah->curchan;
u32 saveDefAntenna;
u32 macStaId1;
+ u64 tsf = 0;
int i, rx_chainmask, r;
ah->extprotspacing = sc->ht_extprotspacing;
@@ -2372,6 +2373,10 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
macStaId1 = REG_READ(ah, AR_STA_ID1) & AR_STA_ID1_BASE_RATE_11B;
+ /* For chips on which RTC reset is done, save TSF before it gets cleared */
+ if (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ tsf = ath9k_hw_gettsf64(ah);
+
saveLedState = REG_READ(ah, AR_CFG_LED) &
(AR_CFG_LED_ASSOC_CTL | AR_CFG_LED_MODE_SEL |
AR_CFG_LED_BLINK_THRESH_SEL | AR_CFG_LED_BLINK_SLOW);
@@ -2398,6 +2403,10 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
udelay(50);
}
+ /* Restore TSF */
+ if (tsf && AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ ath9k_hw_settsf64(ah, tsf);
+
if (AR_SREV_9280_10_OR_LATER(ah))
REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE);
--
1.6.4.3
^ permalink raw reply related
* [PATCH 02/12] ath9k: Revamp PCIE workarounds
From: Sujith @ 2009-09-17 3:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vivek Natarajan <vnatarajan@atheros.com>
* Disable L1 state ONLY when device is in D3 mode.
* Clear bit 22 of register 0x4004.
* Handle power on/off properly
Not setting the workarounds properly resulted in the
disappearance of the card in certain cases.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 162 +++++++++++++++++++-------------
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 8 +-
drivers/net/wireless/ath/ath9k/reg.h | 3 +-
4 files changed, 103 insertions(+), 72 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index b6c6cca..82a2440 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -965,7 +965,7 @@ int ath9k_hw_init(struct ath_hw *ah)
ath9k_hw_init_mode_regs(ah);
if (ah->is_pciexpress)
- ath9k_hw_configpcipowersave(ah, 0);
+ ath9k_hw_configpcipowersave(ah, 0, 0);
else
ath9k_hw_disablepcie(ah);
@@ -3005,9 +3005,10 @@ void ath9k_ps_restore(struct ath_softc *sc)
* Programming the SerDes must go through the same 288 bit serial shift
* register as the other analog registers. Hence the 9 writes.
*/
-void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore)
+void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore, int power_off)
{
u8 i;
+ u32 val;
if (ah->is_pciexpress != true)
return;
@@ -3017,84 +3018,113 @@ void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore)
return;
/* Nothing to do on restore for 11N */
- if (restore)
- return;
-
- if (AR_SREV_9280_20_OR_LATER(ah)) {
- /*
- * AR9280 2.0 or later chips use SerDes values from the
- * initvals.h initialized depending on chipset during
- * ath9k_hw_init()
- */
- for (i = 0; i < ah->iniPcieSerdes.ia_rows; i++) {
- REG_WRITE(ah, INI_RA(&ah->iniPcieSerdes, i, 0),
- INI_RA(&ah->iniPcieSerdes, i, 1));
- }
- } else if (AR_SREV_9280(ah) &&
- (ah->hw_version.macRev == AR_SREV_REVISION_9280_10)) {
- REG_WRITE(ah, AR_PCIE_SERDES, 0x9248fd00);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x24924924);
+ if (!restore) {
+ if (AR_SREV_9280_20_OR_LATER(ah)) {
+ /*
+ * AR9280 2.0 or later chips use SerDes values from the
+ * initvals.h initialized depending on chipset during
+ * ath9k_hw_init()
+ */
+ for (i = 0; i < ah->iniPcieSerdes.ia_rows; i++) {
+ REG_WRITE(ah, INI_RA(&ah->iniPcieSerdes, i, 0),
+ INI_RA(&ah->iniPcieSerdes, i, 1));
+ }
+ } else if (AR_SREV_9280(ah) &&
+ (ah->hw_version.macRev == AR_SREV_REVISION_9280_10)) {
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x9248fd00);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x24924924);
+
+ /* RX shut off when elecidle is asserted */
+ REG_WRITE(ah, AR_PCIE_SERDES, 0xa8000019);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x13160820);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0xe5980560);
+
+ /* Shut off CLKREQ active in L1 */
+ if (ah->config.pcie_clock_req)
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x401deffc);
+ else
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x401deffd);
- /* RX shut off when elecidle is asserted */
- REG_WRITE(ah, AR_PCIE_SERDES, 0xa8000019);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x13160820);
- REG_WRITE(ah, AR_PCIE_SERDES, 0xe5980560);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x1aaabe40);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0xbe105554);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x00043007);
- /* Shut off CLKREQ active in L1 */
- if (ah->config.pcie_clock_req)
- REG_WRITE(ah, AR_PCIE_SERDES, 0x401deffc);
- else
- REG_WRITE(ah, AR_PCIE_SERDES, 0x401deffd);
+ /* Load the new settings */
+ REG_WRITE(ah, AR_PCIE_SERDES2, 0x00000000);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x1aaabe40);
- REG_WRITE(ah, AR_PCIE_SERDES, 0xbe105554);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x00043007);
+ } else {
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x9248fc00);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x24924924);
- /* Load the new settings */
- REG_WRITE(ah, AR_PCIE_SERDES2, 0x00000000);
+ /* RX shut off when elecidle is asserted */
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x28000039);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x53160824);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0xe5980579);
- } else {
- REG_WRITE(ah, AR_PCIE_SERDES, 0x9248fc00);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x24924924);
+ /*
+ * Ignore ah->ah_config.pcie_clock_req setting for
+ * pre-AR9280 11n
+ */
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x001defff);
- /* RX shut off when elecidle is asserted */
- REG_WRITE(ah, AR_PCIE_SERDES, 0x28000039);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x53160824);
- REG_WRITE(ah, AR_PCIE_SERDES, 0xe5980579);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x1aaabe40);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0xbe105554);
+ REG_WRITE(ah, AR_PCIE_SERDES, 0x000e3007);
- /*
- * Ignore ah->ah_config.pcie_clock_req setting for
- * pre-AR9280 11n
- */
- REG_WRITE(ah, AR_PCIE_SERDES, 0x001defff);
+ /* Load the new settings */
+ REG_WRITE(ah, AR_PCIE_SERDES2, 0x00000000);
+ }
- REG_WRITE(ah, AR_PCIE_SERDES, 0x1aaabe40);
- REG_WRITE(ah, AR_PCIE_SERDES, 0xbe105554);
- REG_WRITE(ah, AR_PCIE_SERDES, 0x000e3007);
+ udelay(1000);
- /* Load the new settings */
- REG_WRITE(ah, AR_PCIE_SERDES2, 0x00000000);
- }
+ /* set bit 19 to allow forcing of pcie core into L1 state */
+ REG_SET_BIT(ah, AR_PCIE_PM_CTRL, AR_PCIE_PM_CTRL_ENA);
- udelay(1000);
+ /* Several PCIe massages to ensure proper behaviour */
+ if (ah->config.pcie_waen) {
+ val = ah->config.pcie_waen;
+ if (!power_off)
+ val &= (~AR_WA_D3_L1_DISABLE);
+ } else {
+ if (AR_SREV_9285(ah) || AR_SREV_9271(ah) ||
+ AR_SREV_9287(ah)) {
+ val = AR9285_WA_DEFAULT;
+ if (!power_off)
+ val &= (~AR_WA_D3_L1_DISABLE);
+ } else if (AR_SREV_9280(ah)) {
+ /*
+ * On AR9280 chips bit 22 of 0x4004 needs to be
+ * set otherwise card may disappear.
+ */
+ val = AR9280_WA_DEFAULT;
+ if (!power_off)
+ val &= (~AR_WA_D3_L1_DISABLE);
+ } else
+ val = AR_WA_DEFAULT;
+ }
- /* set bit 19 to allow forcing of pcie core into L1 state */
- REG_SET_BIT(ah, AR_PCIE_PM_CTRL, AR_PCIE_PM_CTRL_ENA);
+ REG_WRITE(ah, AR_WA, val);
+ }
- /* Several PCIe massages to ensure proper behaviour */
- if (ah->config.pcie_waen) {
- REG_WRITE(ah, AR_WA, ah->config.pcie_waen);
- } else {
- if (AR_SREV_9285(ah) || AR_SREV_9271(ah) || AR_SREV_9287(ah))
- REG_WRITE(ah, AR_WA, AR9285_WA_DEFAULT);
+ if (power_off) {
/*
- * On AR9280 chips bit 22 of 0x4004 needs to be set to
- * otherwise card may disappear.
+ * Set PCIe workaround bits
+ * bit 14 in WA register (disable L1) should only
+ * be set when device enters D3 and be cleared
+ * when device comes back to D0.
*/
- else if (AR_SREV_9280(ah))
- REG_WRITE(ah, AR_WA, AR9280_WA_DEFAULT);
- else
- REG_WRITE(ah, AR_WA, AR_WA_DEFAULT);
+ if (ah->config.pcie_waen) {
+ if (ah->config.pcie_waen & AR_WA_D3_L1_DISABLE)
+ REG_SET_BIT(ah, AR_WA, AR_WA_D3_L1_DISABLE);
+ } else {
+ if (((AR_SREV_9285(ah) || AR_SREV_9271(ah) ||
+ AR_SREV_9287(ah)) &&
+ (AR9285_WA_DEFAULT & AR_WA_D3_L1_DISABLE)) ||
+ (AR_SREV_9280(ah) &&
+ (AR9280_WA_DEFAULT & AR_WA_D3_L1_DISABLE))) {
+ REG_SET_BIT(ah, AR_WA, AR_WA_D3_L1_DISABLE);
+ }
+ }
}
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9106a0b..75c3041 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -650,7 +650,7 @@ void ath9k_hw_set_sta_beacon_timers(struct ath_hw *ah,
const struct ath9k_beacon_state *bs);
bool ath9k_hw_setpower(struct ath_hw *ah,
enum ath9k_power_mode mode);
-void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore);
+void ath9k_hw_configpcipowersave(struct ath_hw *ah, int restore, int power_off);
/* Interrupt Handling */
bool ath9k_hw_intrpend(struct ath_hw *ah);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3dc7b5a..5055f18 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1131,7 +1131,7 @@ void ath_radio_enable(struct ath_softc *sc)
int r;
ath9k_ps_wakeup(sc);
- ath9k_hw_configpcipowersave(ah, 0);
+ ath9k_hw_configpcipowersave(ah, 0, 0);
if (!ah->curchan)
ah->curchan = ath_get_curchannel(sc, sc->hw);
@@ -1202,7 +1202,7 @@ void ath_radio_disable(struct ath_softc *sc)
spin_unlock_bh(&sc->sc_resetlock);
ath9k_hw_phy_disable(ah);
- ath9k_hw_configpcipowersave(ah, 1);
+ ath9k_hw_configpcipowersave(ah, 1, 1);
ath9k_ps_restore(sc);
ath9k_hw_setpower(ah, ATH9K_PM_FULL_SLEEP);
}
@@ -1942,7 +1942,7 @@ static int ath9k_start(struct ieee80211_hw *hw)
init_channel = ath_get_curchannel(sc, hw);
/* Reset SERDES registers */
- ath9k_hw_configpcipowersave(sc->sc_ah, 0);
+ ath9k_hw_configpcipowersave(sc->sc_ah, 0, 0);
/*
* The basic interface to setting the hardware in a good
@@ -2170,7 +2170,7 @@ static void ath9k_stop(struct ieee80211_hw *hw)
/* disable HAL and put h/w to sleep */
ath9k_hw_disable(sc->sc_ah);
- ath9k_hw_configpcipowersave(sc->sc_ah, 1);
+ ath9k_hw_configpcipowersave(sc->sc_ah, 1, 1);
ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_FULL_SLEEP);
sc->sc_flags |= SC_OP_INVALID;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index e5c29eb..d83b77f 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -676,8 +676,9 @@
#define AR_RC_HOSTIF 0x00000100
#define AR_WA 0x4004
+#define AR_WA_D3_L1_DISABLE (1 << 14)
#define AR9285_WA_DEFAULT 0x004a05cb
-#define AR9280_WA_DEFAULT 0x0040073f
+#define AR9280_WA_DEFAULT 0x0040073b
#define AR_WA_DEFAULT 0x0000073f
--
1.6.4.3
^ permalink raw reply related
* [PATCH 01/12] ath9k: Set default noise floor value for AR9287
From: Sujith @ 2009-09-17 3:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Vivek Natarajan <vnatarajan@atheros.com>
The default noise floor was never initialized for
AR9287.This patch helps in reporting the correct
RSSI for this version of chipset.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 2 ++
drivers/net/wireless/ath/ath9k/calib.h | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 3234995..439f2c7 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -697,6 +697,8 @@ void ath9k_init_nfcal_hist_buffer(struct ath_hw *ah)
noise_floor = AR_PHY_CCA_MAX_AR9280_GOOD_VALUE;
else if (AR_SREV_9285(ah))
noise_floor = AR_PHY_CCA_MAX_AR9285_GOOD_VALUE;
+ else if (AR_SREV_9287(ah))
+ noise_floor = AR_PHY_CCA_MAX_AR9287_GOOD_VALUE;
else
noise_floor = AR_PHY_CCA_MAX_AR5416_GOOD_VALUE;
diff --git a/drivers/net/wireless/ath/ath9k/calib.h b/drivers/net/wireless/ath/ath9k/calib.h
index 019bcbb..9028ab1 100644
--- a/drivers/net/wireless/ath/ath9k/calib.h
+++ b/drivers/net/wireless/ath/ath9k/calib.h
@@ -28,6 +28,7 @@ extern const struct ath9k_percal_data adc_init_dc_cal;
#define AR_PHY_CCA_MAX_AR5416_GOOD_VALUE -85
#define AR_PHY_CCA_MAX_AR9280_GOOD_VALUE -112
#define AR_PHY_CCA_MAX_AR9285_GOOD_VALUE -118
+#define AR_PHY_CCA_MAX_AR9287_GOOD_VALUE -118
#define AR_PHY_CCA_MAX_HIGH_VALUE -62
#define AR_PHY_CCA_MIN_BAD_VALUE -140
#define AR_PHY_CCA_FILTERWINDOW_LENGTH_INIT 3
--
1.6.4.3
^ permalink raw reply related
* [PATCH 00/12] ath9k bug fixes
From: Sujith @ 2009-09-17 3:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
John,
A bunch of patches fixing various bugs in the driver.
These apply on top of wireless-testing.
Luis would rebase his pending patches on top of these
and resend them.
Thanks.
Sujith
Senthil Balasubramanian (2):
ath9k: Adjust the chainmasks properly
ath9k: Fix bug in chain handling
Sujith (3):
ath9k: Restore TSF after RESET
ath9k: Fix chip wakeup issue
ath9k: Fix regression in PA calibration
Vasanthakumar Thiagarajan (3):
ath9k: Fix rx data corruption
ath9k: Don't read NF when chip has gone through full sleep mode
ath9k: Do a full reset for AR9280
Vivek Natarajan (4):
ath9k: Set default noise floor value for AR9287
ath9k: Revamp PCIE workarounds
ath9k: Fix AHB reset for AR9280
ath9k: Disable autosleep feature by default.
drivers/net/wireless/ath/ath9k/calib.c | 23 +++-
drivers/net/wireless/ath/ath9k/calib.h | 1 +
drivers/net/wireless/ath/ath9k/eeprom_def.c | 4 +-
drivers/net/wireless/ath/ath9k/hw.c | 198 ++++++++++++++++-----------
drivers/net/wireless/ath/ath9k/hw.h | 4 +-
drivers/net/wireless/ath/ath9k/main.c | 8 +-
drivers/net/wireless/ath/ath9k/reg.h | 3 +-
7 files changed, 149 insertions(+), 92 deletions(-)
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Bryan Wu @ 2009-09-17 3:38 UTC (permalink / raw)
To: Larry Finger; +Cc: Gábor Stefanik, mb, linux-wireless
In-Reply-To: <4AB109D7.2060300@lwfinger.net>
Larry Finger wrote:
> Bryan Wu wrote:
>
>> Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
>> anything need me to do, please feel free ping me.
>
> Not an issue with 64-bit DMA. Those people with 64-bit DMA problems
> get error messages.
>
OK, got you. Thanks. I'm just wandering how to debug this driver. It seems that probing passes but the wlan1
interface does not work at all.
-Bryan
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Bryan Wu @ 2009-09-17 3:34 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: mb, stefano.brivio, linux-wireless
In-Reply-To: <69e28c910909160813h2a91ff32hb5fa836f1f7a4963@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/9/16 Bryan Wu <bryan.wu@canonical.com>:
>> Hi Gabor,
>>
>> I tried the latest cmpat-wireless 09-16 snapshot on my machine which runs on 2.6.31
>> Ubuntu Karmic latest kernel. The hardware probing passes and wlan1 interface shows up.
>> But the iwlist scanning got no data from wlan1 interface,
>>
>> dmesg:
>> ---
>> [ 364.371703] b43-pci-bridge 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
>> [ 364.371761] b43-pci-bridge 0000:07:00.0: setting latency timer to 64
>> [ 364.437779] ssb: Sonics Silicon Backplane found on PCI device 0000:07:00.0
>> [ 364.491488] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
>> [ 364.533562] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
>> [ 364.533604] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
>> [ 364.693040] phy0: Selected rate control algorithm 'minstrel'
>> [ 364.701666] Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
>> [ 364.748486] udev: renamed network interface wlan0 to wlan1
>> [ 364.824296] b43 ssb0:0: firmware: requesting b43/ucode15.fw
>> [ 364.901848] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
>> [ 364.931482] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
>> [ 365.140212] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
>
> Please test with v478 or newer.
OK, do you know where can I find this firmware? I just followed the wiki page to get the firmware, but it seems the same version as I am using.
http://linuxwireless.org/en/users/Drivers/b43#device_firmware
>
>> [ 365.144349] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
>> [ 365.412558] b43-phy0 debug: Chip initialized
>> [ 365.413163] b43-phy0 debug: 64-bit DMA initialized
>> [ 365.413356] b43-phy0 debug: QoS enabled
>
> Try disabling QoS via modparam. Also, try earlier compat-wireless versions.
>
Yeah, I disabled the QoS via qos=0 modparam, but the result it is the same.
>> [ 365.434064] Registered led device: b43-phy0::tx
>> [ 365.434315] Registered led device: b43-phy0::rx
>> [ 365.434545] Registered led device: b43-phy0::radio
>> [ 365.435079] b43-phy0 debug: Wireless interface started
>> [ 365.435208] b43-phy0 debug: Adding Interface type 2
>> ----
>>
>> ifconfig:
>> ---
>> $ ifconfig
>> eth0 Link encap:Ethernet HWaddr 00:24:e8:bd:c9:3d
>> inet addr:10.101.46.6 Bcast:10.101.46.255 Mask:255.255.255.0
>> inet6 addr: fe80::224:e8ff:febd:c93d/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:797 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:663 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:76364 (76.3 KB) TX bytes:452350 (452.3 KB)
>> Interrupt:30 Base address:0xc000
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:29 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:6202 (6.2 KB) TX bytes:6202 (6.2 KB)
>>
>> wlan1 Link encap:Ethernet HWaddr 00:25:56:a0:15:58
>> UP BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>> ---
>>
>> $ iwconfig wlan1
>> wlan1 IEEE 802.11bg Mode:Managed Access Point: Not-Associated
>> Tx-Power=20 dBm
>> Retry long limit:7 RTS thr:off Fragment thr:off
>> Power Management:off
>>
>> $ sudo iwlist wlan1 scanning
>> wlan1 No scan results
>
> Use "sudo iw dev wlan1 scan" with mac80211 drivers.
>
Tried that, but the same result, nothing shows up.
Thanks a lot
-Bryan
>> Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
>> anything need me to do, please feel free ping me.
>>
>> Thanks
>> -Bryan
>>
>> Gábor Stefanik wrote:
>>> This chip works (though not quite "supported", that is, can't
>>> guarantee that it will work for you, and speed is not up to par with
>>> wl_hybrid) in wireless-testing. It should also work in
>>> compat-wireless, though compat-wireless is having problems with 64-bit
>>> DMA lately (probably also affects the G-PHY 4311/02). Specifically,
>>> the Dell 1397 (half-mini version of the 1395) and the HP 459263-002
>>> are known to work.
>>>
>>> On Fri, Sep 11, 2009 at 4:22 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
>>>> Dear Michael and Stefano,
>>>>
>>>> I have a project which integrate Broadcom Wifi chip. But the mainline b43 still does not support this chip, because it has Low Power PHY.
>>>>
>>>> Here is my lspci -vvnn output for this device:
>>>> ------
>>>> 07:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
>>>> Subsystem: Dell Device [1028:000c]
>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> Latency: 0, Cache Line Size: 32 bytes
>>>> Interrupt: pin A routed to IRQ 17
>>>> Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
>>>> Capabilities: [40] Power Management version 3
>>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>>>> Capabilities: [58] Vendor Specific Information <?>
>>>> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
>>>> Address: 0000000000000000 Data: 0000
>>>> Capabilities: [d0] Express (v1) Endpoint, MSI 00
>>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
>>>> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>> RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
>>>> ClockPM+ Suprise- LLActRep- BwNot-
>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>>>> Kernel driver in use: b43-pci-bridge
>>>> Kernel modules: ssb
>>>> ------
>>>>
>>>> Do you guys know how to support this device in 2.6.31 kernel? Need I backport some code from wireless-testing? I enabled the PHY_LP config manually in 2.6.31 kernel and b43 driver recognized the hardware wifi device, but it still
>>>> does not work at all.
>>>>
>>>> Or there is no choice but Broadcom's STA driver? I do not like such non-GPL stuff.
>>>>
>>>> Thanks a lot
>>>> --
>>>> Bryan Wu <bryan.wu@canonical.com>
>>>> Kernel Developer +86.138-1617-6545 Mobile
>>>> Ubuntu Kernel Team | Hardware Enablement Team
>>>> Canonical Ltd. www.canonical.com
>>>> Ubuntu - Linux for human beings | www.ubuntu.com
>>>> --
>>>> 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[4]: 2.6.25 kernel & compat-wireless-2009-09-14
From: Nikolai ZHUBR @ 2009-09-17 3:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1253153088.9450.10.camel@johannes.local>
Thursday, September 17, 2009, 5:04:48 AM, Johannes Berg wrote:
>>
>> --- everything.orig/net/wireless/core.c 2009-09-16 23:45:40.000000000 +0400
>> +++ everything/net/wireless/core.c 2009-09-16 23:48:22.000000000 +0400
>> @@ -350,6 +350,7 @@
>>
>> /* give it a proper name */
>> dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
>> + snprintf(rdev->wiphy.dev.bus_id, BUS_ID_SIZE, PHY_NAME "%d", rdev->wiphy_idx);
> Isn't that exactly what dev_set_name() is/was supposed to do?
Well, probably yes, but still it doesn't set bus_id, I've checked.
Probably it needs some correction.
> johannes
^ permalink raw reply
* Re: Re[2]: 2.6.25 kernel & compat-wireless-2009-09-14
From: Johannes Berg @ 2009-09-17 2:04 UTC (permalink / raw)
To: Nikolai ZHUBR; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <142272111.20090917060119@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Thu, 2009-09-17 at 06:01 +0300, Nikolai ZHUBR wrote:
> Thursday, September 17, 2009, 2:54:28 AM, Luis R. Rodriguez wrote:
> >> device_add in 2.6.25.20 wants some bus_id, but bus_id seems to not
> >> be assigned anymore, so device_add fails. Therefore, wiphy_register
> >> fails, and then clearly ieee80211_register_hw fails too.
> >>
> >> Any ideas how to properly fix this?
>
> > FIgure out what the bus_id is used for first.
>
> Hmm, don't know, but the following helps and wlan0 appears:
>
> --- everything.orig/net/wireless/core.c 2009-09-16 23:45:40.000000000 +0400
> +++ everything/net/wireless/core.c 2009-09-16 23:48:22.000000000 +0400
> @@ -350,6 +350,7 @@
>
> /* give it a proper name */
> dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
> + snprintf(rdev->wiphy.dev.bus_id, BUS_ID_SIZE, PHY_NAME "%d", rdev->wiphy_idx);
Isn't that exactly what dev_set_name() is/was supposed to do?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re[2]: 2.6.25 kernel & compat-wireless-2009-09-14
From: Nikolai ZHUBR @ 2009-09-17 3:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890909161654x141f48e4q54f0526bf6c04ea3@mail.gmail.com>
Thursday, September 17, 2009, 2:54:28 AM, Luis R. Rodriguez wrote:
>> device_add in 2.6.25.20 wants some bus_id, but bus_id seems to not
>> be assigned anymore, so device_add fails. Therefore, wiphy_register
>> fails, and then clearly ieee80211_register_hw fails too.
>>
>> Any ideas how to properly fix this?
> FIgure out what the bus_id is used for first.
Hmm, don't know, but the following helps and wlan0 appears:
--- everything.orig/net/wireless/core.c 2009-09-16 23:45:40.000000000 +0400
+++ everything/net/wireless/core.c 2009-09-16 23:48:22.000000000 +0400
@@ -350,6 +350,7 @@
/* give it a proper name */
dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ snprintf(rdev->wiphy.dev.bus_id, BUS_ID_SIZE, PHY_NAME "%d", rdev->wiphy_idx);
mutex_init(&rdev->mtx);
mutex_init(&rdev->devlist_mtx);
> Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-16
From: David Miller @ 2009-09-17 0:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090916204150.GG10634@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 16 Sep 2009 16:41:51 -0400
> Dave,
>
> Here is a batch of fixes for 2.6.32...nothing too controversial
> AFAICT...
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: 2.6.25 kernel & compat-wireless-2009-09-14
From: Luis R. Rodriguez @ 2009-09-16 23:54 UTC (permalink / raw)
To: Nikolai ZHUBR; +Cc: linux-wireless
In-Reply-To: <191513177.20090917035628@mail.ru>
On Wed, Sep 16, 2009 at 5:56 PM, Nikolai ZHUBR <zhubr@mail.ru> wrote:
> Hello all,
>
> After some more digging I think I've found an incompatibility.
>
> device_add in 2.6.25.20 wants some bus_id, but bus_id seems to not
> be assigned anymore, so device_add fails. Therefore, wiphy_register
> fails, and then clearly ieee80211_register_hw fails too.
>
> Any ideas how to properly fix this?
FIgure out what the bus_id is used for first.
Luis
^ permalink raw reply
* 2.6.25 kernel & compat-wireless-2009-09-14
From: Nikolai ZHUBR @ 2009-09-17 0:56 UTC (permalink / raw)
To: linux-wireless
Hello all,
After some more digging I think I've found an incompatibility.
device_add in 2.6.25.20 wants some bus_id, but bus_id seems to not
be assigned anymore, so device_add fails. Therefore, wiphy_register
fails, and then clearly ieee80211_register_hw fails too.
Any ideas how to properly fix this?
Thank you,
Nikolai
^ permalink raw reply
* Re: iwlagn rfkill and 2.6.31 on Intel Corporation PRO/Wireless 5100 AGN
From: Hin-Tak Leung @ 2009-09-16 23:15 UTC (permalink / raw)
To: Fabio Coatti
Cc: reinette chatre, John W. Linville, linux-wireless@vger.kernel.org,
mjg@redhat.com
In-Reply-To: <200909170005.56145.fabio.coatti@gmail.com>
On Wed, Sep 16, 2009 at 11:05 PM, Fabio Coatti <fabio.coatti@gmail.com> wrote:
> In data mercoledì 16 settembre 2009 18:30:19, reinette chatre ha scritto:
>
>> On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
>> > But the behaviour of wifi sybsystem is still weird, (maybe for some
>> > faults on my side). Basically if the laptop starts with wifi enabled
>> > (rfkill off) wpa_supplicant can establish a connection, that can be
>> > killed by rfkill switch (both wifi and bluetooth seems to be killed). But
>> > when I turn off rfkill switch wpa_supplicant is unable to connect again;
>> > looking at syslog/dmesg I can see activity in bt stack, but no messages
>> > regarding wlan0.
>>
>> I think at this point you need to bring the interface back up. When you
>> enable rfkill the interface is brought down, the opposite (bringing
>> interface up) is not done automatically when you disable rfkill.
>>
>
> Ok, I understand your point. In fact I can bring up the interface using
> "ip link set wlan0 up"
> but this leads me to another question: I fail to see how restart the interface
> automatically when rfkill switch is turned off.
> The expected behaviour in this case should be, imho, that wpa_supplicant wakes
> up and restarts the connection.
> IIRC netplug doesn't work with wireless connections and this leaves me
> wondering how I can have wireless la to wake up after turning off rfkill
> switch :)
Hmm, I recently looked to the interaction between rfkill and hal, and
may be able to answer that. The kernel rfkill module also exports its
state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
on kernel version; I think /dev/rfkill is new to
2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
devicekit (again, depend on distro/kernel version) monitors those, and
informs NetworkManager via d-bus messaging when the rkfill state
changes. NetworkManager then if up/down the device and tell
wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
to happen automatically, if hald/devicekit works and talk to
NetworkManager.
i.e. the waking-up should happen automatically if you have the
combination of hald/devicekit and networkmanager.
Does this answer your question?
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: reinette chatre @ 2009-09-16 22:13 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <8db1092f0909161259i5e007282i42f426bc2d0fc0c4@mail.gmail.com>
Hi Maciej,
On Wed, 2009-09-16 at 12:59 -0700, Maciej Rutecki wrote:
> Script (wifi_wpa.sh):
> #!/bin/sh
> INTERFACE=wlan0
> WPA_FILE=/etc/wpa_supplicant/wpa_supplicant.conf
> DRIVER=wext
> ifconfig eth0 down
> ifconfig $INTERFACE up
> sleep 3
> killall wpa_supplicant &> /dev/null
> wpa_supplicant -c $WPA_FILE -D $DRIVER -i $INTERFACE -B
> dhclient $INTERFACE
I think there is a potential race here. You start wpa_supplicant in
background and then immediately request an IP. It is not guaranteed at
this point that you are associated.
Could you perform the last three steps of your script manually?
Reinette
^ permalink raw reply
* Re: iwlagn rfkill and 2.6.31 on Intel Corporation PRO/Wireless 5100 AGN
From: Fabio Coatti @ 2009-09-16 22:05 UTC (permalink / raw)
To: reinette chatre
Cc: John W. Linville, linux-wireless@vger.kernel.org, mjg@redhat.com
In-Reply-To: <1253118619.26521.420.camel@rc-desk>
In data mercoledì 16 settembre 2009 18:30:19, reinette chatre ha scritto:
> On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
> > But the behaviour of wifi sybsystem is still weird, (maybe for some
> > faults on my side). Basically if the laptop starts with wifi enabled
> > (rfkill off) wpa_supplicant can establish a connection, that can be
> > killed by rfkill switch (both wifi and bluetooth seems to be killed). But
> > when I turn off rfkill switch wpa_supplicant is unable to connect again;
> > looking at syslog/dmesg I can see activity in bt stack, but no messages
> > regarding wlan0.
>
> I think at this point you need to bring the interface back up. When you
> enable rfkill the interface is brought down, the opposite (bringing
> interface up) is not done automatically when you disable rfkill.
>
Ok, I understand your point. In fact I can bring up the interface using
"ip link set wlan0 up"
but this leads me to another question: I fail to see how restart the interface
automatically when rfkill switch is turned off.
The expected behaviour in this case should be, imho, that wpa_supplicant wakes
up and restarts the connection.
IIRC netplug doesn't work with wireless connections and this leaves me
wondering how I can have wireless la to wake up after turning off rfkill
switch :)
^ permalink raw reply
* Re[8]: cfg80211 and rfkill_backport question.
From: Nikolai ZHUBR @ 2009-09-16 22:11 UTC (permalink / raw)
To: linux-wireless
Cc: Hin-Tak Leung, Luis R. Rodriguez, Gaurav Jauhar,
Senthil Balasubramanian
In-Reply-To: <3ace41890909160824w146d63e6haddabe645d3e27d2@mail.gmail.com>
Wednesday, September 16, 2009, 6:24:11 PM, Hin-Tak Leung wrote:
>> From what I checked it all looks fine to me, except that there is
>> a circular dependency between cfg80211 and rfkill_backport (which
>> is confirmed by nm output I suppose). Is this circular dependency
>> intentional? Or, could it be avoided? (My understanding was that
>> as module loader loads one file at a time, it just have no way
>> to resolve such symbols, maybe I'm wrong on this)
> Hmm, yes and no... insmod loads modules one at a time; but as long as
> you run depmod, modprobe loads dependent modules automatically. I
> don't know if modprobe works for circular dependency, but it probably
> works correctly (since AFAIK, it reference-counts)?
Well, maybe modprobe is smart enough these days already, but openwrt
doesn't have it.
Anyway.
Circular dependency issue is now gone together with rfkill_backport
as I don't need rfkill at this point.
"Unable to reserve mem region" error was probably MIPS-related or
PCI-related and gone after cold reboot.
Now here is another:
in function wiphy_register (net/wireless/core.c):
device_add returns an error (-22)
Looks like some problem in mac80211<-->kernel_2.6.25 communication?
regards,
Nikolai
^ 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