Here's a patch that works on my laptop's AR9565 - it just allows GPIO BIT_11 accesses. No idea why that works; I thought I discovered BIT_8 was the rfkill bit. I tried allowing both BIT_11 /and/ BIT_8, but that doesn't work (wpa_supplicant(8) can never authenticate). May dig further, but I'm kinda swamped with stuff.

I can conditionally allow BIT_11 GPIOs if the device is an AR9565... should I do that?

Why/how does the Atheros driver emit invalid GPIO bit controls for a device? In other words, if my Atheros 123456 chip wants to do XXX, how does that translate to a GPIO bit access that needs to be blocked in the low-level GPIO functions? Yet another way to put it, what's that blocking logic in ar9300_gpio.c there for?

Thanks,
Anthony

On 01/10/15 17:44, Adrian Chadd wrote:
Yup, it doesn't pick up the config options (like enabling 11n) in the
kernel config. That's turned into opt_xxx.h header files in a kernel
build directory.



-a


On 10 January 2015 at 13:11, Anthony Jenkins <scoobi_...@yahoo.com> wrote:
Ahhh... "make" in the module dir, not good?  I've since done a kernel build
and I noticed it's not showing up (as much).  Why would building the kernel
module that way cause that behavior?

Anthony

________________________________
From: Adrian Chadd <adr...@freebsd.org>
To: Anthony Jenkins <anthony.b.jenk...@att.net>
Cc: Anthony Jenkins <scoobi_...@yahoo.com>; "wirel...@freebsd.org"
<wirel...@freebsd.org>
Sent: Friday, January 9, 2015 4:00 PM

Subject: Re: Atheros AR9565 detected, not working

Hm, are you buliding as a module by doing "make" in the module dir? or
by doing a buildkernel?



-a




On 7 January 2015 at 21:10, Anthony Jenkins <anthony.b.jenk...@att.net>
wrote:
Removing just the ar9300_enable_rf_kill() bit works too, but now ath(4)
endlessly spews

    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=2, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=2, nbufs=128?
    ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
    ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?

Also changed GPIO patch to not block/just/ pin 11 ops instead of all pins
as in previous patch, but if allowing all pins is kosher I'd prefer that.

Anthony

On 01/07/2015 09:08, Anthony Jenkins wrote:
Hi Adrian,

Just letting you know I haven't died in a shootout with the US FBI or
anything, just been working on (and suprisingly fixing) issues with my HP
Envy Sleekbook 6 since the holidays.  I'll be cleaning up my patches and
posting to the wiki this week (hopefully).  Also still sitting on that ACPI
patch for the RTC CMOS handler.

So, would you mind trying your patch again but only with the bits that
allow the GPIO pins to be enabled? If that works, then I'll commit
that
Just to be clear, instead of commenting out the early exits in the GPIO
readers/writers for certain GPIO addresses, I should selectively give the
AR9565 a pass?  ...or do you want me to /just/ comment out the early exits,
and revert the added call to ar9300_enable_rf_kill() and see if that works?
I don't like those early exit bits anyway...
In parallel I'm going to have to tidy up the rfkill capability
API to correctly set bits - I'll likely expand the field in the driver
and have the pre-AR9300 chipset code error out if an out-of-bounds
gpio value is sent.
Excellent!  Anything I can help with?  We /have/ an rfkill API?
...because I need some way to connect my newly-fixed laptop wifi-enable key
to some function to enable/disable the radios.  Right now I'm just throwing
an event over to devd(8).

Thanks,
Anthony

On 12/23/2014 13:06, Adrian Chadd wrote:
On 22 December 2014 at 14:57, Adrian Chadd <adr...@freebsd.org> wrote:

Ok, let me go see what's going on.
I dislike when I say "let me see what's going on" and then I .. see
what's going on.

So:

* the ar5212 HAL does the right thing - it checks the rfkill setup in
ar5212Reset() and enables it if required
* it also populates the rfkill data from EEPROM at attach time
* the sysctl code just grabs the rfkill /eeprom field/ and .. well,
that's the API. So I have to see if that's the same for the AR9300 or
not. Grr.

Well, it kinda is:

ar9300eep.h:#define EEP_RFSILENT_ENABLED        0x0001  /* bit 0:
enabled/disabled */
ar9300eep.h:#define EEP_RFSILENT_ENABLED_S      0      /* bit 0:
enabled/disabled */
ar9300eep.h:#define EEP_RFSILENT_POLARITY      0x0002  /* bit 1:
polarity */
ar9300eep.h:#define EEP_RFSILENT_POLARITY_S    1      /* bit 1: polarity
*/
ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL      0x00fc  /* bits 2..7:
gpio PIN */
ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL_S    2      /* bits 2..7:
gpio PIN */

.. but on the AR5212:

../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL    0x001c
../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S    2
../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY    0x0002
../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY_S    1
../ah_eeprom_v3.h:#define    AR_EEPROM_RFSILENT    0x0f    /* RF
Silent/Clock Run Enable */
../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL    0x001c
../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S    2
../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY    0x0002
../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY_S    1

.. so more bits are available on the ar9300. I have to check the
AR5416 too; maybe more bits are also available there.

Grr!

* Then, the Ar5212 is doing it in ar5212Reset(), but ar5416Reset()
isn't doing it! So I'm going to have to go and hook that up for the
AR5416, AR9160, AR9280, AR9285, AR9287. Ugh.

* the ar9300 HAL on -HEAD has this in ar9300_reset():

    /* Reset ier reference count to disabled */
//    OS_ATOMIC_SET(&ahp->ah_ier_ref_count, 1);C
    if (ath_hal_isrfkillenabled(ah)) {
        ar9300_enable_rf_kill(ah);
    }

.. so it should be enabling it at reset. We shouldn't need to enable
it during ar9300_attach() as the first reset will set it up.

* The AR5212 HAL enables rfkill interrupts, but the AR9300 doesn't.
Apparently there are .. issues. I don't know what they are. So maybe
we should use polling on that particular GPIO pin to provide rfkill
feedback to the driver and eventually the network stack.

So, would you mind trying your patch again but only with the bits that
allow the GPIO pins to be enabled? If that works, then I'll commit
that. In parallel I'm going to have to tidy up the rfkill capability
API to correctly set bits - I'll likely expand the field in the driver
and have the pre-AR9300 chipset code error out if an out-of-bounds
gpio value is sent.

Thanks!



-adrian
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
"freebsd-wireless-unsubscr...@freebsd.org"



Index: sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c
===================================================================
--- sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c	(revision 277102)
+++ sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c	(working copy)
@@ -162,7 +162,6 @@
 
     HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins);
     if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
-        (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
         (gpio == AR9382_GPIO_9_INPUT_ONLY))
     {
         return AH_FALSE;
@@ -348,7 +347,6 @@
 
     HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins);
     if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
-        (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
         (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
     {
         return AH_FALSE;
@@ -378,7 +376,6 @@
 {
     HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins);
     if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
-        (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
         (gpio == AR9382_GPIO_9_INPUT_ONLY))
     {
         return AH_FALSE;
@@ -397,8 +394,7 @@
 {
     u_int32_t gpio_in;
     HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins);
-    if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
-        (gpio == AR9382_GPIO_PIN_11_RESERVED))
+    if ((gpio == AR9382_GPIO_PIN_8_RESERVED))
     {
         return 0xffffffff;
     }
@@ -453,7 +449,6 @@
     HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins);
 
     if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
-        (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
         (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
     {
         return;
@@ -549,8 +544,7 @@
 
     if (AH_PRIVATE(ah)->ah_devid == AR9300_DEVID_AR9380_PCIE) {
         mask = (1 << AR9382_MAX_GPIO_PIN_NUM) - 1;
-        mask &= ~(1 << AR9382_GPIO_PIN_8_RESERVED |
-                  1 << AR9382_GPIO_PIN_11_RESERVED);
+        mask &= ~(1 << AR9382_GPIO_PIN_8_RESERVED);
     }
     return mask;
 }
@@ -562,8 +556,7 @@
 
     if (AH_PRIVATE(ah)->ah_devid == AR9300_DEVID_AR9380_PCIE) {
         invalid = ~((1 << AR9382_MAX_GPIO_PIN_NUM) - 1);
-        invalid |= 1 << AR9382_GPIO_PIN_8_RESERVED |
-                   1 << AR9382_GPIO_PIN_11_RESERVED;
+        invalid |= 1 << AR9382_GPIO_PIN_8_RESERVED;
     }
     if (mask & invalid) {
         ath_hal_printf(ah, "%s: invalid GPIO mask 0x%x\n", __func__, mask);
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to