iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

Browse Source 
Pull the MCA deletion branch from Paul Gortmaker:
 "It was good that we could support MCA machines back in the day, but
  realistically, nobody is using them anymore.  They were mostly limited
  to 386-sx 16MHz CPU and some 486 class machines and never more than
  64MB of RAM.  Even the enthusiast hobbyist community seems to have
  dried up close to ten years ago, based on what you can find searching
  various websites dedicated to the relatively short lived hardware.

  So lets remove the support relating to CONFIG_MCA.  There is no point
  carrying this forward, wasting cycles doing routine maintenance on it;
  wasting allyesconfig build time on validating it, wasting I/O on git
  grep'ping over it, and so on."

Let's see if anybody screams.  It generally has compiled, and James
Bottomley pointed out that there was a MCA extension from NCR that
allowed for up to 4GB of memory and PPro-class machines.  So in *theory*
there may be users out there.

But even James (technically listed as a maintainer) doesn't actually
have a system, and while Alan Cox claims to have a machine in his cellar
that he offered to anybody who wants to take it off his hands, he didn't
argue for keeping MCA support either.

So we could bring it back.  But somebody had better speak up and talk
about how they have actually been using said MCA hardware with modern
kernels for us to do that.  And David already took the patch to delete
all the networking driver code (commit a5e371f61a: "drivers/net:
delete all code/drivers depending on CONFIG_MCA").

* 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  MCA: delete all remaining traces of microchannel bus support.
  scsi: delete the MCA specific drivers and driver code
  serial: delete the MCA specific 8250 support.
  arm: remove ability to select CONFIG_MCA
This commit is contained in:
Linus Torvalds
2012-05-23 17:12:06 -07:00
parent c80ddb5263 bb8187d35f
commit d5b4bb4d10
55 changed files with 32 additions and 8033 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/00-INDEX
View File

@@ -218,8 +218,6 @@ m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
- list of magic numbers used to mark/protect kernel data structures.
mca.txt
- info on supporting Micro Channel Architecture (e.g. PS/2) systems.
md.txt
- info on boot arguments for the multiple devices driver.
memory-barriers.txt

2
Documentation/DocBook/Makefile
View File

@@ -6,7 +6,7 @@
# To add a new book the only step required is to add the book to the
# list of DOCBOOKS.
DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
DOCBOOKS := z8530book.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
writing_usb_driver.xml networking.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \

13
Documentation/DocBook/kernel-api.tmpl
View File

@@ -212,19 +212,6 @@ X!Edrivers/pci/hotplug.c
<sect1><title>PCI Hotplug Support Library</title>
!Edrivers/pci/hotplug/pci_hotplug_core.c
</sect1>
<sect1><title>MCA Architecture</title>
<sect2><title>MCA Device Functions</title>
<para>
Refer to the file arch/x86/kernel/mca_32.c for more information.
</para>
<!-- FIXME: Removed for now since no structured comments in source
X!Earch/x86/kernel/mca_32.c
-->
</sect2>
<sect2><title>MCA Bus DMA</title>
!Iarch/x86/include/asm/mca_dma.h
</sect2>
</sect1>
</chapter>
<chapter id="firmware">

107
Documentation/DocBook/mcabook.tmpl
View File

@@ -1,107 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="MCAGuide">
<bookinfo>
<title>MCA Driver Programming Interface</title>
<authorgroup>
<author>
<firstname>Alan</firstname>
<surname>Cox</surname>
<affiliation>
<address>
<email>alan@lxorguk.ukuu.org.uk</email>
</address>
</affiliation>
</author>
<author>
<firstname>David</firstname>
<surname>Weinehall</surname>
</author>
<author>
<firstname>Chris</firstname>
<surname>Beauregard</surname>
</author>
</authorgroup>
<copyright>
<year>2000</year>
<holder>Alan Cox</holder>
<holder>David Weinehall</holder>
<holder>Chris Beauregard</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<para>
The MCA bus functions provide a generalised interface to find MCA
bus cards, to claim them for a driver, and to read and manipulate POS
registers without being aware of the motherboard internals or
certain deep magic specific to onboard devices.
</para>
<para>
The basic interface to the MCA bus devices is the slot. Each slot
is numbered and virtual slot numbers are assigned to the internal
devices. Using a pci_dev as other busses do does not really make
sense in the MCA context as the MCA bus resources require card
specific interpretation.
</para>
<para>
Finally the MCA bus functions provide a parallel set of DMA
functions mimicing the ISA bus DMA functions as closely as possible,
although also supporting the additional DMA functionality on the
MCA bus controllers.
</para>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>
<para>
None.
</para>
</chapter>
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Edrivers/mca/mca-legacy.c
</chapter>
<chapter id="dmafunctions">
<title>DMA Functions Provided</title>
!Iarch/x86/include/asm/mca_dma.h
</chapter>
</book>

8
Documentation/devices.txt
View File

@@ -847,13 +847,7 @@ Your cooperation is appreciated.
...
31 = /dev/tap15 16th Ethertap device
36 block MCA ESDI hard disk
0 = /dev/eda First ESDI disk whole disk
64 = /dev/edb Second ESDI disk whole disk
...
Partitions are handled in the same way as IDE disks
(see major number 3).
36 block OBSOLETE (was MCA ESDI hard disk)
37 char IDE tape
0 = /dev/ht0 First IDE tape

2
Documentation/eisa.txt
View File

@@ -179,7 +179,7 @@ CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
Converting an EISA driver to the new API mostly involves *deleting*
code (since probing is now in the core EISA code). Unfortunately, most
drivers share their probing routine between ISA, MCA and EISA. Special
drivers share their probing routine between ISA, and EISA. Special
care must be taken when ripping out the EISA code, so other busses
won't suffer from these surgical strikes...

1
Documentation/kernel-parameters.txt
View File

@@ -70,7 +70,6 @@ parameter is applicable:
M68k M68k architecture is enabled.
These options have more detailed description inside of
Documentation/m68k/kernel-options.txt.
MCA MCA bus support is enabled.
MDA MDA console support is enabled.
MIPS MIPS architecture is enabled.
MOUSE Appropriate mouse support is enabled.

313
Documentation/mca.txt
View File

@@ -1,313 +0,0 @@
i386 Micro Channel Architecture Support
=======================================
MCA support is enabled using the CONFIG_MCA define. A machine with a MCA
bus will have the kernel variable MCA_bus set, assuming the BIOS feature
bits are set properly (see arch/i386/boot/setup.S for information on
how this detection is done).
Adapter Detection
=================
The ideal MCA adapter detection is done through the use of the
Programmable Option Select registers. Generic functions for doing
this have been added in include/linux/mca.h and arch/x86/kernel/mca_32.c.
Everything needed to detect adapters and read (and write) configuration
information is there. A number of MCA-specific drivers already use
this. The typical probe code looks like the following:
#include <linux/mca.h>
unsigned char pos2, pos3, pos4, pos5;
struct net_device* dev;
int slot;
if( MCA_bus ) {
slot = mca_find_adapter( ADAPTER_ID, 0 );
if( slot == MCA_NOTFOUND ) {
return -ENODEV;
}
/* optional - see below */
mca_set_adapter_name( slot, "adapter name & description" );
mca_set_adapter_procfn( slot, dev_getinfo, dev );
/* read the POS registers. Most devices only use 2 and 3 */
pos2 = mca_read_stored_pos( slot, 2 );
pos3 = mca_read_stored_pos( slot, 3 );
pos4 = mca_read_stored_pos( slot, 4 );
pos5 = mca_read_stored_pos( slot, 5 );
} else {
return -ENODEV;
}
/* extract configuration from pos[2345] and set everything up */
Loadable modules should modify this to test that the specified IRQ and
IO ports (plus whatever other stuff) match. See 3c523.c for example
code (actually, smc-mca.c has a slightly more complex example that can
handle a list of adapter ids).
Keep in mind that devices should never directly access the POS registers
(via inb(), outb(), etc). While it's generally safe, there is a small
potential for blowing up hardware when it's done at the wrong time.
Furthermore, accessing a POS register disables a device temporarily.
This is usually okay during startup, but do _you_ want to rely on it?
During initial configuration, mca_init() reads all the POS registers
into memory. mca_read_stored_pos() accesses that data. mca_read_pos()
and mca_write_pos() are also available for (safer) direct POS access,
but their use is _highly_ discouraged. mca_write_pos() is particularly
dangerous, as it is possible for adapters to be put in inconsistent
states (i.e. sharing IO address, etc) and may result in crashes, toasted
hardware, and blindness.
User level drivers (such as the AGX X server) can use /proc/mca/pos to
find adapters (see below).
Some MCA adapters can also be detected via the usual ISA-style device
probing (many SCSI adapters, for example). This sort of thing is highly
discouraged. Perfectly good information is available telling you what's
there, so there's no excuse for messing with random IO ports. However,
we MCA people still appreciate any ISA-style driver that will work with
our hardware. You take what you can get...
Level-Triggered Interrupts
==========================
Because MCA uses level-triggered interrupts, a few problems arise with
what might best be described as the ISA mindset and its effects on
drivers. These sorts of problems are expected to become less common as
more people use shared IRQs on PCI machines.
In general, an interrupt must be acknowledged not only at the ICU (which
is done automagically by the kernel), but at the device level. In
particular, IRQ 0 must be reset after a timer interrupt (now done in
arch/x86/kernel/time.c) or the first timer interrupt hangs the system.
There were also problems with the 1.3.x floppy drivers, but that seems
to have been fixed.
IRQs are also shareable, and most MCA-specific devices should be coded
with shared IRQs in mind.
/proc/mca
=========
/proc/mca is a directory containing various files for adapters and
other stuff.
/proc/mca/pos Straight listing of POS registers
/proc/mca/slot[1-8] Information on adapter in specific slot
/proc/mca/video Same for integrated video
/proc/mca/scsi Same for integrated SCSI
/proc/mca/machine Machine information
See Appendix A for a sample.
Device drivers can easily add their own information function for
specific slots (including integrated ones) via the
mca_set_adapter_procfn() call. Drivers that support this are ESDI, IBM
SCSI, and 3c523. If a device is also a module, make sure that the proc
function is removed in the module cleanup. This will require storing
the slot information in a private structure somewhere. See the 3c523
driver for details.
Your typical proc function will look something like this:
static int
dev_getinfo( char* buf, int slot, void* d ) {
struct net_device* dev = (struct net_device*) d;
int len = 0;
len += sprintf( buf+len, "Device: %s\n", dev->name );
len += sprintf( buf+len, "IRQ: %d\n", dev->irq );
len += sprintf( buf+len, "IO Port: %#lx-%#lx\n", ... );
...
return len;
}
Some of the standard MCA information will already be printed, so don't
bother repeating it. Don't try putting in more than 3K of information.
Enable this function with:
mca_set_adapter_procfn( slot, dev_getinfo, dev );
Disable it with:
mca_set_adapter_procfn( slot, NULL, NULL );
It is also recommended that, even if you don't write a proc function, to
set the name of the adapter (i.e. "PS/2 ESDI Controller") via
mca_set_adapter_name( int slot, char* name ).
MCA Device Drivers
==================
Currently, there are a number of MCA-specific device drivers.
1) PS/2 SCSI
drivers/scsi/ibmmca.c
drivers/scsi/ibmmca.h
The driver for the IBM SCSI subsystem. Includes both integrated
controllers and adapter cards. May require command-line arg
"ibmmcascsi=io_port" to force detection of an adapter. If you have a
machine with a front-panel display (i.e. model 95), you can use
"ibmmcascsi=display" to enable a drive activity indicator.
2) 3c523
drivers/net/3c523.c
drivers/net/3c523.h
3Com 3c523 Etherlink/MC ethernet driver.
3) SMC Ultra/MCA and IBM Adapter/A
drivers/net/smc-mca.c
drivers/net/smc-mca.h
Driver for the MCA version of the SMC Ultra and various other
OEM'ed and work-alike cards (Elite, Adapter/A, etc).
4) NE/2
driver/net/ne2.c
driver/net/ne2.h
The NE/2 is the MCA version of the NE2000. This may not work
with clones that have a different adapter id than the original
NE/2.
5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and
Reply Sound Blaster/SCSI (SCSI part)
Better support for these cards than the driver for ISA.
Supports multiple cards with IRQ sharing.
Also added boot time option of scsi-probe, which can do reordering of
SCSI host adapters. This will direct the kernel on the order which
SCSI adapter should be detected. Example:
scsi-probe=ibmmca,fd_mcs,adaptec1542,buslogic
The serial drivers were modified to support the extended IO port range
of the typical MCA system (also #ifdef CONFIG_MCA).
The following devices work with existing drivers:
1) Token-ring
2) Future Domain SCSI (MCS-600, MCS-700, not MCS-350, OEM'ed IBM SCSI)
3) Adaptec 1640 SCSI (using the aha1542 driver)
4) Bustek/Buslogic SCSI (various)
5) Probably all Arcnet cards.
6) Some, possibly all, MCA IDE controllers.
7) 3Com 3c529 (MCA version of 3c509) (patched)
8) Intel EtherExpressMC (patched version)
You need to have CONFIG_MCA defined to have EtherExpressMC support.
9) Reply Sound Blaster/SCSI (SB part) (patched version)
Bugs & Other Weirdness
======================
NMIs tend to occur with MCA machines because of various hardware
weirdness, bus timeouts, and many other non-critical things. Some basic
code to handle them (inspired by the NetBSD MCA code) has been added to
detect the guilty device, but it's pretty incomplete. If NMIs are a
persistent problem (on some model 70 or 80s, they occur every couple
shell commands), the CONFIG_IGNORE_NMI flag will take care of that.
Various Pentium machines have had serious problems with the FPU test in
bugs.h. Basically, the machine hangs after the HLT test. This occurs,
as far as we know, on the Pentium-equipped 85s, 95s, and some PC Servers.
The PCI/MCA PC 750s are fine as far as I can tell. The ``mca-pentium''
boot-prompt flag will disable the FPU bug check if this is a problem
with your machine.
The model 80 has a raft of problems that are just too weird and unique
to get into here. Some people have no trouble while others have nothing
but problems. I'd suspect some problems are related to the age of the
average 80 and accompanying hardware deterioration, although others
are definitely design problems with the hardware. Among the problems
include SCSI controller problems, ESDI controller problems, and serious
screw-ups in the floppy controller. Oh, and the parallel port is also
pretty flaky. There were about 5 or 6 different model 80 motherboards
produced to fix various obscure problems. As far as I know, it's pretty
much impossible to tell which bugs a particular model 80 has (other than
triggering them, that is).
Drivers are required for some MCA memory adapters. If you're suddenly
short a few megs of RAM, this might be the reason. The (I think) Enhanced
Memory Adapter commonly found on the model 70 is one. There's a very
alpha driver floating around, but it's pretty ugly (disassembled from
the DOS driver, actually). See the MCA Linux web page (URL below)
for more current memory info.
The Thinkpad 700 and 720 will work, but various components are either
non-functional, flaky, or we don't know anything about them. The
graphics controller is supposed to be some WD, but we can't get things
working properly. The PCMCIA slots don't seem to work. Ditto for APM.
The serial ports work, but detection seems to be flaky.
Credits
=======
A whole pile of people have contributed to the MCA code. I'd include
their names here, but I don't have a list handy. Check the MCA Linux
home page (URL below) for a perpetually out-of-date list.
=====================================================================
MCA Linux Home Page: http://www.dgmicro.com/mca/
Christophe Beauregard
chrisb@truespectra.com
cpbeaure@calum.csclub.uwaterloo.ca
=====================================================================
Appendix A: Sample /proc/mca
This is from my model 8595. Slot 1 contains the standard IBM SCSI
adapter, slot 3 is an Adaptec AHA-1640, slot 5 is a XGA-1 video adapter,
and slot 7 is the 3c523 Etherlink/MC.
/proc/mca/machine:
Model Id: 0xf8
Submodel Id: 0x14
BIOS Revision: 0x5
/proc/mca/pos:
Slot 1: ff 8e f1 fc a0 ff ff ff IBM SCSI Adapter w/Cache
Slot 2: ff ff ff ff ff ff ff ff
Slot 3: 1f 0f 81 3b bf b6 ff ff
Slot 4: ff ff ff ff ff ff ff ff
Slot 5: db 8f 1d 5e fd c0 00 00
Slot 6: ff ff ff ff ff ff ff ff
Slot 7: 42 60 ff 08 ff ff ff ff 3Com 3c523 Etherlink/MC
Slot 8: ff ff ff ff ff ff ff ff
Video : ff ff ff ff ff ff ff ff
SCSI : ff ff ff ff ff ff ff ff
/proc/mca/slot1:
Slot: 1
Adapter Name: IBM SCSI Adapter w/Cache
Id: 8eff
Enabled: Yes
POS: ff 8e f1 fc a0 ff ff ff
Subsystem PUN: 7
Detected at boot: Yes
/proc/mca/slot3:
Slot: 3
Adapter Name: Unknown
Id: 0f1f
Enabled: Yes
POS: 1f 0f 81 3b bf b6 ff ff
/proc/mca/slot5:
Slot: 5
Adapter Name: Unknown
Id: 8fdb
Enabled: Yes
POS: db 8f 1d 5e fd c0 00 00
/proc/mca/slot7:
Slot: 7
Adapter Name: 3Com 3c523 Etherlink/MC
Id: 6042
Enabled: Yes
POS: 42 60 ff 08 ff ff ff ff
Revision: 0xe
IRQ: 9
IO Address: 0x3300-0x3308
Memory: 0xd8000-0xdbfff
Transceiver: External
Device: eth0
Hardware Address: 02 60 8c 45 c4 2a

2
Documentation/scsi/00-INDEX
View File

@@ -56,8 +56,6 @@ g_NCR5380.txt
- info on driver for NCR5380 and NCR53c400 based adapters
hptiop.txt
- HIGHPOINT ROCKETRAID 3xxx RAID DRIVER
ibmmca.txt
- info on driver for IBM adapters with MCA bus
in2000.txt
- info on in2000 driver
libsas.txt

1402
Documentation/scsi/ibmmca.txt
View File

File diff suppressed because it is too large Load Diff

6
Documentation/scsi/scsi-parameters.txt
View File

@@ -37,9 +37,6 @@ parameters may be changed at runtime by the command
eata= [HW,SCSI]
fd_mcs= [HW,SCSI]
See header of drivers/scsi/fd_mcs.c.
fdomain= [HW,SCSI]
See header of drivers/scsi/fdomain.c.
@@ -48,9 +45,6 @@ parameters may be changed at runtime by the command
gvp11= [HW,SCSI]
ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter
See Documentation/mca.txt.
in2000= [HW,SCSI]
See header of drivers/scsi/in2000.c.

2
Documentation/scsi/scsi_mid_low_api.txt
View File

@@ -30,7 +30,7 @@ the motherboard (or both). Some aic7xxx based HBAs are dual controllers
and thus represent two hosts. Like most modern HBAs, each aic7xxx host
has its own PCI device address. [The one-to-one correspondence between
a SCSI host and a PCI device is common but not required (e.g. with
ISA or MCA adapters).]
ISA adapters).]
The SCSI mid level isolates an LLD from other layers such as the SCSI
upper layer drivers and the block layer.

22
Documentation/serial/stallion.txt
View File

@@ -20,10 +20,10 @@ There are two drivers that work with the different families of Stallion
multiport serial boards. One is for the Stallion smart boards - that is
EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for
the true Stallion intelligent multiport boards - EasyConnection 8/64
(ISA, EISA, MCA), EasyConnection/RA-PCI, ONboard and Brumby.
(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby.
If you are using any of the Stallion intelligent multiport boards (Brumby,
ONboard, EasyConnection 8/64 (ISA, EISA, MCA), EasyConnection/RA-PCI) with
ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with
Linux you will need to get the driver utility package. This contains a
firmware loader and the firmware images necessary to make the devices operate.
@@ -40,7 +40,7 @@ If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI
boards then you don't need this package, although it does have a serial stats
display program.
If you require DIP switch settings, EISA or MCA configuration files, or any
If you require DIP switch settings, or EISA configuration files, or any
other information related to Stallion boards then have a look at Stallion's
web pages at http://www.stallion.com.
@@ -51,13 +51,13 @@ web pages at http://www.stallion.com.
The drivers can be used as loadable modules or compiled into the kernel.
You can choose which when doing a "config" on the kernel.
All ISA, EISA and MCA boards that you want to use need to be configured into
All ISA, and EISA boards that you want to use need to be configured into
the driver(s). All PCI boards will be automatically detected when you load
the driver - so they do not need to be entered into the driver(s)
configuration structure. Note that kernel PCI support is required to use PCI
boards.
There are two methods of configuring ISA, EISA and MCA boards into the drivers.
There are two methods of configuring ISA and EISA boards into the drivers.
If using the driver as a loadable module then the simplest method is to pass
the driver configuration as module arguments. The other method is to modify
the driver source to add configuration lines for each board in use.
@@ -71,12 +71,12 @@ That makes things pretty simple to get going.
2.1 MODULE DRIVER CONFIGURATION:
The simplest configuration for modules is to use the module load arguments
to configure any ISA, EISA or MCA boards. PCI boards are automatically
to configure any ISA or EISA boards. PCI boards are automatically
detected, so do not need any additional configuration at all.
If using EasyIO, EasyConnection 8/32 ISA or MCA, or EasyConnection 8/63-PCI
If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI
boards then use the "stallion" driver module, Otherwise if you are using
an EasyConnection 8/64 ISA, EISA or MCA, EasyConnection/RA-PCI, ONboard,
an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard,
Brumby or original Stallion board then use the "istallion" driver module.
Typically to load up the smart board driver use:
@@ -146,7 +146,7 @@ on each system boot. Typically configuration files are put in the
2.2 STATIC DRIVER CONFIGURATION:
For static driver configuration you need to modify the driver source code.
Entering ISA, EISA and MCA boards into the driver(s) configuration structure
Entering ISA and EISA boards into the driver(s) configuration structure
involves editing the driver(s) source file. It's pretty easy if you follow
the instructions below. Both drivers can support up to 4 boards. The smart
card driver (the stallion.c driver) supports any combination of EasyIO and
@@ -157,7 +157,7 @@ supports any combination of ONboards, Brumbys, Stallions and EasyConnection
To set up the driver(s) for the boards that you want to use you need to
edit the appropriate driver file and add configuration entries.
If using EasyIO or EasyConnection 8/32 ISA or MCA boards,
If using EasyIO or EasyConnection 8/32 ISA boards,
In drivers/char/stallion.c:
- find the definition of the stl_brdconf array (of structures)
near the top of the file
@@ -243,7 +243,7 @@ change it on the board.
On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so
if there is a conflict you may need to change the IRQ used for a board. There
are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64
(ISA, EISA and MCA) boards. The memory region on EasyConnection 8/64 and
(ISA and EISA) boards. The memory region on EasyConnection 8/64 and
ONboard boards is software programmable, but not on the Brumby boards.