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.


* 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.


* 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)) {

.. 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.


freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to