Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jan 2015 15:45:43 -0500
From:      Anthony Jenkins <Anthony.B.Jenkins@att.net>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Anthony Jenkins <scoobi_doo@yahoo.com>, "wireless@freebsd.org" <wireless@freebsd.org>
Subject:   Re: Atheros AR9565 detected, not working
Message-ID:  <54C2B2F7.3060308@att.net>
In-Reply-To: <CAJ-VmoneyJBkj9MWp-Dbad45tpXPZurryr9OqVg2Bm975dWU5w@mail.gmail.com>
References:  <CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ@mail.gmail.com>	<284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> <CAJ-VmoneyJBkj9MWp-Dbad45tpXPZurryr9OqVg2Bm975dWU5w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------080603060005030405010209
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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_doo@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 <adrian@freebsd.org>
>> To: Anthony Jenkins <Anthony.B.Jenkins@att.net>
>> Cc: Anthony Jenkins <Scoobi_doo@yahoo.com>; "wireless@freebsd.org"
>> <wireless@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.Jenkins@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 <adrian@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-unsubscribe@freebsd.org"
>>>>>
>>


--------------080603060005030405010209
Content-Type: text/x-patch;
 name="ath_allow_gpio_11.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="ath_allow_gpio_11.patch"

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);

--------------080603060005030405010209--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54C2B2F7.3060308>