Andrea Arcangeli (email@example.com)
Thu, 28 May 1998 01:53:22 +0200 (CEST)
On Thu, 28 May 1998, David Campbell wrote:
>I suggest taking a second look at that code. The same value is written to
>CTR as ECR.
What I see is that parport_pc write a byte on 0x77? without checks if some
other device is just using that I/O area (while it indirectly checks for
This was the only reason for the patch.
Also it' s a case that the same value is written to CTR and to ECR since
the semantics of the two control port is completly different (at least
after a short read of the specs I have here).
>If you remember that old style XT ports alias IO locations every 0x400,
>this means that writing to ECR (base+0x401) is the same as writing to CTR
>(base + 0x001). On newer chipsets if the ECR is not present then the write
>disappears into the bit bucket.
OK. I read this at top of the function that check for the ECR.
>All I am saying is just be very careful when writing to the ECP associated
>registers as it may clobber older style hardware. If the suggested patch
I am not writing more of what parport_pc was just writing. I removed only
no sense writing. Which sense could make to write a byte on a port
reserved to a device _not_ present (or duplicated)?
>does actually work (I would be supprised if it did) then the entire ECP
I haven' t tried it yet but I can' t see how it could break things. Also
Andreas Muck reported me that writing 0x0 in the econtrol register fix
printing for him. You can see the patch that helps in another email in
That patch include also the patch that you think that could break things,
so maybe lp started to work not only due writing 0x0 instead of 0xc?
Anyway _now_ I don' t think so.
>detection code needs to be reworked.
I' ll take a second look at the code soon... (now it' s time to
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:47 EST