From owner-freebsd-wireless@FreeBSD.ORG Tue Dec 23 18:06:58 2014 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 E5685B64 for ; Tue, 23 Dec 2014 18:06:58 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 706D92A65 for ; Tue, 23 Dec 2014 18:06:58 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so11558436wiw.16 for ; Tue, 23 Dec 2014 10:06:56 -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=96nJKmhld2C++leruTjmytjXxvDBkkexY5ysVBLiq9M=; b=BD2NxwN+CnoLM3guZBAm1butbeoNFDSMdNOZ/Q6Ozg28axo44jIcRNA2yySH0v42UJ STm6FaxH4wboHPdF1bo0nQYtrO5WV99fAlLY/vbfweaNfPR0vF8M97EQvya9QW5719p/ EABE/hjnPQ2bg/2UiYhCUTX3G/5XDSqk2LZbG8GabiZvlwp0aW2sCwBxx59QyuswzYaE I7xg43bFaxgP9vr2DEeMUoaHYc76OtXj3E4L7xHQdXY1ofNgdlIRdBmsESqKy02pBJAt QeEjws7AOVwPIE2WFRTqhriy88zRQkVtjAlup3lffaJRBo1the4dxNyoCaY8/KHEC/g8 SUwg== MIME-Version: 1.0 X-Received: by 10.180.7.198 with SMTP id l6mr43836442wia.26.1419358016820; Tue, 23 Dec 2014 10:06:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Tue, 23 Dec 2014 10:06:56 -0800 (PST) In-Reply-To: References: <433678684.160603.1419257025708.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> <54987366.6060803@yahoo.com> <5498780B.90704@yahoo.com> <5498944C.4040706@yahoo.com> Date: Tue, 23 Dec 2014 10:06:56 -0800 X-Google-Sender-Auth: -r1hYct-yhDWlTtG4DnWsBlmQZ4 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: Tue, 23 Dec 2014 18:06:59 -0000 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