From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from duke.felloff.net ([216.126.196.34]) by ur; Fri Jul  1 06:27:27 EDT 2016
Message-ID: <1b7f4590bc4b19ce8253e6373f2ff7d9@felloff.net>
Date: Fri, 1 Jul 2016 12:27:19 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] Hardware woes
In-Reply-To: <CAG2UyHobLtN4TzWr8QZZeW4KezxYjK5C-oQizzz-AUiqDMEK6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: virtual deep-learning-aware scripting engine 

> 1. I've got one of these:
> http://www.canakit.com/raspberry-pi-wifi.html gathering dust on a
> shelf. The firmware in Linux is rt2870.bin (despite the chipset being
> 5390) and I noticed in /sys/src/9/pc/etherrt2860.c there's some code
> about 2870, so figured there's a chance it'll just work. I plugged it
> in and it's not even generating an event in /dev/usbevent. I know the
> USB port works, because it's the same one I used to copy the firmware
> into /lib/firmware. What would stop it from even noticing that the
> dongle was plugged in?

the etherrt2860.c is driver for a pci card. usb drivers run in userspace.
so would need to port the wifi stack to userspace and make a usb driver.

> 2. I decided to look into the difference between the iwm driver from
> OpenBSD (https://github.com/rpaulo/iwm/blob/master/driver/if_iwmreg.h)
> and iwl from 9front
> (http://www.9front.org/9front/sys/src/9/pc/etheriwl.c). From what I
> can tell, every register and offset I compared seemed to have the same
> format, so I'm tempted to just add the type to fwname[] and see what
> happens. If that works, it'll be better than being forced to have a
> usb port.. but I don't know how to figure out the ID for the type to
> add to the enum above it. I added a print statement to setfwinfo() and
> added ether0=type=iwl to my plan9.ini, but it doesn't seem to be
> making it there. Is there something else I need to do to force the
> driver or an easier way to probe the id?

see iwlpci() function:

		switch(pdev->did){
		default:
			continue;
		case 0x0084:	/* WiFi Link 1000 */
		case 0x4229:	/* WiFi Link 4965 */
		case 0x4230:	/* WiFi Link 4965 */
		case 0x4232:	/* Wifi Link 5100 */
		case 0x4236:	/* WiFi Link 5300 AGN */
		case 0x4237:	/* Wifi Link 5100 AGN */
		case 0x423d:	/* Wifi Link 5150 */
		case 0x423b:	/* PRO/Wireless 5350 AGN */
		case 0x0082:	/* Centrino Advanced-N 6205 */
		case 0x0085:	/* Centrino Advanced-N 6205 */
		case 0x422b:	/* Centrino Ultimate-N 6300 variant 1 */
		case 0x4238:	/* Centrino Ultimate-N 6300 variant 2 */
		case 0x08ae:	/* Centrino Wireless-N 100 */
		case 0x0083:	/* Centrino Wireless-N 1000 */
		case 0x0887:	/* Centrino Wireless-N 2230 */
		case 0x0888:	/* Centrino Wireless-N 2230 */
			break;
		}

the device type is read from pci config space Rev register:

		ctlr->type = (csr32r(ctlr, Rev) >> 4) & 0xF;

the differences are distinguished by that field, like
the firmware name is indexed by that:

		fw = readfirmware(fwname[ctlr->type]);

--
cinap