lkml.org 
[lkml]   [1999]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    auto-probed.

    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. |
    +----------------------------------------------------------------------+
    * ftp://ftp.MemAlpha.cx/pub/rhw/Linux
    * http://www.MemAlpha.cx/kernel.versions.html
    [unhandled content-type:application/octet-stream]
    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.027 / U:0.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site