[Acx100-devel] interrogate debugging: call for testing

[Denis V. <vd...@il...>]

What we have now is rather abysmal:

#define ACX1xx_IE_MEMORY_MAP                    0x0008  /* huh? */
#define ACX100_IE_SSID                          0x0008  /* huh? */
...
#define ACX1xx_IE_MEMORY_MAP_LEN                        0x28
#define ACX100_IE_SSID_LEN                              0x20

etc...

So do we use 0x20, or 0x28??? Code currently does not
distinguish acx100, acx100usb and acx111 whed doing interrogate
or configure, but they are subtly different in length
and structure.

I developed a little tool to help collecting info on what
really firmware provides for us. Will appear in tomorrow's
tarball, or just grab it at
http://195.66.192.167/linux/acx_patches/tomorrow.tar.bz2

Define this to 1 in acx_config.h:

/* 0 - normal mode */
/* 1 - development/debug: probe for IEs on modprobe */
#define CMD_DISCOVERY 0

Then build the driver and modprobe debug=0xffff. You will hit this:

...
        printk("acx_pci module " WLAN_RELEASE " loaded successfully\n");
        result = OK;

#if CMD_DISCOVERY
        great_inquisistor(priv);
#endif
...
#if CMD_DISCOVERY
void
great_inquisistor(wlandevice_t *priv)
{
        static struct {
                u16     type ACX_PACKED;
                u16     len ACX_PACKED;
                /* 0x200 was too large here: */
                u8      data[0x100 - 4] ACX_PACKED;
        } ie;
        u16 type;

        FN_ENTER;

        /* 0..0x20, 0x1000..0x1020 */
        for (type = 0; type <= 0x1020; type++) {
                if (type == 0x21)
                        type = 0x1000;
                ie.type = cpu_to_le16(type);
                ie.len = cpu_to_le16(sizeof(ie) - 4);
                acx_s_issue_cmd(priv, ACX1xx_CMD_INTERROGATE, &ie, sizeof(ie));
        }
        FN_EXIT0;
}
#endif

You end up with largish debug log where you will see every
IE being interrogated. Some fail with "Invalid IE", some
with "Write only". The rest return interesting data:
length and contents of IE. This is what we are after.

I already did it for my hardware. See acx_struct.h,
"Interrogate/Configure cmd constants". I still use old
semi-buggy defs for driver (just reformatted them for sanity),
and placed my device's results in #if 0 block.

Let's take a look:

/* Experimentally obtained on PCI acx111 Xterasys XN-2522g, fw 1.2.1.34
** -1 means that fw returned 'invalid IE'
** 0400 0800 nnnn... are test read contents: u16 type, u16 len, data
** (AA are poison bytes marking bytes not written by fw) */
...
/* said to have len:1 (not true, actually returns 12 bytes): */
DEF_IE(111_IE_RADIO_BAND,       0x0007, 12); /* 07000C00 AAAA1F00 FF03AAAA AAAAAAAA */

whoever said that this is one byte 802.11g/a flag - lied. It's something else.

/* said to have len:4, but gives INVAL on read: */
DEF_IE(111_IE_SCAN_STATUS,      0x0009, -1);

more lies

/* said to have len:4, but in fact returns 8: */
DEF_IE(111_IE_MAX_USB_XFR,      0x0017, 8); /* 17000800 00014000 00000000 */

previusly unknown IE

/* undoc but returns something: */
/* huh, fw indicates len=20 but uses 4 more bytes in buffer??? */
DEF_IE(111_IE_UNKNOWN_1A,       0x001A, 20); /* 1A001400 AA00AAAA 0000020F FF030000 00020000 00000007 04000000 */

undocumented IE with fw bug in len reporting!

I will be happy to get similar data from acx100 and acx100usb owners.
(AA poisoning is missing from usb code.)
--
vda