From owner-freebsd-wireless@FreeBSD.ORG Sat Jan 10 21:18:08 2015 Return-Path: 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 1B5BD972 for ; Sat, 10 Jan 2015 21:18:08 +0000 (UTC) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3FC4342 for ; Sat, 10 Jan 2015 21:18:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1420924295; bh=iRnD4XYheIxgmrdOpDJ919t4y16LDXgZ+gqXumvFuJE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=p5MY0HlTNMbYs5GnQ+9GC105kBMhA1yKS4Clq4rXvZj1HareTqrtJp3qYJSVBWN5PJYOS0Mu+NESRHsMWKos+VKGOSNhYJahHknd9C399fl1BrqwbTDvDmsO6Ick2+du13XjImHcr0jRZrfXQm212vMZ2dgxfRhF+6AW84cbdNjrtYneqaPlq8zY67ZSWsaXC51+Vyu1xcLb66le+WMAIf/qDy3yzwcsGcmC/sY3RXnYrdueFN0soHcv2qN/tEU5ms4jrI+8skzIPTk/6rSYnd1UIo4rPGf3aurJE2SrwsxPHKuj3unVHUso14dR1/r9XNbA4eVIPMvkAqCLNHDEhA== Received: from [98.139.215.143] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2015 21:11:35 -0000 Received: from [98.139.212.213] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jan 2015 21:11:35 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 10 Jan 2015 21:11:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 549660.61604.bm@omp1022.mail.bf1.yahoo.com X-YMail-OSG: T0rdU7sVM1mQs2e5WIa1Dgl5009v5OVO64RRSE3Zk6dN1xtfOHgYXai_ySrrbFw OcSgMRDKp0DFz23_JcHZfMmY.vlF7A__n2DJwyalpSIpdDv3bCSfrl2oWYONEcNAIWXNN67FKRtu 9cnLzK7v6asTn5thS516xCsONBmBEJ8bnx.hJjNA1N3qU5uCw_MLW1TjhGfxFVje1OoSBsdSwlTi E2Dtf2LlmHdJq6m.onRKaqSuHBy2_BndfoxEvv1ZvvTt8_VdSq2NCOqPdu_SouuE2v6tS8rltsRu MUCf8a.A2ah71YQBQu21RzxaoFLgVtxLMPnyMu9kBk4PKrWp7TdB_yIBdskQvolR6mIZGCXvateS AHA3_sz9lS5uMsgYKr_cPHwbPQol9Z9kOxwApr6Fie8vxBZNQs8Aad.XUohlYgv2D1KWyMrv050G ZvLhlr_8IEEbTYTnmaBUdkEAmBmeO3HYqdH04jFkMF5frSWJos6yLp7PsCA.6aW.s2Kso2asoayZ V_g-- Received: by 76.13.26.110; Sat, 10 Jan 2015 21:11:35 +0000 Date: Sat, 10 Jan 2015 21:11:33 +0000 (UTC) From: Anthony Jenkins Reply-To: Anthony Jenkins To: Adrian Chadd , Anthony Jenkins Message-ID: <284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> In-Reply-To: References: Subject: Re: Atheros AR9565 detected, not working MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 21:18:08 -0000 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 To: Anthony Jenkins =20 Cc: Anthony Jenkins ; "wireless@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 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 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: 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 ; 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 ; Sat, 10 Jan 2015 22:44:08 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so8462239wiv.2 for ; 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: <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: Subject: Re: Atheros AR9565 detected, not working From: Adrian Chadd To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > To: Anthony Jenkins > Cc: Anthony Jenkins ; "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 > 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 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" >>>> >> > >