ipw2200-linux3 Files

README for modified ipw2200 code.

For kernel version >= 3.2.57, maybe somewhere up from 2.6.22 as well.

Tested on 3.2.57 from debian

For kernels >= 2.6.20 to somewhere about 2.6.22 use the old code, this
one won't work.
For kernels prior to 2.6.20 use the very old code, other won't work.

This has not been tested on SMP machines.
This has not been tested on preemptible kernels.
This has not been tested on anything other than a Dell Inspiron 1300 with an
 Intel PRO/Wireless 2200BG.

Use At Your Own Risk.

For the amount of feedback this work is all pure proof-of-concept :/.


USAGE

Check the following:

~ # cd /sys/bus/pci/drivers/ipw2200/0000:02:03.0
/sys/bus/pci/drivers/ipw2200/0000:02:03.0 $ cat device
0x4220
/sys/bus/pci/drivers/ipw2200/0000:02:03.0 $ cat subsystem_device
0x2722

These two are the identifiers that my code uses to decide about switching on
the LED code.  If your values are the same it should be safe to use my modified
code.  Otherwise you'll have to experiment and adapt the settings in ipw2200.c.

You have to have a kernel build tree at hand.  That means you'll have to have
a kernel source directory and appropriate kernel configuration (usually:
/usr/src/<YourSourceDir>/.config) and dependency information of your
current kernel -- otherwise the compiler won't know if f.i. you have some
dependencies built in or compiled as modules and such.

If you don't have such a thing, create it -- by configuring and compiling your
own kernel -- it's exciting!  You might have to download a linux-source package
to do this.

`recent kernel' in the text below refers to 3.2.57, but might also cover
versions higher than 2.6.22 or thereabouts.

Kernel configuration:
It's advisable to activate at least the CONFIG_MAGIC_SYSRQ (s. below) and to
use a journalling filesystem (such as ext3 or reiser), to be on the safe side.
Modules are part of the kernel and if something doesn't work out you can end up
with quite undesirable results -- like a complete system hang, where even sysrq
can't help you, therefore use a safe filesystem.

You should select the following, found in
`Networking support -> Wireless LAN': libipw

Nota bene:
When playing with kernels you should always have a working kernel available as
fallback to boot if anything goes wrong.  You have been warned.

Finally you'll need the firmware, which is usually not shipped with the Linux
source.

It used to be available from the Intel website <www.intel.com>.  Nowadays one
is redirected to sourceforge, where on June 1st 2014 the link to the download
server (bughost.org) had no address on my nameserver.

But you can search the internet for ipw2200-fw-3.0.tgz, many findings offer
the firmware that the module produced with this code works with.
The contents of the tarfile are to be placed in /lib/firmware/.

In case you have to compile your kernel first, you can of course just place
the two files (ipw2200.c, ipw2200.h) into your linux source tree at the
appropriate place (back up original code just in case):

/usr/src/<YourSourceDir>/drivers/net/wireless/ipw2x00/

Otherwise (if you don't want to compile your kernel -- you'll still need a
kernel build tree) just create a directory for the code  (e.g. ~/ipw), put
the two source files there (ipw2200.c and ipw2200.h) and create a Makefile
there with the text editor of your choice:

#==========================================================#
        obj-m := ipw2200.o
	KERNELDIR ?= /lib/modules/<YourKernelDir>/build
all:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

#=====================End Of File==========================#

With a recent kernel you will then have to symlink ipw.h and libipw.h to your
ipw directory:
~/ipw # ln -s /usr/src/<YourSourceDir>/drivers/net/wireless/ipw2x00/ipw.h
~/ipw # ln -s /usr/src/<YourSourceDir>/drivers/net/wireless/ipw2x00/libipw.h

After that, you can simply issue:
~/ipw # make

For all this hard work you'll obtain a file named ipw2200.ko, which is the new
(modified) module.

For the following steps you'll have to obtain root privileges.

Back up the original drivers in your module directory (for instance by simply
renaming it to *.ko.orig)
/lib/modules/<YourKernelVersion>/kernel/drivers/net/wireless/ipw2x00/

then copy the file from your ipw directory to the module directory.

Depending on your distribution and settings, you might have to rmmod the
original module before playing with the new one.

Read the footnote about sysrq if you don't already know what that is.

Then modprobe your new module first and watch your LEDs.

Good luck and have fun.

As is with free and open_source software, the risk is with you.
Not me, not Intel, only you.

It works on my machine, to my satisfaction.


MOTIVATION

Bloody firmware.  It's like experimenting with a black box!

Logic would suggest that the LED primarily is to indicate if the device is
switched on or off.  Secondly it could flash while the device is unassociated
(not a priority).  Thirdly it could flash in different ways depending on
circumstances (not a priority).

The LED should really be hardwired IMHO.  Otherwise you'll never know is your
device switched on or off while the module is not loaded.  Which latter needn't
always be the case.

With the original driver loaded with parameter led=1 the LED doesn't react
before switching radio first on, then off, then back on again.  After that it
doesn't go off before unloading the module, no matter if the radio is switched
on or not.

As I've found that I'm not the only user being annoyed or perplexed by this
behaviour (google is our witness), I decided to give it a try.  Alas, I'm
neither a kernel hacker nor even a proficient C programmer.  And I don't
dispose of lots of different hardware, so no testing on (real) SMP systems or
different Intel Wireless NICs has been performed.  You might have to adapt
the PCI_IDS in ipw_led_init (ipw2200.c) to your subsystem_device's.

Whoever feels inclined to adapt this code to other platforms than the i386 it
has been tested on, please do.  Though I don't think there'll be many SMP
machines or sparcs or alphas out there equipped with an Intel PRO/Wireless
2200BG NIC ;).

The original driver decides on the nic_type reported by the firmware, which
parts of the LED code to use, if any.  However the previous version of the
firmware reported my nic_type as 1 while the chip was switched on, and 0 while
switched off.  This has changed now with a newer firmware, now it always says
'TYPE: 0'.

This inconsistency in combination with the code claiming that type 1 has
several LEDs instead of only one like mine made me believe there was some
confusion in the intel household.

I have changed a few strategic aspects and tried to simplify the code a little.

Intel folk seem to have done quite a bit of work on associated code to adapt to
new kernel structures.  Also they have redefined some of their code into new
libraries like libipw and lib80211.

And due to kernel changes it isn't necessary anymore to load all involved
modules manually (if you choose appropriate kernel config options that is).

However Intel folk haven't done ANY changes regarding the LED code in the last
eight years.  But they've added quite a lot of le_to_cpu and cpu_to_le things,
some of which are completely contrary to former settings.  May those settings
have been inadequate or are they just eyecandy, I don't know, at least for a
driver which I suppose is not in broad use on platforms other than i.86, if at
all.

If Intel were as negligent about their CPUs as they seem to be about their
open source software they'd been long out of business (IMHO).

===========================================================================


FEATURES:
Added a sysfs entry for en|disable, soft_off.  Echo 1 > soft_off to
soft_switch_off the module, echo 0 > soft_off to soft_switch_on.  I don't
really know if anybody would need such a feature, but now it's there.

Added different LED states:
While switched off (so called RF_KILL switch), LED off.
When switched on, while unassociated: fast blink, while associated: solid.
When soft_switched off, slow blink.


LOCKING:
I've tested this with an SMP-kernel, but only on a UP machine, and sometimes
during development got locking errors.  These might be due to bugs (?) in
the lock-debugging code, I don't know.


ED <enno doT vet At gmx Dot net> 31 Dec 2009
(The new code for 3.2.x has not been tested on SMP-kernel.)

===========================================================================
Footnotes:

¹) SYSRQ: If you compile the 'magic' sysrq into the kernel, you can avoid
severe crashes (even if you don't see the commands' output) by using the keys
advertised in kernel-tree/Documentation/sysrq.txt.

Usually this means you can sync your disk[s] with key-combination Alt+SysRq+S,
unmount them with Alt+SysRq+U, reboot with Alt+SysRq+R.

This should save you from having to boot from not cleanly unmounted
filesystems.


²) `uname -r' will tell you your current kernel version.  Alternatively you can
look it up in /proc/sys/kernel/osrelease.