-
Notifications
You must be signed in to change notification settings - Fork 0
/
README-2.4
132 lines (107 loc) · 6.29 KB
/
README-2.4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
Notes about PCMCIA in the 2.4 kernel
When compiling the standalone PCMCIA package, the Configure script
decides whether or not to build any kernel modules by looking at the
value of the CONFIG_PCMCIA option in your kernel configuration. If
CONFIG_PCMCIA is enabled, then by default, no driver components are
built. If CONFIG_PCMCIA is disabled, then all the modules will be
built and installed. It is safe to compile the user tools (cardmgr,
cardctl, etc) in a PCMCIA package whose version number differs from
the PCMCIA version number in the kernel source tree. The kernel
PCMCIA header files take precedence over the ones included in the
PCMCIA package, if CONFIG_PCMCIA is enabled.
The following tables show the correspondence between PCMCIA client
driver names, and kernel configuration options.
Network drivers:
3c589_cs 3Com 3c589 CONFIG_PCMCIA_3C589
3c574_cs 3Com 3c574 CONFIG_PCMCIA_3C574
axnet_cs Asix AX88190 chipset CONFIG_PCMCIA_AXNET
fmvj18x_cs Fujitsu FMV-J18x CONFIG_PCMCIA_FMVJ18X
nmclan_cs New Media CONFIG_PCMCIA_NMCLAN
pcnet_cs NE2000 compatible CONFIG_PCMCIA_PCNET
smc91c92_cs SMC 91Cxx CONFIG_PCMCIA_SMC91C92
xirc2ps_cs Xircom 16-bit CONFIG_PCMCIA_XIRC2PS
ibmtr_cs IBM PCMCIA tokenring CONFIG_PCMCIA_IBMTR
ray_cs Aviator/Raytheon 2.4MHz CONFIG_PCMCIA_RAYCS
netwave_cs Xircom Netwave AirSurfer CONFIG_PCMCIA_NETWAVE
orinoco_cs Hermes chipset 802.11 CONFIG_PCMCIA_HERMES
wavelan_cs AT&T/Lucent Wavelan CONFIG_PCMCIA_WAVELAN
Character drivers:
serial_cs PCMCIA serial device CONFIG_PCMCIA_SERIAL_CS
SCSI low-level drivers:
aha152x_cs Adaptec AHA152X CONFIG_PCMCIA_AHA152X
qlogic_cs Qlogic CONFIG_PCMCIA_QLOGIC
fdomain_cs Future Domain CONFIG_PCMCIA_FDOMAIN
Other drivers:
ide-cs ATA/IDE devices CONFIG_BLK_DEV_IDECS
All CardBus drivers have been folded into their corresponding regular
PCI drivers using the new "hot plug PCI" interface. Here is a mapping
from old CardBus drivers to new hot plug drivers:
3c575_cb 3c59x 3c59x/3c90x/3x575 series CONFIG_VORTEX
tulip_cb tulip DECchip Tulip (dc21x4x) CONFIG_TULIP
epic_cb epic100 SMC EtherPower II CONFIG_EPIC100
serial_cb serial Standard/generic serial CONFIG_SERIAL
apa1480_cb aic7xxx Adaptec AIC7xxx SCSI CONFIG_SCSI_AIC7XXX
There are two drivers for Xircom CardBus cards:
xircom_tulip_cb Xircom Tulip-like CardBus CONFIG_PCMCIA_XIRTULIP
xircom_cb Xircom CardBus (new driver) CONFIG_PCMCIA_XIRCOM
Hot plug PCI drivers are not managed by cardmgr; they are managed by
the "hotplug" subsystem. See http://linux-hotplug.sourceforge.net for
information about this facility. When cardmgr sees a card that is
owned by a hot plug PCI driver, it will ignore that card. There will
be one beep when these cards are inserted/ejected, but they will be
identified only as a "CardBus hotplug device" in the log files.
Known problems and limitations:
o Some of the less widely used client drivers, like the memory card
drivers, have not been ported into the 2.4 driver tree yet.
o The yenta_socket driver does not have the /proc interface of the
i82365 driver, so the dump_exca and dump_cardbus tools do not work.
It actually has no built-in debugging aids at all.
o The kernel PCMCIA package cannot be configured to use PnP BIOS calls
for resource management. Recent kernels do have PnP BIOS support
but the "glue" hasn't been written.
o With the introduction of the Hot Plug PCI subsystem, CardBus drivers
now no longer act like other PCMCIA drivers; most obviously, they
don't interact with the PCMCIA device configuration scripts. These
devices are configured using the "hotplug" scripts.
Answers to some common questions:
Q: Are these two versions of PCMCIA both going to continue with active
development?
A: The kernel PCMCIA subsystem should be the focus for ongoing
development. The standalone pcmcia-cs drivers are still being
maintained but the focus has shifted from adding functionality,
towards just bug fixes.
Q: Which should I use / which is better? The kernel PCMCIA, or the
standalone PCMCIA?
A: The client drivers should generally behave the same. At this
point, most current distributions use the kernel PCMCIA subsystem,
and I recommend sticking with that unless you have a particular
need that is only met by the standalone drivers.
Q: What should I do as a driver developer?
A: I will not be including any significant new functionality in the
standalone PCMCIA package. In some cases it might still make sense
to develop contributed drivers for the standalone package first if
backwards compatibility with 2.2 kernels is useful.
Q: I'm using the kernel PCMCIA subsystem but want to use a driver that
isn't included in the kernel yet. Why can't I compile that driver
from the standalone PCMCIA package?
A: The Makefiles are set up to discourage this, mainly to prevent
people from trying combinations that don't make sense. Things in
the "modules" directory of the standalone package will not work
with the kernel PCMCIA subsystem. However, you can build client
drivers by doing a "make install" in either the "clients" or
"wireless" subdirectories after a normal "make config".
Q: Who is maintaining the kernel PCMCIA subsystem?
A: I am not playing a central role in maintaining the kernel modules
as I have with the standalone package. I have periodically updated
some of the core modules and client drivers with fixes from the
standalone package. Linus Torvalds wrote the yenta_socket driver
more or less from scratch and he has been maintaining that bit.
Jeff Garzik has been working on the hot plug PCI adaptations for
the tulip_cb, 3c575_cb, and epic_cb drivers.
Q: What about 2.5, 2.6, and beyond?
A: The PCMCIA subsystem in 2.5 has been extensively rewritten, thanks
to the work of Russell King, Dominik Brodowski, and others. There
is a mailing list devoted to discussion of new PCMCIA development
at http://lists.infradead.org/mailman/listinfo/linux-pcmcia. The
standalone pcmcia-cs modules will probably not be ported beyond 2.4
kernels, due the number of API changes.