Date: Fri, 9 Jan 2015 13:00:15 -0800 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> Subject: Re: Atheros AR9565 detected, not working Message-ID: <CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ@mail.gmail.com> In-Reply-To: <54AE1136.8000706@att.net> References: <CAJ-Vmo=rLMaatYY692fzc2CF2iiEXM9Fd5DZZpJTWOD_6mHpQg@mail.gmail.com> <433678684.160603.1419257025708.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> <CAJ-Vmom9zW9eeWvZ8KrpgYWS_MFQ46S1eOd4aUiOQ1S3P%2BbyNA@mail.gmail.com> <54987366.6060803@yahoo.com> <CAJ-VmomUoY3y5vtB88H4eugX01VVWMuuLf1gXsUS4Wptv8jh2Q@mail.gmail.com> <5498780B.90704@yahoo.com> <CAJ-Vmo=eaKGG9ha99%2B5gGdOE7OxkKq9RG3auc-2VP=ES0bvGmw@mail.gmail.com> <5498944C.4040706@yahoo.com> <CAJ-VmonQsa=D52esXPiEY_csngXrA8n3hGZoS9ix1o-RAC_uEA@mail.gmail.com> <CAJ-VmonaSP5sOSii6HWUHwuTxd_30dXv%2BhH6ZDEVNzHopj9vLA@mail.gmail.com> <54AD3DF5.1070905@att.net> <54AE1136.8000706@att.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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> wro=
te:
> Removing just the ar9300_enable_rf_kill() bit works too, but now ath(4) e=
ndlessly spews
>
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D3, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D1, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D2, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D1, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D2, nbufs=3D128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=3D128?
>
> 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 an=
ything, just been working on (and suprisingly fixing) issues with my HP Env=
y Sleekbook 6 since the holidays. I'll be cleaning up my patches and posti=
ng to the wiki this week (hopefully). Also still sitting on that ACPI patc=
h 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 A=
R9565 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? ...beca=
use I need some way to connect my newly-fixed laptop wifi-enable key to som=
e function to enable/disable the radios. Right now I'm just throwing an ev=
ent 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: polar=
ity */
>>> ar9300eep.h:#define EEP_RFSILENT_POLARITY_S 1 /* bit 1: polar=
ity */
>>> 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"
>>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ>