We had 0x9912 but AR_PHY_SPECTRAL_SCAN is 0x9910. By using the
0x9912 we were making the hardware unresponsive. This allows us
to move forward with hardware reset on ar9271 on the ath9k_htc
driver.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath9k/hw.c |3 ++-
drivers/net/
These are shared between ath9k and the future ath9k_htc driver.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath9k/ahb.c |5 ++-
drivers/net/wireless/ath/ath9k/hw.c | 62 +
drivers/net/wireless/ath/ath9k/hw.h |3 ++
drivers/net/wire
Devices with external radios have revisions which we can count on.
On single chip solutions these EEPROM values for these radio revision
also exist but are not meaningful as the radios are embedded onto the
same chip. Each single-chip device evolves together as one device.
Signed-off-by: Luis R. R
John here this series has the name fix plus two more fixes I made
yesterday to get ar9271 to reset the hw properly.
Luis R. Rodriguez (5):
ath9k_hw: move mac name and rf name helpers to hw code
ath9k_hw: distinguish single-chip solutions on initial probe print
ath9k_hw: add AR9271 single chi
An extra register was being written to for PA calibration
making the hardware unresponsive, remove it. Hardware
reset should now complete fine on ar9271.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath9k/calib.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath9k/hw.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index dedffb8..bb540bf 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
++
On Mon, Oct 26, 2009 at 2:32 PM, Luis R. Rodriguez
wrote:
> On Mon, Oct 26, 2009 at 02:15:13PM -0700, Kalle Valo wrote:
>> "Luis R. Rodriguez" writes:
>>
>> >> I think you should provide the size of hw_name to this function and
>> >> use snprintf() to avoid writing out of bounds.
>> >
>> > I was
On Tue, Oct 27, 2009 at 9:16 AM, Luis R. Rodriguez
wrote:
> The FCC is trying to assist airports that use Terminal Doppler
> Weather Radar (TDWR) systems in avoiding interference with
> some outdoor wireless systems operating in the 5.4 GHz
> (5470 MHz - 5725 MHz) band. One of the things they have
The FCC is trying to assist airports that use Terminal Doppler
Weather Radar (TDWR) systems in avoiding interference with
some outdoor wireless systems operating in the 5.4 GHz
(5470 MHz - 5725 MHz) band. One of the things they have decided
on is to disallow operation on the 5600 MHz - 5650 MHz fre
On Tue, Oct 27, 2009 at 8:53 AM, Luis R. Rodriguez
wrote:
> The FCC is trying to assist airports that use Terminal Doppler
> Weather Radar (TDWR) systems in avoiding interference with
> some outdoor wireless systems operating in the 5.4 GHz
> (5470 MHz - 5725 MHz) band. One of the things they have
The FCC is trying to assist airports that use Terminal Doppler
Weather Radar (TDWR) systems in avoiding interference with
some outdoor wireless systems operating in the 5.4 GHz
(5470 MHz - 5725 MHz) band. One of the things they have decided
on is to disallow operation on the 5600 MHz - 5650 MHz fre
On Tue, Oct 27, 2009 at 7:47 AM, Paul Kench wrote:
> Hello I have an ar9220/9223 dual band atheros card mini-pci, in a mini-PCI to
> PCI adapter.
>
> Shows up in lspci like this.
>
> 02:09.0 Network controller: Atheros Communications Inc. AR922X Wireless
> Network Adapter (rev 01)
>
> I am runni
Hello I have an ar9220/9223 dual band atheros card mini-pci, in a mini-PCI to
PCI adapter.
Shows up in lspci like this.
02:09.0 Network controller: Atheros Communications Inc. AR922X Wireless Network
Adapter (rev 01)
I am running Debian Unstable with kernel 2.6.30-2, and
compat-wireless-2009-
13 matches
Mail list logo
