linux-kernel - parport_pc disables parallel port on unload.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 22 Sep 2008 18:10:38 -0700 (PDT)
From:	Bill Unruh <unruh@...sics.ubc.ca>
To:	linux-kernel@...r.kernel.org
Subject: parport_pc disables parallel port on unload.

I have a parallel port module gps.c which I have written ( after the short
module described in Linux Device Drivers), whose purpose is to timestamp
the occurance of interrupts on the parallel port Ack line to as high a temporal
accuracy as possible.These are generated by the PPS line of a Gamin 18LVC
gps receiver. Since I want the highest accuracy possible I do not want the
latency of going through the stock drivers and waiting for a poll or
select to let me know an interrupt has occured.

The problem I am running into is that the parport_pc driver, if it is
unloaded, powers off the parallel port, making it useless for my  purposes
(or at least I do not know how to power it up again). Now I do not think
that the parport driver should disable the port when it is unloaded, but
rather leave it in the state it was in when the module was loaded, but the
maintainer of parport_pc (alan@...rguk.ukuu.org.uk) disagrees with me,
  and he is doing the maintaining, not me.

So, could anyone point me to some relatively comprehensible documentation (
or "canned program") to show me how to switch the parallel port back on if
unloading parport_pc has switched it off. I assume it can be switched on
again. Alternatively, how to tell parport_pc to release the registers of
the parallel port so I can run my module even if parport_pc is loaded. 
(that of course sounds dangerous and could lead to contention)
Having the interrupt be processed first by parport_pc and then by my
userland program sounds like a recipie for long and variable latency (I am
talking in terms of usec). (Mind you I hae not measured it but the direct
interrupt is of the order of 1usec).

If parport_pc is not loaded first, then my program runs fine. And the clock
discipline and scatter using ntp is of the order of 2usec, and I suspect much of that
is ntp's relatively poor clock discipline algorithm (in comparison with the
best possible) rather than problems with latency in the clock reading.

Thanks
Bill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/