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