On Saturday 03 October 2009 00:25:47 Joerg Albert wrote: > On 10/02/2009 01:45 PM, Malte Gell wrote: > > Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> wrote > > > >>> The Netgear (WN?) 111 even only has one blue LED as far as I know. > >> the question is if it's the only device with this deficit, or not? > > > > Is it feasable to write to the well known stick makers (Netgear, AVM, > > Belkin,Asus...) and just ask them? > > After looking into staging/otus/80211core/ledmgr.c, which has functions > zfLedCtrlType1,2,3 for: > - "Traditional single-LED state" > - "Netgear Dual-LED state" > - "Netgear Single-LED state" > > (althrough they are not used there, as noone initializes wd->ledStruct.LEDCtrlType correctly) On Windows platforms this setting is initialized by the Driver .inf file: (ref: http://ftp.dlink.ru/pub/Wireless/DWA-160/Drivers/Rev.A-DWA-160_S0009/Drivers/Vista32/arusb_lh.inf ) [NTGR9010.reg] HKR, Ndi, Service, 0, "WNDA3100" HKR, Ndi\Interfaces, UpperRange, 0, "ndis5" HKR, Ndi\Interfaces, LowerRange, 0, "wlan,ethernet" [...] HKR,, DfsChDisable, 0, 1 HKR,, LEDCtrlType, 0, 2 vs. [NTGR9001.reg] HKR, Ndi, Service, 0, "WN111v2" HKR, Ndi\Interfaces, UpperRange, 0, "ndis5" HKR, Ndi\Interfaces, LowerRange, 0, "wlan,ethernet" [...] HKR,, DfsChDisable, 0, 1 HKR,, LEDCtrlType, 0, 3 the situation is different for AVM: there is not any reference of LEDCtrlType in any of AVM's inf files, but the LEDCtrlType string does turn up in the driver file. > I guess there is a way to determine the number of LED in a device from the EEPROM. > I really doubt that Netgear would built different drivers/firmwares > (if they built any instead of getting them from Atheros) > for both WNDA3100 and WN111v2. > > hal/hpmain.c, line 2322: > #define ZM_SEEPROM_HARDWARE_TYPE_OFFSET (0x1374) > > the value from the above address is retrieved in rsp[5] and processed in > > hal/hprw.c, lines 601f. > wd->ledStruct.ledMode[0] = (u16_t)(rsp[5]&0xffff); > wd->ledStruct.ledMode[1] = (u16_t)(rsp[5]>>16); > > If the bits of ledMode[] are explained in 80211/ledmgr.c, lines 34ff., > Atheros provided a generic way for vendors to program LED behaviour > via the EEPROM and Netgear got some extra handling in the driver > (if otus is close the windows driver). nice catch! On Saturday 03 October 2009 01:03:28 Joerg Albert wrote: > Hi, > > could anyone with a WN111v2 (or any other device with one LED only) > apply the patch below and look into syslog for the value of "hwtype"? > > I get 22212221 for an AVM stick (057c:8401) and 22211111 for a Netgear WNDA3100 (0846:9010). > > Thanks, > Joerg. > > Netgear WNDA3100: LedMode[0] = 0x1111 => (blue LED) Bit 0 = 1 => Power-on state: On Bit 6 = 0 => Connect state Bit 4 = 1 => always on (~ assoc/link LED?) Ton = 1 Toff = 1 LedMode[1] = 0x2221 => (orange LED) Bit 0 = 1 => Power-on state: On Bit 6 = 0 => Connect state Bit 5 = 1 => Idle off, acitve on (~ traffic/tx LED?) Ton = 2 Toff = 2 this looks promising. The setting here does indeed match the current driver behavior! AVM: LedMode[0] = 0x2221 => (red LED?) Bit 0 = 1 => Power-on state: On Bit 6 = 0 => Connect state Bit 5 = 1 => Idle off, acitve on (~ traffic/tx LED?) Ton = 2 Toff = 2 LedMode[1] = 0x2221 => (green LED?) Bit 0 = 1 => Power-on state: On Bit 6 = 0 => Connect state Bit 5 = 1 => Idle off, acitve on (~ traffic/tx LED?) Ton = 2 Toff = 2 hmm, by this definition both LEDs are assigned as "traffic indicators". This can not be right?! I did expect (based on Malte's description of the Windows driver) something more like: 0x11112221. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
