From owner-freebsd-wireless@FreeBSD.ORG Fri Jan 23 20:45:52 2015 Return-Path: Delivered-To: wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E273705 for ; Fri, 23 Jan 2015 20:45:52 +0000 (UTC) Received: from nm8-vm0.bullet.mail.ne1.yahoo.com (nm8-vm0.bullet.mail.ne1.yahoo.com [98.138.91.23]) (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 2283EF52 for ; Fri, 23 Jan 2015 20:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1422045944; bh=5OQR7fnXs1fHMCyZp7xfLueYSS+Bxs9QqJQwnyy8osQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=pO1URYWzPtL0jQyf4zsTbvPjZIvAdcGLWP68KaG7xuRDzwGhZcZPj0wEToMYwdqoKaHbmWGlZm4Sjq9HifYdHpdCm2yUNX2fVruD7AR8PTDmohWlZV6Fps7rm0iDuyy0mdLJgy3Y68lnjZgHZKRVy+5xVi/b2fkpI09vNeQdy+g= Received: from [98.138.101.132] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jan 2015 20:45:44 -0000 Received: from [98.138.84.39] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 23 Jan 2015 20:45:44 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 23 Jan 2015 20:45:44 -0000 X-Yahoo-Newman-Id: 572981.85222.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oP1oCnMVM1lDfbui60bEdscw4Ncsk0r5RcFAxL69MxKuIlB R6XOqOzdKz8jeKU7Y.UQyrxScuS7E.pHamEHt_GE44GJd5PqHxI_0ZYxcW4N cXMbi2ocLcjuVIBVqh8y1BmVNi5B00wHU_dAYukjxDOrLWhrJGO0bmJJGEI8 We4RheQO0cvmNVSYgCinP93LPAOwfQQJosZjqWsBb3dqYTChM91J5.jRIWPC 0WzhVjuD3NNqtOGUOVuA9PD298CjoRmuBUhYYwdd_dInsDq9RsCDZjof8mRR FVsoEXwxRCqArOHUQhDDaWUdMd4IcuZlg0iqzCLhCj_gIrOIfVbIDkLiVPqb Q9Z8Bm0Qxz9uxdOkw_pgb15NeOvmZrw11QEh_GZxZ2AsAtwCuB0UrRXkBnUr gtQNAQ.i8Bqv_1Inw6ZWdpDXfslw5.0RT70nh4MAuO0lPAPZzxvC_7.An88z BOuiijLeMU4tacb1HNUIrJbIQuhuU_lH50XzeECTSDHHNvov35.TBOQgIvo3 l.tWcEldJSZvlYeV.ndCAHS2EFS5wRuY.LObRtutIZS_ixl6g X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <54C2B2F7.3060308@att.net> Date: Fri, 23 Jan 2015 15:45:43 -0500 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Atheros AR9565 detected, not working References: <284932058.303050.1420924294011.JavaMail.yahoo@jws10628.mail.bf1.yahoo.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080603060005030405010209" Cc: Anthony Jenkins , "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: Fri, 23 Jan 2015 20:45:52 -0000 This is a multi-part message in MIME format. --------------080603060005030405010209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here's a patch that works on my laptop's AR9565 - it just allows GPIO BIT_11 accesses. No idea why that works; I thought I discovered BIT_8 was the rfkill bit. I tried allowing both BIT_11 /and/ BIT_8, but that doesn't work (wpa_supplicant(8) can never authenticate). May dig further, but I'm kinda swamped with stuff. I can conditionally allow BIT_11 GPIOs if the device is an AR9565... should I do that? Why/how does the Atheros driver emit invalid GPIO bit controls for a device? In other words, if my Atheros 123456 chip wants to do XXX, how does that translate to a GPIO bit access that needs to be blocked in the low-level GPIO functions? Yet another way to put it, what's that blocking logic in ar9300_gpio.c there for? Thanks, Anthony On 01/10/15 17:44, Adrian Chadd wrote: > 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" >>>>> >> --------------080603060005030405010209 Content-Type: text/x-patch; name="ath_allow_gpio_11.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ath_allow_gpio_11.patch" Index: sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c =================================================================== --- sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c (revision 277102) +++ sys/contrib/dev/ath/ath_hal/ar9300/ar9300_gpio.c (working copy) @@ -162,7 +162,6 @@ HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins); if ((gpio == AR9382_GPIO_PIN_8_RESERVED) || - (gpio == AR9382_GPIO_PIN_11_RESERVED) || (gpio == AR9382_GPIO_9_INPUT_ONLY)) { return AH_FALSE; @@ -348,7 +347,6 @@ HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins); if ((gpio == AR9382_GPIO_PIN_8_RESERVED) || - (gpio == AR9382_GPIO_PIN_11_RESERVED) || (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM)) { return AH_FALSE; @@ -378,7 +376,6 @@ { HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins); if ((gpio == AR9382_GPIO_PIN_8_RESERVED) || - (gpio == AR9382_GPIO_PIN_11_RESERVED) || (gpio == AR9382_GPIO_9_INPUT_ONLY)) { return AH_FALSE; @@ -397,8 +394,7 @@ { u_int32_t gpio_in; HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins); - if ((gpio == AR9382_GPIO_PIN_8_RESERVED) || - (gpio == AR9382_GPIO_PIN_11_RESERVED)) + if ((gpio == AR9382_GPIO_PIN_8_RESERVED)) { return 0xffffffff; } @@ -453,7 +449,6 @@ HALASSERT(gpio < AH_PRIVATE(ah)->ah_caps.halNumGpioPins); if ((gpio == AR9382_GPIO_PIN_8_RESERVED) || - (gpio == AR9382_GPIO_PIN_11_RESERVED) || (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM)) { return; @@ -549,8 +544,7 @@ if (AH_PRIVATE(ah)->ah_devid == AR9300_DEVID_AR9380_PCIE) { mask = (1 << AR9382_MAX_GPIO_PIN_NUM) - 1; - mask &= ~(1 << AR9382_GPIO_PIN_8_RESERVED | - 1 << AR9382_GPIO_PIN_11_RESERVED); + mask &= ~(1 << AR9382_GPIO_PIN_8_RESERVED); } return mask; } @@ -562,8 +556,7 @@ if (AH_PRIVATE(ah)->ah_devid == AR9300_DEVID_AR9380_PCIE) { invalid = ~((1 << AR9382_MAX_GPIO_PIN_NUM) - 1); - invalid |= 1 << AR9382_GPIO_PIN_8_RESERVED | - 1 << AR9382_GPIO_PIN_11_RESERVED; + invalid |= 1 << AR9382_GPIO_PIN_8_RESERVED; } if (mask & invalid) { ath_hal_printf(ah, "%s: invalid GPIO mask 0x%x\n", __func__, mask); --------------080603060005030405010209--