[lkml]   [1999]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: ne2k and 0x378 lp ports
Hi Randy, Alan.

Alan: Can you please forward this to whoever maintains the ne-isa
driver - I can't work out who that is...

> NE2000 uses base_io_addr thru base + 0x1f, but all registers in
> that range are not used.

> Base thru base + 0xf are ethernet controller registers. Base +
> 0x10 (16 bits) is a packet data transfer register. Base + 0x1f
> is a reset register.

Ah...16 bits! I hadn't realised that...patch fixed to deal with it...

> Some NE2000 adapters may alias the data transfer register and
> the reset register. Apparently yours does not do this...

Just a thought, but if the register at offset 0x10 is 16-bit, then the
addresses 0x10, 0x11 and 0x1F all need to be separately decoded, and
that essentially requires full decoding, with the faint possibility
that up to two of A1, A2 or A3 is not decoded - at least one of them
needs to be decoded to tell the difference between 0x11 and 0x1F.

I've developed a patch which deals with this situation, and I can
report that the resulting patched kernel is now in use on my systems,
and is working fine on all of them.

The patch is attached, and it has an analysis of the various
situations that may apply, and how it affects them, in the same file
in front of the patch. Here's the said summary...

1. This patch has no affect on the behaviour of the ne-pci driver.

2. This patch does not affect the behaviour of the ne-isa driver as
it applies to non-ISA-bus interfaces.

3. This patch does not affect the behaviour of the ne-isa driver if
the said driver is compiled as a module. Indeed, in this case,
the compiled driver code is unchanged.

4. This patch does not affect the behaviour of the ne-isa driver in
the case where the io address is provided by the user at boot time.

5. This patch does not affect the behaviour of the ne-isa driver in
the case where the entire 32-byte I/O address space is unclaimed
when this driver tries to initialise the port in question. The
full 32-byte region is still claimed by the driver.

6. This patch does not affect the behaviour of the ne-isa driver in
the case where any of the I/O ports at address offsets 0x00 to
0x10 inclusive, or at address offset 0x1F, are already claimed.
The driver will still refuse to auto-probe that address range in
the event that this is true.

7. This patch DOES affect the behaviour of the ISA-bus auto-probe in
the case where all of the I/O ports at address offsets 0x00 to
0x10, and at address offset 0x1F, are currently unclaimed, but
one or more of the I/O ports at address offsets 0x11 to 0x1E are
claimed. However, its application currently depends on a new
configuration option, which is fully documented.

In particular, the problem case that inspired this patch now works, as
do similar problem cases. The original is the following configuration:

a. An ne2000 clone ISA-bus network interface card is based at
io=0x360, and fully decodes all address lines for all ports.

b. The secondary IDE interface is in use, claiming port 0x376, as
well as claiming other ports not relevant to this case.

c. The printer interface based at io=0x378 is NOT present. If this
interface is present, the behaviour is unchanged as the I/O port
at address offset 0x1F has already been claimed, and case (6) of
the above description thus applies.

With the original code, the stated card configuration could not be

On my system, this is the resulting /proc/ioports extract:

Q> 02f8-02ff : serial(auto)
Q> 0360-0371 : NE2000 <=== Main block.
Q> 0376-0376 : ide1
Q> 037f-037f : NE2000 <=== Reset port.
Q> 0388-038b : OPL3/OPL2

This implementation currently relies on a new configuration option as
I have not yet worked out all of the necessary logic to automatically
determine whether the card fully decodes the address bus. However,
when this logic is completed, this extra configuration option will
vanish and the detection will be fully automatic.

Best wishes from Riley.

| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
[unhandled content-type:application/octet-stream]
 \ /
  Last update: 2005-03-22 13:53    [W:0.108 / U:13.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site