[PATCH] orinoco: further comment cleanup in the PCI drivers

 * Driver for Prism II devices which would usually be driven by orinoco_cs,

 * but are connected to the PCI bus by a PCI-to-PCMCIA adapter used in

 * Nortel emobility, Symbol LA-4113 and Symbol LA-4123.

 * but are connected to the PCI bus by a Nortel PCI-PCMCIA-Adapter. 

 *

 * Copyright (C) 2002 Tobias Hoffmann

 *           (C) 2003 Christoph Jungegger <disdos@traum404.de>

/*

 * Do a soft reset of the PCI card using the Configuration Option Register

 * Do a soft reset of the card using the Configuration Option Register

 * We need this to get going...

 * This is the part of the code that is strongly inspired from wlan-ng

 *

{

	struct orinoco_pci_card *card = priv->card;

	/* Assert the reset until the card notice */

	/* Assert the reset until the card notices */

	iowrite16(8, card->bridge_io + 2);

	ioread16(card->attr_io + COR_OFFSET);

	iowrite16(0x80, card->attr_io + COR_OFFSET);

		return -EBUSY;

	}

	/* Set the PCMCIA COR-Register */

	/* Set the PCMCIA COR register */

	iowrite16(COR_VALUE, card->attr_io + COR_OFFSET);

	mdelay(1);

	reg = ioread16(card->attr_io + COR_OFFSET);

/* orinoco_pci.c

 * 

 * Driver for Prism II devices that have a direct PCI interface

 * (i.e., not in a Pcmcia or PLX bridge)

 *

 * Specifically here we're talking about the Linksys WMP11

 * Driver for Prism 2.5/3 devices that have a direct PCI interface

 * (i.e. these are not PCMCIA cards in a PCMCIA-to-PCI bridge).

 * The card contains only one PCI region, which contains all the usual

 * hermes registers, as well as the COR register.

 *

 * Current maintainers (as of 29 September 2003) are:

 * Current maintainers are:

 * 	Pavel Roskin <proski AT gnu.org>

 * and	David Gibson <hermes AT gibson.dropbear.id.au>

 *

 * under either the MPL or the GPL.

 */

/*

 * Theory of operation...

 * -------------------

 * Maybe you had a look in orinoco_plx. Well, this is totally different...

 *

 * The card contains only one PCI region, which contains all the usual

 * hermes registers.

 *

 * The driver will memory map this region in normal memory. Because

 * the hermes registers are mapped in normal memory and not in ISA I/O

 * post space, we can't use the usual inw/outw macros and we need to

 * use readw/writew.

 * This slight difference force us to compile our own version of

 * hermes.c with the register access macro changed. That's a bit

 * hackish but works fine.

 *

 * Note that the PCI region is pretty big (4K). That's much more than

 * the usual set of hermes register (0x0 -> 0x3E). I've got a strong

 * suspicion that the whole memory space of the adapter is in fact in

 * this region. Accessing directly the adapter memory instead of going

 * through the usual register would speed up significantely the

 * operations...

 *

 * Finally, the card looks like this :

-----------------------

  Bus  0, device  14, function  0:

    Network controller: PCI device 1260:3873 (Harris Semiconductor) (rev 1).

      IRQ 11.

      Master Capable.  Latency=248.  

      Prefetchable 32 bit memory at 0xffbcc000 [0xffbccfff].

-----------------------

00:0e.0 Network controller: Harris Semiconductor: Unknown device 3873 (rev 01)

        Subsystem: Unknown device 1737:3874

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-

        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 248 set, cache line size 08

        Interrupt: pin A routed to IRQ 11

        Region 0: Memory at ffbcc000 (32-bit, prefetchable) [size=4K]

        Capabilities: [dc] Power Management version 2

                Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME+

                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

-----------------------

 *

 * That's all..

 *

 * Jean II

 */

#define DRIVER_NAME "orinoco_pci"

#define PFX DRIVER_NAME ": "

#include "orinoco.h"

#include "orinoco_pci.h"

/* All the magic there is from wlan-ng */

/* Magic offset of the reset register of the PCI card */

/* Offset of the COR register of the PCI card */

#define HERMES_PCI_COR		(0x26)

/* Magic bitmask to reset the card */

/* Bitmask to reset the card */

#define HERMES_PCI_COR_MASK	(0x0080)

/* Magic timeouts for doing the reset.

 * Those times are straight from wlan-ng, and it is claimed that they

 * are necessary. Alan will kill me. Take your time and grab a coffee. */

#define HERMES_PCI_COR_BUSYT	(500)		/* ms */

/*

 * Do a soft reset of the PCI card using the Configuration Option Register

 * Do a soft reset of the card using the Configuration Option Register

 * We need this to get going...

 * This is the part of the code that is strongly inspired from wlan-ng

 *

	unsigned long timeout;

	u16 reg;

	/* Assert the reset until the card notice */

	/* Assert the reset until the card notices */

	hermes_write_regn(hw, PCI_COR, HERMES_PCI_COR_MASK);

	mdelay(HERMES_PCI_COR_ONT);

 * Driver for Prism II devices which would usually be driven by orinoco_cs,

 * but are connected to the PCI bus by a PLX9052.

 *

 * Current maintainers (as of 29 September 2003) are:

 * Current maintainers are:

 * 	Pavel Roskin <proski AT gnu.org>

 * and	David Gibson <hermes AT gibson.dropbear.id.au>

 *

 * other provisions required by the GPL.  If you do not delete the

 * provisions above, a recipient may use your version of this file

 * under either the MPL or the GPL.

 * Caution: this is experimental and probably buggy.  For success and

 * failure reports for different cards and adaptors, see

 * orinoco_plx_id_table near the end of the file.  If you have a

 * card we don't have the PCI id for, and looks like it should work,

 * drop me mail with the id and "it works"/"it doesn't work".

 *

 * Note: if everything gets detected fine but it doesn't actually send

 * or receive packets, your first port of call should probably be to

 * try newer firmware in the card.  Especially if you're doing Ad-Hoc

 * modes.

 *

 * The actual driving is done by orinoco.c, this is just resource

 * allocation stuff.  The explanation below is courtesy of Ryan Niemi

 * on the linux-wlan-ng list at

 * http://archives.neohapsis.com/archives/dev/linux-wlan/2001-q1/0026.html

 *

 * The PLX9052-based cards (WL11000 and several others) are a

 * different beast than the usual PCMCIA-based PRISM2 configuration

 * expected by wlan-ng.  Here's the general details on how the WL11000

 * PCI adapter works:

 * Here's the general details on how the PLX9052 adapter works:

 *

 * - Two PCI I/O address spaces, one 0x80 long which contains the

 * PLX9052 registers, and one that's 0x40 long mapped to the PCMCIA

 * slot I/O address space.

 *

 * - One PCI memory address space, mapped to the PCMCIA memory space

 * - One PCI memory address space, mapped to the PCMCIA attribute space

 * (containing the CIS).

 *

 * After identifying the I/O and memory space, you can read through

 * the memory space to confirm the CIS's device ID or manufacturer ID

 * to make sure it's the expected card.  qKeep in mind that the PCMCIA

 * Using the later, you can read through the CIS data to make sure the

 * card is compatible with the driver. Keep in mind that the PCMCIA

 * spec specifies the CIS as the lower 8 bits of each word read from

 * the CIS, so to read the bytes of the CIS, read every other byte

 * (0,2,4,...). Passing that test, you need to enable the I/O address

 * that, I've hot-swapped a number of times during debugging and

 * driver development for various reasons (stuck WAIT# line after the

 * radio card's firmware locks up).

 *

 * Hope this is enough info for someone to add PLX9052 support to the

 * wlan-ng card. In the case of the WL11000, the PCI ID's are

 * 0x1639/0x0200, with matching subsystem ID's. Other PLX9052-based

 * manufacturers other than Eumitcom (or on cards other than the

 * WL11000) may have different PCI ID's.

 *

 * If anyone needs any more specific info, let me know. I haven't had

 * time to implement support myself yet, and with the way things are

 * going, might not have time for a while..

 */

#define DRIVER_NAME "orinoco_plx"

 * other provisions required by the GPL.  If you do not delete the

 * provisions above, a recipient may use your version of this file

 * under either the MPL or the GPL.

 * Caution: this is experimental and probably buggy.  For success and

 * failure reports for different cards and adaptors, see

 * orinoco_tmd_id_table near the end of the file.  If you have a

 * card we don't have the PCI id for, and looks like it should work,

 * drop me mail with the id and "it works"/"it doesn't work".

 *

 * Note: if everything gets detected fine but it doesn't actually send

 * or receive packets, your first port of call should probably be to

 * try newer firmware in the card.  Especially if you're doing Ad-Hoc

 * modes.

 *

 * The actual driving is done by orinoco.c, this is just resource

 * allocation stuff.

 *

 * This driver is modeled after the orinoco_plx driver. The main

 * difference is that the TMD chip has only IO port ranges and no

 * memory space, i.e.  no access to the CIS. Compared to the PLX chip,

 * the io range functionalities are exchanged.

 * difference is that the TMD chip has only IO port ranges and doesn't

 * provide access to the PCMCIA attribute space.

 *

 * Pheecom sells cards with the TMD chip as "ASIC version"

 */