Atheros AR9565 detected, not working

Anthony Jenkins Anthony.B.Jenkins at att.net
Thu Jan 8 05:10:24 UTC 2015 

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 at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe at freebsd.org"
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath_ar9565_rfkill_gpio-2.0.patch
Type: text/x-patch
Size: 3629 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20150108/adfd99b3/attachment.bin>

More information about the freebsd-wireless mailing list