Date: Sat, 10 Jan 2015 21:11:33 +0000 (UTC) From: Anthony Jenkins <scoobi_doo@yahoo.com> To: Adrian Chadd <adrian@freebsd.org>, Anthony Jenkins <Anthony.B.Jenkins@att.net> Cc: "wireless@freebsd.org" <wireless@freebsd.org> Subject: Re: Atheros AR9565 detected, not working Message-ID: <284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> In-Reply-To: <CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ@mail.gmail.com> References: <CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ahhh... "make" in the module dir, not good?=C2=A0 I've since done a kernel =
build and I noticed it's not showing up (as much).=C2=A0 Why would building=
the kernel module that way cause that behavior?
Anthony
From: Adrian Chadd <adrian@freebsd.org>
To: Anthony Jenkins <Anthony.B.Jenkins@att.net>=20
Cc: Anthony Jenkins <Scoobi_doo@yahoo.com>; "wireless@freebsd.org" <wireles=
s@freebsd.org>=20
Sent: Friday, January 9, 2015 4:00 PM
Subject: Re: Atheros AR9565 detected, not working
=20
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
>
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D3, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D1, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D2, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D1, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D0, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3D2, nbufs=
=3D128?
>=C2=A0 =C2=A0 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>=C2=A0 =C2=A0 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.=C2=A0 I'll be cleaning up my patches and =
posting to the wiki this week (hopefully).=C2=A0 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 A=
R9565 a pass?=C2=A0 ...or do you want me to /just/ comment out the early ex=
its, and revert the added call to ar9300_enable_rf_kill() and see if that w=
orks?=C2=A0 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!=C2=A0 Anything I can help with?=C2=A0 We /have/ an rfkill API=
?=C2=A0 ...because I need some way to connect my newly-fixed laptop wifi-en=
able key to some function to enable/disable the radios.=C2=A0 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@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=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0=
001=C2=A0 /* bit 0:
>>> enabled/disabled */
>>> ar9300eep.h:#define EEP_RFSILENT_ENABLED_S=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =
=C2=A0 =C2=A0 /* bit 0:
>>> enabled/disabled */
>>> ar9300eep.h:#define EEP_RFSILENT_POLARITY=C2=A0 =C2=A0 =C2=A0 0x0002=C2=
=A0 /* bit 1: polarity */
>>> ar9300eep.h:#define EEP_RFSILENT_POLARITY_S=C2=A0 =C2=A0 1=C2=A0 =C2=A0=
=C2=A0 /* bit 1: polarity */
>>> ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL=C2=A0 =C2=A0 =C2=A0 0x00fc=C2=
=A0 /* bits 2..7:
>>> gpio PIN */
>>> ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL_S=C2=A0 =C2=A0 2=C2=A0 =C2=A0=
=C2=A0 /* bits 2..7:
>>> gpio PIN */
>>>
>>> .. but on the AR5212:
>>>
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL=C2=A0 =C2=A0 0x00=
1c
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S=C2=A0 =C2=A0 2
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY=C2=A0 =C2=A0 0x00=
02
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY_S=C2=A0 =C2=A0 1
>>> ../ah_eeprom_v3.h:#define=C2=A0 =C2=A0 AR_EEPROM_RFSILENT=C2=A0 =C2=A0 =
0x0f=C2=A0 =C2=A0 /* RF
>>> Silent/Clock Run Enable */
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL=C2=A0 =C2=A0 0x00=
1c
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S=C2=A0 =C2=A0 2
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY=C2=A0 =C2=A0 0x00=
02
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY_S=C2=A0 =C2=A0 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():
>>>
>>>=C2=A0 =C2=A0 /* Reset ier reference count to disabled */
>>> //=C2=A0 =C2=A0 OS_ATOMIC_SET(&ahp->ah_ier_ref_count, 1);C
>>>=C2=A0 =C2=A0 if (ath_hal_isrfkillenabled(ah)) {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ar9300_enable_rf_kill(ah);
>>>=C2=A0 =C2=A0 }
>>>
>>> .. 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"
>>>
>
From owner-freebsd-wireless@FreeBSD.ORG Sat Jan 10 22:44:08 2015
Return-Path: <owner-freebsd-wireless@FreeBSD.ORG>
Delivered-To: wireless@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id AEAA6479
for <wireless@freebsd.org>; Sat, 10 Jan 2015 22:44:08 +0000 (UTC)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com
[IPv6:2a00:1450:400c:c05::235])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 387E0E6F
for <wireless@freebsd.org>; Sat, 10 Jan 2015 22:44:08 +0000 (UTC)
Received: by mail-wi0-f181.google.com with SMTP id r20so8462239wiv.2
for <wireless@freebsd.org>; Sat, 10 Jan 2015 14:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=jVZE3kMI1tkCXwrsq9ijRizxvrCniKxJvksOPC/7hMM=;
b=xTPadmDpezM1AHg64xyUuf+TqkaDm9rORmOpihUG1Mbq0QW5khW1ecOCYAzS5/K3fw
5VULGvTyHyajPmqcbmFerUzJG+2aJOVkeH3b9Tw5nh2sJnzKwM30TlUaGEJEvrphpHtl
tcLWyr7QCFzHe4IUIfsH/HPSigCoNqdwHciUwP/m+wsn38YnXXTOpHBaGQwB/iXNEag7
NFeGLOTQxSw7kNGCpDxRm2zCC6p7zZ94Ua+/shgANBdzw5THwc3E9QyC/vdoYDChkYo3
FKIrcft+Of2yC2kq03MjFcgCK6jCdqMCuF6TOJ8b5YJno+DznXpaHPRGqXjQmPX4TMzn
WZAw==
MIME-Version: 1.0
X-Received: by 10.180.14.136 with SMTP id p8mr17229473wic.20.1420929846714;
Sat, 10 Jan 2015 14:44:06 -0800 (PST)
Sender: adrian.chadd@gmail.com
Received: by 10.216.41.136 with HTTP; Sat, 10 Jan 2015 14:44:06 -0800 (PST)
In-Reply-To: <284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com>
References: <CAJ-Vmo=3WXOnk-9HeeddDtDCs1Gu02WJ6Qj8j43AJu2e_ozyyQ@mail.gmail.com>
<284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com>
Date: Sat, 10 Jan 2015 14:44:06 -0800
X-Google-Sender-Auth: 38wIDrheh2d02q9kjwVmszEsejo
Message-ID: <CAJ-VmoneyJBkj9MWp-Dbad45tpXPZurryr9OqVg2Bm975dWU5w@mail.gmail.com>
Subject: Re: Atheros AR9565 detected, not working
From: Adrian Chadd <adrian@freebsd.org>
To: Anthony Jenkins <scoobi_doo@yahoo.com>
Content-Type: text/plain; charset=UTF-8
Cc: "wireless@freebsd.org" <wireless@freebsd.org>
X-BeenThere: freebsd-wireless@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "Discussions of 802.11 stack,
tools device driver development." <freebsd-wireless.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-wireless>,
<mailto:freebsd-wireless-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-wireless/>;
List-Post: <mailto:freebsd-wireless@freebsd.org>
List-Help: <mailto:freebsd-wireless-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-wireless>,
<mailto:freebsd-wireless-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jan 2015 22:44:08 -0000
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_doo@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 <adrian@freebsd.org>
> To: Anthony Jenkins <Anthony.B.Jenkins@att.net>
> Cc: Anthony Jenkins <Scoobi_doo@yahoo.com>; "wireless@freebsd.org"
> <wireless@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.Jenkins@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 <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:
>>>> 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-unsubscribe@freebsd.org"
>>>>
>>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?284932058.303050.1420924294011.JavaMail.yahoo>