renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-26 14:14:01 +08:00
Code

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

Browse Source 
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
Pavel Roskin 2006-04-07 04:11:00 -04:00 committed by John W. Linville
parent b884c872fa
commit dc3437d205
4 changed files with 22 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
drivers/net/wireless/orinoco_nortel.c
View File

@ -3,7 +3,6 @@
* 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>
@ -57,7 +56,7 @@
/*
* 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
*
@ -68,7 +67,7 @@ static int orinoco_nortel_cor_reset(struct orinoco_private *priv)
{
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);
@ -126,7 +125,7 @@ static int orinoco_nortel_hw_init(struct orinoco_pci_card *card)
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);

69
drivers/net/wireless/orinoco_pci.c
View File

@ -1,11 +1,11 @@
/* orinoco_pci.c
*
* Driver for Prism II devices that have a direct PCI interface
* (i.e., not in a Pcmcia or PLX bridge)
* 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.
*
* Specifically here we're talking about the Linksys WMP11
*
* 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>
*
@ -41,54 +41,6 @@
* 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 ": "
@ -102,11 +54,12 @@
#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. */
@ -115,7 +68,7 @@
#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
*
@ -133,7 +86,7 @@ static int orinoco_pci_cor_reset(struct orinoco_private *priv)
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);

42
drivers/net/wireless/orinoco_plx.c
View File

@ -3,7 +3,7 @@
* 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>
*
@ -30,38 +30,18 @@
* 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
@ -71,7 +51,7 @@
* within the PCI memory space. Write 0x41 to the COR register to
* enable I/O mode and to select level triggered interrupts. To
* confirm you actually succeeded, read the COR register back and make
* sure it actually got set to 0x41, incase you have an unexpected
* sure it actually got set to 0x41, in case you have an unexpected
* card inserted.
*
* Following that, you can treat the second PCI I/O address space (the
@ -101,16 +81,6 @@
* 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"

16
drivers/net/wireless/orinoco_tmd.c
View File

@ -26,25 +26,13 @@
* 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"
*/