Re: Add support to AR5424
Hi, I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The question is: wasn't the patch which I found ( http://marc.info/?t=12643791922) merged into OpenBSD official repository or it's bugged? Have maybe anyone tried testing/developing those patches since 2010? Retards, Hubert
Re: Add support to AR5424
On 03/27/13 12:27, Hubert Jarosz wrote: Hi, I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The question is: wasn't the patch which I found ( http://marc.info/?t=12643791922) merged into OpenBSD official repository or it's bugged? If I remember well it breaks at least hidden SSID and maybe also some working devices. Cheers Giovanni
Re: Add support to AR5424
Hi Tom, On Mon, Jun 28, 2010 at 12:26 PM, Tom Murphy open...@pertho.net wrote: On 21/05/10 18:42, Giovanni Bechis wrote: Il 21/05/2010 19.31, Tom Murphy ha scritto: Is there any update on this? Is it possible to get the chipset working? At least latest version breaks this chip (found on IBM x40): ath0 at pci1 dev 2 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, MKK2A Cheers Giovanni Hi all, Any chance to get this patch work ingon the AR5424 in Asus 4g (701) laptops? The aforementioned patch here at least gets the machine no longer locking up so I think it would be a good candidate for going into the tree. Unfortunately, I've not been able to spend too much time on this. Besides, its something very difficult for me to get more envolved on because 1) I do not have the hardware for testing and 2) I do not have the knowledge on wifi network cards. (btw, have you tried the latest patch I sent?) -- Luis Henriques
Re: Add support to AR5424
On 21/05/10 18:42, Giovanni Bechis wrote: Il 21/05/2010 19.31, Tom Murphy ha scritto: Is there any update on this? Is it possible to get the chipset working? At least latest version breaks this chip (found on IBM x40): ath0 at pci1 dev 2 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, MKK2A Cheers Giovanni Hi all, Any chance to get this patch work ingon the AR5424 in Asus 4g (701) laptops? The aforementioned patch here at least gets the machine no longer locking up so I think it would be a good candidate for going into the tree. Tom
Re: Add support to AR5424
Hi,
I'm attaching a patch I've been using for a couple of weeks now. Can
anyone give it a try? As usual, no guarantees -- it may crash your
system, so be careful.
Just let me know of any successful/unsuccessful story.
--
Luis Henriques
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ dev/ic/ar5212.c 23 May 2010 18:33:01 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
voidar5k_ar5212_fill(struct ath_hal *);
HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+voidar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -234,9 +235,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +271,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -312,7 +327,7 @@ ar5k_ar5212_nic_reset(struct ath_hal *ha
HAL_BOOL
ar5k_ar5212_nic_wakeup(struct ath_hal *hal, u_int16_t flags)
{
- u_int32_t turbo, mode, clock;
+ u_int32_t turbo, mode, clock, bus_flags;
turbo = 0;
mode = 0;
@@ -335,7 +350,10 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
clock |= AR5K_AR5212_PHY_PLL_44MHZ;
} else if (flags IEEE80211_CHAN_5GHZ) {
mode |= AR5K_AR5212_PHY_MODE_FREQ_5GHZ;
- clock |= AR5K_AR5212_PHY_PLL_40MHZ;
+ if (hal-ah_radio == AR5K_AR5413)
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ_5413;
+ else
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ;
} else {
AR5K_PRINT(invalid radio frequency mode\n);
return (AH_FALSE);
@@ -361,23 +379,30 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
* Reset and wakeup the device
*/
- /* ...reset chipset and PCI device (if not PCI-E) */
- if (hal-ah_pci_express == AH_FALSE
- ar5k_ar5212_nic_reset(hal, AR5K_AR5212_RC_CHIP) == AH_FALSE) {
- AR5K_PRINT(failed to reset the AR5212 + PCI chipset\n);
+ /* Wakeup the device */
+ if (ar5k_ar5212_set_power(hal,
+ HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
+ AR5K_PRINT(failed to wakeup the AR5212 chipset\n);
+ return (AH_FALSE);
+ }
+
+ /* ...reset chipset and PCI device */
+ bus_flags = (hal-ah_pci_express != AH_FALSE) ? 0 : AR5K_AR5212_RC_PCI;
+ if (ar5k_ar5212_nic_reset(hal, bus_flags) == AH_FALSE) {
+ AR5K_PRINT(failed to reset the AR5212 chipset\n);
return (AH_FALSE);
}
- /* ...wakeup */
+ /* ...wakeup again */
if (ar5k_ar5212_set_power(hal,
HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
- AR5K_PRINT(failed to resume the AR5212 (again)\n);
+ AR5K_PRINT(failed to wakeup (again) the AR5212 chipset\n);
return (AH_FALSE);
}
/* ...final warm reset */
if (ar5k_ar5212_nic_reset(hal, 0) == AH_FALSE) {
- AR5K_PRINT(failed to warm reset the AR5212\n);
+ AR5K_PRINT(failed to
Re: Add support to AR5424
Full patch against latest I assume b/c of the 1.51 version tag of ar5212.c. I'll need to update before I test, but I'll try to test soon. Thanks.
Re: Add support to AR5424
Il 21/05/2010 19.31, Tom Murphy ha scritto: Is there any update on this? Is it possible to get the chipset working? At least latest version breaks this chip (found on IBM x40): ath0 at pci1 dev 2 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, MKK2A Cheers Giovanni
Re: Add support to AR5424
Hi,
Here's another patch with a couple of changes since the last one. Not
sure how this will make any difference to the cards that were not working
with previous versions, but hopefully there will be some changes.
Please let me know if this works for you.
Alexander: sorry for the delay on sending you the debug output, but I've
been very busy on vacations! :-)
--
Luis
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ dev/ic/ar5212.c 3 May 2010 16:23:22 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
voidar5k_ar5212_fill(struct ath_hal *);
HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+voidar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -234,9 +235,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +271,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -312,7 +327,7 @@ ar5k_ar5212_nic_reset(struct ath_hal *ha
HAL_BOOL
ar5k_ar5212_nic_wakeup(struct ath_hal *hal, u_int16_t flags)
{
- u_int32_t turbo, mode, clock;
+ u_int32_t turbo, mode, clock, bus_flags;
turbo = 0;
mode = 0;
@@ -335,7 +350,10 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
clock |= AR5K_AR5212_PHY_PLL_44MHZ;
} else if (flags IEEE80211_CHAN_5GHZ) {
mode |= AR5K_AR5212_PHY_MODE_FREQ_5GHZ;
- clock |= AR5K_AR5212_PHY_PLL_40MHZ;
+ if (hal-ah_radio == AR5K_AR5413)
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ_5413;
+ else
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ;
} else {
AR5K_PRINT(invalid radio frequency mode\n);
return (AH_FALSE);
@@ -361,23 +379,30 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
* Reset and wakeup the device
*/
- /* ...reset chipset and PCI device (if not PCI-E) */
- if (hal-ah_pci_express == AH_FALSE
- ar5k_ar5212_nic_reset(hal, AR5K_AR5212_RC_CHIP) == AH_FALSE) {
- AR5K_PRINT(failed to reset the AR5212 + PCI chipset\n);
+ /* Wakeup the device */
+ if (ar5k_ar5212_set_power(hal,
+ HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
+ AR5K_PRINT(failed to wakeup the AR5212 chipset\n);
return (AH_FALSE);
}
- /* ...wakeup */
+ /* ...reset chipset and PCI device */
+ bus_flags = (hal-ah_pci_express != AH_FALSE) ? 0 : AR5K_AR5212_RC_PCI;
+ if (ar5k_ar5212_nic_reset(hal, bus_flags) == AH_FALSE) {
+ AR5K_PRINT(failed to reset the AR5212 chipset\n);
+ return (AH_FALSE);
+ }
+
+ /* ...wakeup again */
if (ar5k_ar5212_set_power(hal,
HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
- AR5K_PRINT(failed to resume the AR5212 (again)\n);
+ AR5K_PRINT(failed to wakeup (again) the AR5212 chipset\n);
return (AH_FALSE);
}
/* ...final warm reset */
if
Re: Add support to AR5424
On 04/29/10 13:40, Luis Henriques wrote:
On 2010/04/28 18:41, Luis Henriques wrote:
Anyway, this gave me the chance to find some more differences between
ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
HAL_MODE_XR) were defined with the wrong values. See updated patch
bellow.
hmm, I'm not sure about this...
--- sys/dev/ic/ar5xxx.h 20 Apr 2010 22:05:41 - 1.48
+++ sys/dev/ic/ar5xxx.h 28 Apr 2010 17:33:17 -
@@ -92,9 +92,9 @@ typedef enum {
HAL_MODE_TURBO = 0x002,
HAL_MODE_11B = 0x004,
HAL_MODE_PUREG = 0x008,
- HAL_MODE_11G = 0x010,
+ HAL_MODE_11G = 0x080,
HAL_MODE_108G = 0x020,
- HAL_MODE_XR = 0x040,
+ HAL_MODE_XR = 0x010,
HAL_MODE_ALL = 0xfff
} HAL_MODE;
With HAL_MODE_11G = 0x080 and HAL_MODE_XR = 0x010 my system hangs, with
previous values I can at least run ifconfig ath0 scan
The values for these HAL_MODE_XXX constants don't really matter,
unless you want to use the origional binary blob HAL, which we don't
support anyway.
Changing those values is making the difference on my laptop, wrong
values freeze the kernel so I think there's something weird somewhere.
Cheers
Giovanni
Re: Add support to AR5424
Il 29/04/2010 11.59, Giovanni Bechis ha scritto: With this patch my system does not hang anymore but when I try dhclient ath0 my wifi status is no network: $ sudo dhclient ath0 ath0: no link . sleeping I am seeing also some ath0: device timeout kernel messages. Cheers Giovanni
Re: Add support to AR5424
On 2010/04/28 18:41, Luis Henriques wrote:
Anyway, this gave me the chance to find some more differences between
ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
HAL_MODE_XR) were defined with the wrong values. See updated patch
bellow.
hmm, I'm not sure about this...
--- sys/dev/ic/ar5xxx.h 20 Apr 2010 22:05:41 - 1.48
+++ sys/dev/ic/ar5xxx.h 28 Apr 2010 17:33:17 -
@@ -92,9 +92,9 @@ typedef enum {
HAL_MODE_TURBO = 0x002,
HAL_MODE_11B = 0x004,
HAL_MODE_PUREG = 0x008,
- HAL_MODE_11G = 0x010,
+ HAL_MODE_11G = 0x080,
HAL_MODE_108G = 0x020,
- HAL_MODE_XR = 0x040,
+ HAL_MODE_XR = 0x010,
HAL_MODE_ALL = 0xfff
} HAL_MODE;
http://fxr.watson.org/fxr/source/dev/ath/ath_hal/ah.h has this:
410 #ifdef notdef
411 HAL_MODE_11G= 0x010,/* 11g channels
(OFDM/CCK) */
412 #else
413 HAL_MODE_11G= 0x008,/* XXX historical */
414 #endif
The values for these HAL_MODE_XXX constants don't really matter,
unless you want to use the origional binary blob HAL, which we don't
support anyway.
Ok, thanks for clarifing. Anyway, I'll (re)check these constants
agains the linux driver, because I'm pretty sure that this is how they
are defined there.
--
Luis
Re: Add support to AR5424
On 04/27/10 19:34, Luis Henriques wrote: BTW, with my wifi card, it seems to make no difference whether the value 0x0040 or 0x1000 is used. How the hell my card is working??? :-) I tried your latest diff with my card, it is recognized well, there are no more hal status messages from the kernel but the system simply hangs whenever I try to work with the card (ifconfig ath0 scan, dhclient ath0). Cheers Giovanni ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 11 (irq 11) ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR02W, address 00:1f:3a:36:a6:d1
Re: Add support to AR5424
On Wed, Apr 28, 2010 at 2:07 PM, Giovanni Bechis giova...@openbsd.org wrote: On 04/27/10 19:34, Luis Henriques wrote: BTW, with my wifi card, it seems to make no difference whether the value 0x0040 or 0x1000 is used. How the hell my card is working??? :-) I tried your latest diff with my card, it is recognized well, there are no more hal status messages from the kernel but the system simply hangs whenever I try to work with the card (ifconfig ath0 scan, dhclient ath0). Interesting. This is behaviour seems to be different from what Alexander was seeing. Is this correct Alexander? I believe you referred in your last email that your system is not hanging anymore. -- Luis
Re: Add support to AR5424
On Wed, 28 Apr 2010 14:15:27 +0100 Luis Henriques luis.hen...@gmail.com wrote: Interesting. This is behaviour seems to be different from what Alexander was seeing. Is this correct Alexander? I believe you referred in your last email that your system is not hanging anymore. -- Luis Your latest patches lack following changeset: @@ -2860,10 +2860,8 @@ ar5k_ar5212_get_capabilities(struct ath_ if (b) hal-ah_capabilities.cap_mode |= HAL_MODE_11B; -#if 0 if (g) hal-ah_capabilities.cap_mode |= HAL_MODE_11G; -#endif } /* GPIO */ I think this is the reason why kernel locks up on ar5k_ar5212_reset. -- Alexander Vladimirov alexander.idkfa.vladimirov at gmail.com
Re: Add support to AR5424
On Tue, Apr 27, 2010 at 3:59 AM, Alexander Vladimirov alexander.idkfa.vladimi...@gmail.com wrote: On Mon, 26 Apr 2010 20:59:45 +0100 Luis Henriques luis.hen...@gmail.com wrote: @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha /* * Set misc registers */ + /* Enable DCU early termination for this queue */ AR5K_REG_WRITE(AR5K_AR5212_QCU_MISC(queue), AR5K_AR5212_QCU_MISC_DCU_EARLY); + /* Enable DCU to wait for next fragment from QCU */ + AR5K_REG_WRITE(AR5K_AR5212_DCU_MISC(queue), + AR5K_AR5212_QCU_MISC_DCU_EARLY); ^^ This should be AR5K_AR5212_DCU_MISC_FRAG_WAIT Don't have the code here to confirm this, but it looks like you're right. Have you tested this with the correct value? -- Luis
Re: Add support to AR5424
On Tue, Apr 27, 2010 at 10:59:21AM +0800, Alexander Vladimirov wrote:
On Mon, 26 Apr 2010 20:59:45 +0100
Luis Henriques luis.hen...@gmail.com wrote:
@@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
/*
* Set misc registers
*/
+ /* Enable DCU early termination for this queue */
AR5K_REG_WRITE(AR5K_AR5212_QCU_MISC(queue),
AR5K_AR5212_QCU_MISC_DCU_EARLY);
+ /* Enable DCU to wait for next fragment from QCU */
+ AR5K_REG_WRITE(AR5K_AR5212_DCU_MISC(queue),
+ AR5K_AR5212_QCU_MISC_DCU_EARLY);
^^
This should be AR5K_AR5212_DCU_MISC_FRAG_WAIT
Found something else:
In Linux ath5k, constant AR5K_TXQ_FLAG_POST_FR_BKOFF_DIS is defined as
0x1000, while in OpenBSD it is defined as 0x0040. Not sure which one is
correct, but here's another version of the patch that sets it to 0x1000
and also corrects the issue found by Alexander.
BTW, with my wifi card, it seems to make no difference whether the value
0x0040 or 0x1000 is used. How the hell my card is working??? :-)
--
Luis
Index: sys/dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- sys/dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ sys/dev/ic/ar5212.c 27 Apr 2010 17:25:26 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
voidar5k_ar5212_fill(struct ath_hal *);
HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+voidar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -234,9 +235,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +271,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -312,7 +327,7 @@ ar5k_ar5212_nic_reset(struct ath_hal *ha
HAL_BOOL
ar5k_ar5212_nic_wakeup(struct ath_hal *hal, u_int16_t flags)
{
- u_int32_t turbo, mode, clock;
+ u_int32_t turbo, mode, clock, bus_flags;
turbo = 0;
mode = 0;
@@ -335,7 +350,10 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
clock |= AR5K_AR5212_PHY_PLL_44MHZ;
} else if (flags IEEE80211_CHAN_5GHZ) {
mode |= AR5K_AR5212_PHY_MODE_FREQ_5GHZ;
- clock |= AR5K_AR5212_PHY_PLL_40MHZ;
+ if (hal-ah_radio == AR5K_AR5413)
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ_5413;
+ else
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ;
} else {
AR5K_PRINT(invalid radio frequency mode\n);
return (AH_FALSE);
@@ -361,23 +379,30 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
* Reset and wakeup the device
*/
- /* ...reset chipset and PCI device (if not PCI-E) */
- if (hal-ah_pci_express == AH_FALSE
- ar5k_ar5212_nic_reset(hal, AR5K_AR5212_RC_CHIP) == AH_FALSE) {
- AR5K_PRINT(failed to reset the AR5212 + PCI chipset\n);
+ /* Wakeup the device */
+ if (ar5k_ar5212_set_power(hal,
+ HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
+ AR5K_PRINT(failed to wakeup the AR5212 chipset\n);
+ return
Re: Add support to AR5424
On Sun, Apr 25, 2010 at 10:49:26PM +0100, Luis Henriques wrote: On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote: Luis, I have an Asus EEE with uses an AR5424 chipset: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f I tried the latest patch you posted and it locks OpenBSD completely up when bringing the network up (even ifconfig ath0 up locks the system.) Thanks for testing and reporting this, Tom. Just curious about something: the dmesg you show in your email has been collected _without_ the patch, right? Because with the patch I would expect that the rf would be different from 0.0. -- Luis Hi Luis, Yes, that is correct. Do you need the rf value from the patched kernel? I basically patched the latest -CURRENT (cvs tree as of yesterday). Please let me know if you need any more information. Thanks! Tom
Re: Add support to AR5424
The previous patches you sent me off list gave me this: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address XX:XX:XX:XX:XX:XX I'm going to evaluate the new ones tonight and will let you know.
Re: Add support to AR5424
AR5424 14.2 phy 7.0 rf 10.2, WOR5_ETSIC
ar5212.c:ar5k_ar5212_reset() resets tx queues.
I inserted a printf as follows...:
/*
* Reset queues and start beacon timers at the end of the reset routine
*/
for (i = 0; i hal-ah_capabilities.cap_queues.q_tx_num; i++) {
/***/ printf(ar5212_ i=%u/%u\n, i, hal-ah_capabilities.cap_queues.q_tx_num);
AR5K_REG_WRITE_Q(AR5K_AR5212_DCU_QCUMASK(i), i);
if (ar5k_ar5212_reset_tx_queue(hal, i) == AH_FALSE) {
AR5K_PRINTF(failed to reset TX queue #%d\n, i);
return (AH_FALSE);
}
}
when I ifconfig ath0 up, I get:
ar5212_ i=0/10
ar5212_ i=1/10
ar5212_ i=2/10
hard lock, cannot enter DDB
Re: Add support to AR5424
On Mon, Apr 26, 2010 at 03:38:19PM +0100, Luis Henriques wrote: On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy open...@pertho.net wrote: Hi Luis, Yes, that is correct. Do you need the rf value from the patched kernel? I basically patched the latest -CURRENT (cvs tree as of yesterday). Ok, thanks. I just wanted to make sure the patch was identifing correctly your card. The rf value should be different from 0.0. Hi Luis, Yes, it is different from 0.0. This is what I got when I booted up: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address 00:15:af:b5:36:7f Regards, Tom
Re: Add support to AR5424
Luis, I have an Asus EEE with uses an AR5424 chipset: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f I tried the latest patch you posted and it locks OpenBSD completely up when bringing the network up (even ifconfig ath0 up locks the system.) Tom
Re: Add support to AR5424
On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote: Luis, I have an Asus EEE with uses an AR5424 chipset: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f I tried the latest patch you posted and it locks OpenBSD completely up when bringing the network up (even ifconfig ath0 up locks the system.) Thanks for testing and reporting this, Tom. Just curious about something: the dmesg you show in your email has been collected _without_ the patch, right? Because with the patch I would expect that the rf would be different from 0.0. -- Luis
Re: Add support to AR5424
Luis, can you send the latest version of your diff please. There were at least two and I'm not sure which one people should be testing. Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works ok with the existing driver. Other people: if you have ath(4) devices please mail the full dmesg. In the subject line include the line from 'dmesg|grep ath0:' and write the word 'works' or 'broken' at the start of the subject. e.g. Subject: works: ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W Subject: broken: ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W For now I want these for the existing in-tree driver. Doesn't have to be current - 4.6 or newer would be ok. Thanks.
Re: Add support to AR5424
On 2010/04/24 13:19, Luis Henriques wrote: Luis, can you send the latest version of your diff please. There were at least two and I'm not sure which one people should be testing. Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works ok with the existing driver. For testing the patch on this AR5213A, I would recommend you to use the first version I sent which you can find at: http://marc.info/?l=openbsd-techm=126438116226809w=2 The reason for using this one is because it's the only one that makes any difference. All the other versions of this patch still work on my card but made no big difference on the others. you had another version in 20100126231526.ga4...@hades.my.domain which fixes the rf id on 14.2 chips, which i think we should have. Other people: if you have ath(4) devices please mail the full dmesg. In the subject line include the line from 'dmesg|grep ath0:' and write the word 'works' or 'broken' at the start of the subject. e.g. Subject: works: ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W Subject: broken: ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W For now I want these for the existing in-tree driver. Doesn't have to be current - 4.6 or newer would be ok. I hope to be able to submit a new patch during the weekend but, again, I can only guarantee it will work on my card. Adam has volunteered to test any new patches (and several others are also available for testing) but this is a very slow process. This is what I call the _real_ remote debugging :-) fwiw, looking over dmesglog, it seems like the 10.x phys are mainly just in apple machines, all the other 5424 I've seen are 14.x been hunting for it, but I'm not sure where my 5424 is at the moment...
Re: Add support to AR5424
Date: Sat, 24 Apr 2010 14:04:35 +0100 From: Stuart Henderson s...@spacehopper.org On 2010/04/24 13:19, Luis Henriques wrote: Luis, can you send the latest version of your diff please. There were at least two and I'm not sure which one people should be testing. Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works ok with the existing driver. For testing the patch on this AR5213A, I would recommend you to use the first version I sent which you can find at: http://marc.info/?l=openbsd-techm=126438116226809w=2 The reason for using this one is because it's the only one that makes any difference. All the other versions of this patch still work on my card but made no big difference on the others. you had another version in 20100126231526.ga4...@hades.my.domain which fixes the rf id on 14.2 chips, which i think we should have. Other people: if you have ath(4) devices please mail the full dmesg. In the subject line include the line from 'dmesg|grep ath0:' and write the word 'works' or 'broken' at the start of the subject. e.g. Subject: works: ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W Subject: broken: ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W For now I want these for the existing in-tree driver. Doesn't have to be current - 4.6 or newer would be ok. I hope to be able to submit a new patch during the weekend but, again, I can only guarantee it will work on my card. Adam has volunteered to test any new patches (and several others are also available for testing) but this is a very slow process. This is what I call the _real_ remote debugging :-) fwiw, looking over dmesglog, it seems like the 10.x phys are mainly just in apple machines, all the other 5424 I've seen are 14.x been hunting for it, but I'm not sure where my 5424 is at the moment... For what it is worth, my Apple Macmini1,1 has: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 17 (irq 11) ath0: AR5424 10.3 phy 6.1 rf 10.2, WORAW, address 00:14:51:ef:73:fb which, in hostap mode works fairly well if I talk to it using an athn(4), but is a bit unreliable with wpi(4). I do have the attached diff in my tree. I'm not sure if I actually need it or if it's just something I did to experiment with getting 802.11g modes work. Index: ar5212.c === RCS file: /cvs/src/sys/dev/ic/ar5212.c,v retrieving revision 1.51 diff -u -p -r1.51 ar5212.c --- ar5212.c2 Jun 2009 12:39:02 - 1.51 +++ ar5212.c24 Apr 2010 13:40:15 - @@ -2860,7 +2860,7 @@ ar5k_ar5212_get_capabilities(struct ath_ if (b) hal-ah_capabilities.cap_mode |= HAL_MODE_11B; -#if 0 +#if 1 if (g) hal-ah_capabilities.cap_mode |= HAL_MODE_11G; #endif
Re: Add support to AR5424
I actually did, your patch was the starting point, but I encountered ath0:
device timeout errors while testing with both patches applied, so it still
needs deeper research.
2010/4/25 Luis Henriques luis.hen...@gmail.com
Hi Alexander,
I was wondering whether you tested this code + my original patch. I
just merged both patches and I'm still able to use my card.
However, with my card the code you added (function ar5k_ar2425_channel)
is not actually activated -- I follow into the default case where function
ar5k_ar5112_channel is invoked.
I can send a patch merging the 2 patches if anyone is interested but
merging them is probably something easy to do for someone willing to
test it (my original patch can be found at
http://marc.info/?l=openbsd-techm=126438116226809w=2 ).
--
Luis
On Sun, Apr 25, 2010 at 01:51:12AM +0800, Alexander Vladimirov wrote:
On Sat, 24 Apr 2010 16:26:01 +0100
Federico G. Schwindt fg...@lodoss.net wrote:
+ else if (hal-ah_radio == AR5K_AR2425)
+ ret = ar5k_ar5111_channel(hal, channel);
^^
shouldn't that be ar_2425?
Oh sorry, sure it should. I was cleaning other changes and introduced
this typo. Here is fixed and re-tested patch:
Index: sys/dev/ic/ar5212.c
===
RCS file: /cvs/src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 ar5212.c
--- sys/dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ sys/dev/ic/ar5212.c 24 Apr 2010 15:47:12 -
@@ -2860,10 +2860,8 @@ ar5k_ar5212_get_capabilities(struct ath_
if (b)
hal-ah_capabilities.cap_mode |= HAL_MODE_11B;
-#if 0
if (g)
hal-ah_capabilities.cap_mode |= HAL_MODE_11G;
-#endif
}
/* GPIO */
Index: sys/dev/ic/ar5xxx.c
===
RCS file: /cvs/src/sys/dev/ic/ar5xxx.c,v
retrieving revision 1.55
diff -u -p -u -p -r1.55 ar5xxx.c
--- sys/dev/ic/ar5xxx.c 23 Sep 2009 18:03:30 - 1.55
+++ sys/dev/ic/ar5xxx.c 24 Apr 2010 15:47:14 -
@@ -87,6 +87,7 @@ u_int32_tar5k_ar5110_chan2athchan(HAL_
HAL_BOOL ar5k_ar5111_channel(struct ath_hal *, HAL_CHANNEL *);
HAL_BOOL ar5k_ar5111_chan2athchan(u_int, struct ar5k_athchan_2ghz
*);
HAL_BOOL ar5k_ar5112_channel(struct ath_hal *, HAL_CHANNEL *);
+HAL_BOOL ar5k_ar2425_channel(struct ath_hal *, HAL_CHANNEL *);
HAL_BOOL ar5k_check_channel(struct ath_hal *, u_int16_t, u_int
flags);
HAL_BOOL ar5k_ar5111_rfregs(struct ath_hal *, HAL_CHANNEL *,
u_int);
@@ -1127,6 +1128,8 @@ ar5k_channel(struct ath_hal *hal, HAL_CH
ret = ar5k_ar5110_channel(hal, channel);
else if (hal-ah_radio == AR5K_AR5111)
ret = ar5k_ar5111_channel(hal, channel);
+ else if (hal-ah_radio == AR5K_AR2425)
+ ret = ar5k_ar2425_channel(hal, channel);
else
ret = ar5k_ar5112_channel(hal, channel);
@@ -1283,6 +1286,44 @@ ar5k_ar5112_channel(struct ath_hal *hal,
AR5K_PHY_WRITE(0x27, data 0xff);
AR5K_PHY_WRITE(0x36, (data 8) 0x7f);
+
+ return (AH_TRUE);
+}
+
+HAL_BOOL
+ar5k_ar2425_channel(struct ath_hal *hal, HAL_CHANNEL *channel)
+{
+ u_int32_t data, data0, data2;
+ u_int16_t c;
+
+ data = data0 = data2 = 0;
+ c = channel-c_channel + hal-ah_chanoff;
+
+ /*
+ * Set the channel on the AR2425
+ */
+ if (c 4800) {
+ data0 = ar5k_bitswap((c - 2272), 8);
+ data2 = 0;
+ } else if ((c - (c % 5)) != 2 || c 5435) {
+ if (!(c % 20) c 5120)
+ data0 = ar5k_bitswap(((c - 4800) / 20 2), 8);
+ else if (!(c % 10))
+ data0 = ar5k_bitswap(((c - 4800) / 10 1), 8);
+ else if (!(c % 5))
+ data0 = ar5k_bitswap((c - 4800) / 5, 8);
+ else
+ return (AH_FALSE);
+ data2 = ar5k_bitswap(1, 2);
+ } else {
+ data0 = ar5k_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
+ data2 = ar5k_bitswap(0, 2);
+ }
+
+ data = (data0 4) | (data2 2) | 0x1001;
+
+ AR5K_PHY_WRITE(0x27, data 0xff);
+ AR5K_PHY_WRITE(0x36, (data 8) 0x7f);
return (AH_TRUE);
}
--
Alexander Vladimirov alexander.idkfa.vladimi...@gmail.com
Re: Add support to AR5424
On Sun, Apr 25, 2010 at 03:25:03AM +0800, Alexander Vladimirov wrote: I actually did, your patch was the starting point, but I encountered ath0: device timeout errors while testing with both patches applied, so it still needs deeper research. Great, thanks. That's valuable information ;-) -- Luis
Re: Add support to AR5424
Hi Alexander (and others),
I am attaching a new patch which merges your patch with another one
I have never sent to tech@ before. I shared this patch with some other
guys that were testing it, but I believe it's worth trying it again
with your modifications.
Could someone run a quick test? Again, this patch has been tested by
me on my HW and it seems to be working fine.
--
Luis
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ dev/ic/ar5212.c 24 Apr 2010 19:31:45 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
voidar5k_ar5212_fill(struct ath_hal *);
HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+voidar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -234,9 +235,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +271,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -312,7 +327,7 @@ ar5k_ar5212_nic_reset(struct ath_hal *ha
HAL_BOOL
ar5k_ar5212_nic_wakeup(struct ath_hal *hal, u_int16_t flags)
{
- u_int32_t turbo, mode, clock;
+ u_int32_t turbo, mode, clock, bus_flags;
turbo = 0;
mode = 0;
@@ -335,7 +350,10 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
clock |= AR5K_AR5212_PHY_PLL_44MHZ;
} else if (flags IEEE80211_CHAN_5GHZ) {
mode |= AR5K_AR5212_PHY_MODE_FREQ_5GHZ;
- clock |= AR5K_AR5212_PHY_PLL_40MHZ;
+ if (hal-ah_radio == AR5K_AR5413)
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ_5413;
+ else
+ clock |= AR5K_AR5212_PHY_PLL_40MHZ;
} else {
AR5K_PRINT(invalid radio frequency mode\n);
return (AH_FALSE);
@@ -361,23 +379,30 @@ ar5k_ar5212_nic_wakeup(struct ath_hal *h
* Reset and wakeup the device
*/
- /* ...reset chipset and PCI device (if not PCI-E) */
- if (hal-ah_pci_express == AH_FALSE
- ar5k_ar5212_nic_reset(hal, AR5K_AR5212_RC_CHIP) == AH_FALSE) {
- AR5K_PRINT(failed to reset the AR5212 + PCI chipset\n);
+ /* Wakeup the device */
+ if (ar5k_ar5212_set_power(hal,
+ HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
+ AR5K_PRINT(failed to wakeup the AR5212 chipset\n);
+ return (AH_FALSE);
+ }
+
+ /* ...reset chipset and PCI device */
+ bus_flags = (hal-ah_pci_express != AH_FALSE) ? 0 : AR5K_AR5212_RC_PCI;
+ if (ar5k_ar5212_nic_reset(hal, bus_flags) == AH_FALSE) {
+ AR5K_PRINT(failed to reset the AR5212 chipset\n);
return (AH_FALSE);
}
- /* ...wakeup */
+ /* ...wakeup again */
if (ar5k_ar5212_set_power(hal,
HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
- AR5K_PRINT(failed to resume the AR5212 (again)\n);
+ AR5K_PRINT(failed to wakeup (again) the AR5212 chipset\n);
return (AH_FALSE);
}
/* ...final warm reset */
if
Re: Add support to AR5424
I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this?
Re: Add support to AR5424
On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com wrote: I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this? Yep, still around. But not sure how I can help without the actual HW. Sometime ago I submited a patch that is working for my card: ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq 11) ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX I'm using a CVS head kernel with this patch on my laptop, but some other guys tried the same patch with different revs of the card without success: http://marc.info/?l=openbsd-techm=126437914024661w=2 Try the patch to see what happens. Ah, and send the dmesg (at least the lines identifing the card. -- Luis
Re: Add support to AR5424
Lines identifying the card: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX I have the version the other folks had that had issues with your patch. I can still attempt to use the patch if you'd like... On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques luis.hen...@gmail.comwrote: On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com wrote: I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this? Yep, still around. But not sure how I can help without the actual HW. Sometime ago I submited a patch that is working for my card: ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq 11) ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX I'm using a CVS head kernel with this patch on my laptop, but some other guys tried the same patch with different revs of the card without success: http://marc.info/?l=openbsd-techm=126437914024661w=2 Try the patch to see what happens. Ah, and send the dmesg (at least the lines identifing the card. -- Luis
Re: Add support to AR5424
On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote: Lines identifying the card: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX I have the version the other folks had that had issues with your patch. I can still attempt to use the patch if you'd like... Well, I guess there's no point trying it since this version has been tested already. I can take a look again at the linux and netbsd code to try to figure out what is missing to have your card working. But it will be trial error: I send you a patch and you test it :-) I'll try to get some time today or tomorrow to dive into the driver again. -- Luis On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques luis.hen...@gmail.comwrote: On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com wrote: I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this? Yep, still around. But not sure how I can help without the actual HW. Sometime ago I submited a patch that is working for my card: ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq 11) ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX I'm using a CVS head kernel with this patch on my laptop, but some other guys tried the same patch with different revs of the card without success: http://marc.info/?l=openbsd-techm=126437914024661w=2 Try the patch to see what happens. Ah, and send the dmesg (at least the lines identifing the card. -- Luis
Re: Add support to AR5424
On Thu, Mar 11, 2010 at 1:20 AM, Abel Abraham Camarillo Ojeda acam...@the00z.org wrote: Anyone knows what happened to this? ... or it just got lost in the mist? I'm currently using a CVS head kernel patched with this. But since the patch seems to benefit myself only (no one else has reported a successfull usage of it), most probably it will be dropped. -- Luis
Re: Add support to AR5424
Bret S. Lambert bret.lamb...@gmail.com wrote: On Mon, Jan 25, 2010 at 06:18:33PM +, Luis Henriques wrote: On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Wha, you mean I have to dismantle my AspireOne again and put the minipcie back in to test it? But last time I did that I had to drill out some of the screws :-) (only joking, I can do this on the eee instead, it's far easier to dismantle! and this is great news). Please also send URLs of where the borrowed code is from so the licensing is totally clear. Here's the link to the Linux ath5k driver: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=tree;f=drivers/net/wireless/ath/ath5k;h=d625eae851dd0c1e42e52a182d8408ebee855377;hb=a2febcd43d859a48672ad922990bd27e5628271f (not 100% sure if this is the exact same version I used, can check that later if it actually matters.) File main.c (in directory ..) sets the license to Dual BSD/GPL. IIRC, it's more dependent upon the licence in the individual files, not the note that satisfies the Linux kernel's just utterly weird tell me your license so I can refuse to load you bits. But, the files in there, where they aren't (c) reyk@, appear to be either straight-up BSD-with-GPL option, or apparently cut-n-paset from OpenBSD's license.template(!) (as in the file you say is dual- licensed), so I think you're on solid footing here. And the link to the NetBSD driver: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/isc/atheros_hal/dist/?only_with_tag=MAIN Anyone knows what happened to this? ... or it just got lost in the mist? -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
Re: Add support to AR5424
Luis Henriques wrote: If you're able to test this patch, please let me know if anything changed from previous patch. The wireless doesn't work but some error codes have changed, now hal statuses are: ath0: unable to reset hardware; hal status 2160264736 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359275568 ath0: unable to reset hardware; hal status 359370144 ath0: unable to reset hardware; hal status 359275568 Thanks Cheers Giovanni
Re: Add support to AR5424
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote:
Giovanni Bechis wrote:
Stuart Henderson wrote:
On 2010/01/25 00:50, Luis Henriques wrote:
Re-sending with cvs diff -upRN
Unfortunately this diff doesn't work with my card, I have unable to
reset hardware errors whenever I try to scan the network or
configure my device.
I took a look at the code again and one of the main things that is failing
is the correct identification of the chip. From my understanding of the
Linux code, the ah_radio should be identified as AR5K_AR2425.
So, I added a few lines to my initial patch so that this version of the chip
is correctly handled. Note, however, that I might have missed something:
as I told you before, I do not have this card so... no testing.
If you're able to test this patch, please let me know if anything changed
from previous patch.
Regards,
Luis
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ dev/ic/ar5212.c 26 Jan 2010 23:05:40 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
voidar5k_ar5212_fill(struct ath_hal *);
HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+voidar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -234,9 +235,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +271,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -485,12 +500,13 @@ ar5k_ar5212_reset(struct ath_hal *hal, H
*/
if (chanchange == AH_TRUE) {
s_seq = AR5K_REG_READ(AR5K_AR5212_DCU_SEQNUM(0));
- s_ant = AR5K_REG_READ(AR5K_AR5212_DEFAULT_ANTENNA);
} else {
s_seq = 0;
- s_ant = 1;
}
+ /* Save default antenna */
+ s_ant = AR5K_REG_READ(AR5K_AR5212_DEFAULT_ANTENNA);
+
s_led[0] = AR5K_REG_READ(AR5K_AR5212_PCICFG)
AR5K_AR5212_PCICFG_LEDSTATE;
s_led[1] = AR5K_REG_READ(AR5K_AR5212_GPIOCR);
@@ -544,6 +560,8 @@ ar5k_ar5212_reset(struct ath_hal *hal, H
return (AH_FALSE);
}
+ ar5k_ar5212_hw_set_sleep_clock(hal, AH_FALSE);
+
/* PHY access enable */
AR5K_REG_WRITE(AR5K_AR5212_PHY(0), AR5K_AR5212_PHY_SHIFT_5GHZ);
@@ -3034,3 +3052,75 @@ ar5k_ar5212_set_txpower_limit(struct ath
AR5K_PRINTF(changing txpower to %d\n, power);
return (ar5k_ar5212_txpower(hal, channel, power));
}
+
+/*
+ * If there is an external 32KHz crystal available, use it
+ * as ref. clock instead of 32/40MHz clock and baseband clocks
+ * to save power during sleep or restore normal 32/40MHz
+ * operation.
+ *
+ * XXX: When operating on 32KHz certain PHY registers (27 - 31,
+ * 123 - 127) require delay on access.
+ */
+void
+ar5k_ar5212_hw_set_sleep_clock(struct ath_hal *hal, HAL_BOOL enable)
+{
+ struct ar5k_eeprom_info *ee = hal-ah_capabilities.cap_eeprom;
+ u_int32_t scal, spending, usec32;
+
+ /* Only set 32KHz settings if we have an external
+* 32KHz crystal present */
+
Re: Add support to AR5424
On 2010/01/25 00:50, Luis Henriques wrote:
Re-sending with cvs diff -upRN
Wha, you mean I have to dismantle my AspireOne again and put the
minipcie back in to test it? But last time I did that I had to drill
out some of the screws :-) (only joking, I can do this on the eee
instead, it's far easier to dismantle! and this is great news).
Please also send URLs of where the borrowed code is from so the
licensing is totally clear.
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 - 1.51
+++ dev/ic/ar5212.c 22 Jan 2010 22:31:45 -
@@ -30,6 +30,7 @@ HAL_BOOL ar5k_ar5212_nic_wakeup(struct
u_int16_t ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
void ar5k_ar5212_fill(struct ath_hal *);
HAL_BOOL ar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
+void ar5k_ar5212_hw_set_sleep_clock(struct ath_hal *, HAL_BOOL);
/*
* Initial register setting for the AR5212
@@ -237,6 +238,11 @@ ar5k_ar5212_attach(u_int16_t device, voi
} else if (srev == AR5K_SREV_VER_AR2425) {
hal-ah_radio = AR5K_AR2425;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -262,6 +268,12 @@ ar5k_ar5212_attach(u_int16_t device, voi
}
hal-ah_phy = AR5K_AR5212_PHY(0);
+ /* Enable pci core retry fix on Hainan (5213A) and later chips */
+ if (srev = AR5K_SREV_VER_AR5213A) {
+ AR5K_REG_ENABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_RETRY_FIX);
+ }
+
if (hal-ah_pci_express == AH_TRUE) {
/* PCI-Express based devices need some extra initialization */
ar5k_write_ini(hal, ar5212_pcie, nitems(ar5212_pcie), 0);
@@ -485,12 +497,13 @@ ar5k_ar5212_reset(struct ath_hal *hal, H
*/
if (chanchange == AH_TRUE) {
s_seq = AR5K_REG_READ(AR5K_AR5212_DCU_SEQNUM(0));
- s_ant = AR5K_REG_READ(AR5K_AR5212_DEFAULT_ANTENNA);
} else {
s_seq = 0;
- s_ant = 1;
}
+ /* Save default antenna */
+ s_ant = AR5K_REG_READ(AR5K_AR5212_DEFAULT_ANTENNA);
+
s_led[0] = AR5K_REG_READ(AR5K_AR5212_PCICFG)
AR5K_AR5212_PCICFG_LEDSTATE;
s_led[1] = AR5K_REG_READ(AR5K_AR5212_GPIOCR);
@@ -544,6 +557,8 @@ ar5k_ar5212_reset(struct ath_hal *hal, H
return (AH_FALSE);
}
+ ar5k_ar5212_hw_set_sleep_clock(hal, AH_FALSE);
+
/* PHY access enable */
AR5K_REG_WRITE(AR5K_AR5212_PHY(0), AR5K_AR5212_PHY_SHIFT_5GHZ);
@@ -3034,3 +3049,58 @@ ar5k_ar5212_set_txpower_limit(struct ath
AR5K_PRINTF(changing txpower to %d\n, power);
return (ar5k_ar5212_txpower(hal, channel, power));
}
+
+/*
+ * If there is an external 32KHz crystal available, use it
+ * as ref. clock instead of 32/40MHz clock and baseband clocks
+ * to save power during sleep or restore normal 32/40MHz
+ * operation.
+ *
+ * XXX: When operating on 32KHz certain PHY registers (27 - 31,
+ * 123 - 127) require delay on access.
+ */
+void
+ar5k_ar5212_hw_set_sleep_clock(struct ath_hal *hal, HAL_BOOL enable)
+{
+ struct ar5k_eeprom_info *ee = hal-ah_capabilities.cap_eeprom;
+
+ /* Only set 32KHz settings if we have an external
+ * 32KHz crystal present */
+ if ((AR5K_EEPROM_HAS32KHZCRYSTAL(ee-ee_misc1) ||
+ AR5K_EEPROM_HAS32KHZCRYSTAL_OLD(ee-ee_misc1))
+ enable) {
+ /* TODO */
+ } else {
+ /* Disable sleep clock operation and
+ * restore default parameters */
+ AR5K_REG_DISABLE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_SLEEP_CLOCK_EN);
+
+ AR5K_REG_WRITE_BITS(AR5K_AR5212_PCICFG,
+ AR5K_AR5212_PCICFG_SLEEP_CLOCK_RATE, 0);
+
+ AR5K_REG_WRITE(AR5K_AR5212_PHY_SCR, 0x1f);
+ AR5K_REG_WRITE(AR5K_AR5212_PHY_SLMT,
+ AR5K_AR5212_PHY_SLMT_32MHZ);
+
+ /* TODO: handle other versions */
+ AR5K_REG_WRITE(AR5K_AR5212_PHY_SCAL,
+ AR5K_AR5212_PHY_SCAL_32MHZ);
+
+ AR5K_REG_WRITE(AR5K_AR5212_PHY_SCLOCK,
+ AR5K_AR5212_PHY_SCLOCK_32MHZ);
+ AR5K_REG_WRITE(AR5K_AR5212_PHY_SDELAY,
Re: Add support to AR5424
Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Wha, you mean I have to dismantle my AspireOne again and put the minipcie back in to test it? Don't worry, I have this wireless card on my laptop too ;-) Cheers Giovanni
Re: Add support to AR5424
Giovanni Bechis wrote: Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Unfortunately this diff doesn't work with my card, I have unable to reset hardware errors whenever I try to scan the network or configure my device. Cheers Giovanni OpenBSD 4.6-current (GENERIC.MP) #4: Mon Jan 25 15:38:08 CET 2010 giova...@bigio.snb.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2145779712 (2046MB) avail mem = 2079301632 (1982MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdf010 (19 entries) bios0: vendor Hewlett-Packard version F.32 date 03/03/2009 bios0: Hewlett-Packard HP Pavilion dv6700 Notebook PC acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SRAT WDAT SSDT MCFG HPET APIC BOOT SLIC acpi0: wakeup devices MAC0(S5) P2P0(S5) KBC0(S3) MSE0(S3) XVR3(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2500 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-60, 2009.47 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Turion(tm) 64 X2 Mobile Technology TL-60, 2009.11 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 7 (P2P0) acpiprt2 at acpi0: bus 5 (XVR0) acpiprt3 at acpi0: bus 9 (XVR1) acpiprt4 at acpi0: bus 3 (XVR2) acpiprt5 at acpi0: bus 1 (XVR3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, PSS acpicpu1 at acpi0: C3, C2, PSS acpitz0 at acpi0acpitz0: THRM: failed to read _CRT : no critical temperature defined acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model Primary serial type LION oem Hewlett-Packard acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: UVGA acpivout0 at acpivideo0: CRT_ acpivout1 at acpivideo0: LCD_ acpivout2 at acpivideo0: TV__ acpivout3 at acpivideo0: HDMI acpivideo1 at acpi0: VGA_ acpivout4 at acpivideo1: CRT_ acpivout5 at acpivideo1: LCD_ acpivout6 at acpivideo1: TV__ acpivout7 at acpivideo1: HDMI cpu0: PowerNow! K8 2009 MHz: speeds: 2000 1800 1600 800 MHz pci0 at mainbus0 bus 0 NVIDIA MCP65 Memory rev 0xa3 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 vendor NVIDIA, unknown product 0x0442 rev 0xa3 nviic0 at pci0 dev 1 function 1 NVIDIA MCP65 SMBus rev 0xa1 iic0 at nviic0 iic1 at nviic0 spdmem0 at iic1 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM spdmem1 at iic1 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM vendor NVIDIA, unknown product 0x0447 (class processor subclass Co-processor, rev 0xa1) at pci0 dev 1 function 3 not configured ohci0 at pci0 dev 2 function 0 NVIDIA MCP65 USB rev 0xa3: apic 2 int 11 (irq 11), version 1.0, legacy support ehci0 at pci0 dev 2 function 1 NVIDIA MCP65 USB rev 0xa3: apic 2 int 7 (irq 7) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 nfe0 at pci0 dev 6 function 0 NVIDIA MCP65 LAN rev 0xa3: apic 2 int 10 (irq 10), address 00:1e:68:0c:02:46 rgephy0 at nfe0 phy 1: RTL8169S/8110S PHY, rev. 2 azalia0 at pci0 dev 7 function 0 NVIDIA MCP65 HD Audio rev 0xa1: apic 2 int 11 (irq 11) azalia0: codecs: Conexant CX20561 audio0 at azalia0 ppb0 at pci0 dev 8 function 0 NVIDIA MCP65 PCI rev 0xa1 pci1 at ppb0 bus 7 Ricoh 5C832 Firewire rev 0x05 at pci1 dev 5 function 0 not configured sdhc0 at pci1 dev 5 function 1 Ricoh 5C822 SD/MMC rev 0x22: apic 2 int 10 (irq 10) sdmmc0 at sdhc0 Ricoh 5C843 MMC rev 0x12 at pci1 dev 5 function 2 not configured Ricoh 5C592 Memory Stick rev 0x12 at pci1 dev 5 function 3 not configured Ricoh 5C852 xD rev 0x12 at pci1 dev 5 function 4 not configured pciide0 at pci0 dev 9 function 0 NVIDIA MCP65 IDE rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TSSTcorp, CDDVDW TS-L632N, 0503 ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) pciide1 at pci0 dev 10 function 0 NVIDIA MCP65 SATA rev 0xa3: DMA pciide1: using
Re: Add support to AR5424
On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Wha, you mean I have to dismantle my AspireOne again and put the minipcie back in to test it? But last time I did that I had to drill out some of the screws :-) (only joking, I can do this on the eee instead, it's far easier to dismantle! and this is great news). Please also send URLs of where the borrowed code is from so the licensing is totally clear. Here's the link to the Linux ath5k driver: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=tree;f=drivers/net/wireless/ath/ath5k;h=d625eae851dd0c1e42e52a182d8408ebee855377;hb=a2febcd43d859a48672ad922990bd27e5628271f (not 100% sure if this is the exact same version I used, can check that later if it actually matters.) File main.c (in directory ..) sets the license to Dual BSD/GPL. And the link to the NetBSD driver: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/isc/atheros_hal/dist/?only_with_tag=MAIN
Re: Add support to AR5424
On Mon, Jan 25, 2010 at 06:18:33PM +, Luis Henriques wrote: On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Wha, you mean I have to dismantle my AspireOne again and put the minipcie back in to test it? But last time I did that I had to drill out some of the screws :-) (only joking, I can do this on the eee instead, it's far easier to dismantle! and this is great news). Please also send URLs of where the borrowed code is from so the licensing is totally clear. Here's the link to the Linux ath5k driver: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=tree;f=drivers/net/wireless/ath/ath5k;h=d625eae851dd0c1e42e52a182d8408ebee855377;hb=a2febcd43d859a48672ad922990bd27e5628271f (not 100% sure if this is the exact same version I used, can check that later if it actually matters.) File main.c (in directory ..) sets the license to Dual BSD/GPL. IIRC, it's more dependent upon the licence in the individual files, not the note that satisfies the Linux kernel's just utterly weird tell me your license so I can refuse to load you bits. But, the files in there, where they aren't (c) reyk@, appear to be either straight-up BSD-with-GPL option, or apparently cut-n-paset from OpenBSD's license.template(!) (as in the file you say is dual- licensed), so I think you're on solid footing here. And the link to the NetBSD driver: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/isc/atheros_hal/dist/?only_with_tag=MAIN
Re: Add support to AR5424
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote: Giovanni Bechis wrote: Stuart Henderson wrote: On 2010/01/25 00:50, Luis Henriques wrote: Re-sending with cvs diff -upRN Unfortunately this diff doesn't work with my card, I have unable to reset hardware errors whenever I try to scan the network or configure my device. ... ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 11 (irq 11) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR02W, address 00:1f:3a:36:a6:d1 This last line indicates that your card is quite different from mine: your MAC version is 14.2 and PHY version is 7.0. Here's the dmesg from my laptop: ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq 11) ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address 00:1b:9e:f5:e6:2a So, without a card for testing it is actually not very easy to submit a patch that would add support for both cards. An interesting thing would be to test with a card that _was_ working without my patch. I would be interested in knowing whether I am breaking something or not. From what you're saying, your card was crashing the kernel when you tryied to use it -- the same behaviour as mine without my mods Regards, Luis
