[PARPORT] Parallel port patches (and woes)

From: Nicholas Hildreth (n.hildreth@irl.cri.nz)
Date: Tue Mar 05 2002 - 03:04:56 EST

  • Next message: Tim Waugh: "Re: [PARPORT] Parallel port patches (and woes)"

    I've had a looksee into getting a PCMCIA parallel port card working for the
    ipaq (in my case a Quatech SPP-100). Two seg faults were occurring when
    trying to load the parport modules. Below are fixes to get parport up and
    running - well,... sorta.

    Seg 1:
    Occurs from the 'parport_pc' module trying to scan for ISA ports that
    obviously the ipaq doesn't have. The easiest way around this is to modify
    the include file "/include/asm-arm/parport.h". Change the line in function
    'parport_pc_find_nonpci_ports' to the following:

    static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)
      // return parport_pc_find_isa_ports (autoirq, autodma);
      return 1; // IPaQ has no ISA ports.

    Any justification need can be argued by saying that this function is only
    ever called when scanning for built-in ports - which the ipaq will never
    have. Scanning events must originate from 'parport_cs' not 'parport_pc'.
    Returning 1 here tricks the module into loading by thinking it succeeded.
    (parport_pc needs to be loaded before parport_cs can load). Besides, fixing
    the 'parport_pc_find_isa_ports' function properly will probably end up
    making 'parport_pc.c' too device dependant.

    Seg 2:
    The second segmentation fault appears to be a coding fault originating from
    the 'parport_cs.c' file. In the function 'parport_config' around line 322,
    there is a small for loop that cycles an array 5 elements. At least it
    probably was 5 elements once. Now it only contains 3 elements. Hence a bad
    memory dereference is occurring.

    Change this: (~line 322: parport_cs.c)
        for (i = 0; i < 5; i++)
            if (p->modes & mode[i].flag) printk(",%s", mode[i].name);

    To this:
        for (i = 0; i < MAX_PARPORT_CS_MODES; i++)
            if (p->modes & mode[i].flag) printk(",%s", mode[i].name);

    Then complete by adding:
        #define MAX_PARPORT_CS_MODES 3;

    just above this: (~line 229: parport_cs.c)
        static struct { u_int flag; char *name; } mode[] = {
            { PARPORT_MODE_TRISTATE, "PS2" },
            { PARPORT_MODE_EPP, "EPP" },
            { PARPORT_MODE_ECP, "ECP" },

    With these changes the parport module set 'parport', 'parport_pc',
    'parport_cs' now install without complaint when the card is inserted.
    According to all the documentation I can find and all the examples I've
    tried, parport (with and with 'ppdev') should be working correctly. Nothing
    complains and every function behaves as it should. An inserted card gets the
    following stats:

    Slot 0: Base_address (0xf6000378) IRQ: 42
    Slot 1: Base_address (0xf7000378) IRQ: 32

    EXCEPT 1, while I have tracked that the correct information is being written
    correctly to this address, none of the data/status/control lines can
    actually be changed no matter what you send it (correct or otherwise). Nor
    can the data lines be read correctly when grounding them. (even writing
    directly to that address does nothing to the port's lines). However I'm
    certian the parport modules are working.

    Possible reasons for this I suppose could be a bad PC-card (I only have the
    one so I cannot check it), however I don't think that is the case. I think
    something more fundamental is happening perhaps an oversight on my behalf
    (all be it somewhat unusual ;-) to do with PC-cards on the ipaq or maybe the
    version of pcmcia-cs utilities used. Or perhaps a kernel change is required.
    I only been using the 2.4.16-rmk1-hh15 kernel (fam v. 0.5.1) but the parport
    source code from the cvs of 2.4.17-rmk5-hh4.

    EXCEPT 2, the ipaq will crash Linux (from all appearances) if the card is
    ejected and then reinserted.

    Any suggestions to this problem greatly appreciated.


    -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Tue Mar 05 2002 - 03:12:20 EST