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"
>>>>
>>
>
>
_______________________________________________
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"
