From owner-freebsd-wireless@FreeBSD.ORG Fri Jan 9 21:00:18 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 F06727EF for ; Fri, 9 Jan 2015 21:00:18 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 786A0CEB for ; Fri, 9 Jan 2015 21:00:18 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so10183492wgh.4 for ; Fri, 09 Jan 2015 13:00:17 -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:content-transfer-encoding; bh=k5e8ArzP9g/+98Ixcc5mwa/gvC2VUyeB7KyHgt3mOVA=; b=mp62+31e9SsnwtJapRoxR18hs3ckS8esLbwJg06YGDcvTmGU8olJxpU4wAUxTuqUTJ uahv9akm02NEHKVN0rP51tP/jb0xlLrn5sFHLaE5A5k2EfTXOW5k3h9gN3pU40faDirD x41tyjlaidJeTlIWUDtpTgZSE7oA3Yy7oH0bHY8MmXdiItk9rpBRUd5ZSKfCztjJ3btz NU1Kgj+68A3FT0PPzZROAsB0zfh2XVKKZSINojyvzWSYUNsoPHuox7+rJIducp89H/z1 fHz7Bb0+3IKvCrYzK+JP9tMaQ+GmeCutv1qZKTfjnq2ET6LC3KlzYfo7SzEXYDLtQlUZ z1fQ== MIME-Version: 1.0 X-Received: by 10.180.20.6 with SMTP id j6mr8321535wie.59.1420837216040; Fri, 09 Jan 2015 13:00:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Fri, 9 Jan 2015 13:00:15 -0800 (PST) In-Reply-To: <54AE1136.8000706@att.net> References: <433678684.160603.1419257025708.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> <54987366.6060803@yahoo.com> <5498780B.90704@yahoo.com> <5498944C.4040706@yahoo.com> <54AD3DF5.1070905@att.net> <54AE1136.8000706@att.net> Date: Fri, 9 Jan 2015 13:00:15 -0800 X-Google-Sender-Auth: 6X9872f5xN923vofL0q0gmlAd7g Message-ID: Subject: Re: Atheros AR9565 detected, not working From: Adrian Chadd To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 09 Jan 2015 21:00:19 -0000 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 > > 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 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" >>> >