[BUG] parport_pc: ECP+EPP mode doesn't work

[Max Dmitrichenko]

Hi!

I've been facing a strange bug (at least in 2.6.24 and 2.6.26). I've
got a PC with SuperIO controller which supports (de jure non-standard
but de facto very common) mode of LPT which is called ECP+EPP, along
with the standard modes "EPP only" and "ECP only". But kernel detects
port to have only [SPP, TRISTATE] when I switch the SuperIO into this
mode in BIOS. ECP mode is not detected since CONFIG_PARPORT_PC_FIFO is
turned off, so its OK. But why it fails to detect EPP?

I've investigated parport_pc code and that's what I found. Have a look
at parport_EPP_supported() function.

1932         /* If EPP timeout bit clear then EPP available */
1933         if (!clear_epp_timeout(pb)) {
1934                 return 0;  /* No way to clear timeout */
1935         }
1936
1937         /* Check for Intel bug. */
1938         if (priv->ecr) {
1939                 unsigned char i;
1940                 for (i = 0x00; i < 0x80; i += 0x20) {
1941                         ECR_WRITE (pb, i);
1942                         if (clear_epp_timeout (pb)) {
1943                                 /* Phony EPP in ECP. */
1944                                 return 0;
1945                         }
1946                 }
1947         }

Here, if ECP mode is supported by SuperIO, the code checkes for some
bug. Semantics is that it puts ECP port into every supported mode
(Standard mode, Byte mode, FIFO mode and ECP FIFO Mode) except the EPP
mode. In every mode it tries to clear EPP timeout condition. If it
succeeds to clear EPP timeout then bug is found. I don't know anything
about this bug, but let's suppose that author of this code thought so,
because EPP timeout can't be cleared in non-EPP mode.

I've found that EPP mode is not detected because this function return
at line 1944 (i.e. code decides that this strange bug is found). But
what happens in clear_epp_timeout() function?

 250 static int clear_epp_timeout(struct parport *pb)
 251 {
 252         unsigned char r;
 253
 254         if (!(parport_pc_read_status(pb) & 0x01))
 255                 return 1;
 ....
 265 }

So, if timeout bit is not asserted (i.e. nothing to clear) then
function returns a success. From one side, we have a code which finds
success of this function to be a bug (if non-EPP mode is active), from
the other side, it is definitely normal that in non-EPP mode there is
nothing to clear so this function has no option to fail.

So does anybody know something about this strange "intel bug"? I think
if this bug exists then it should be handled in a different way,
because now it prevents the EPP mode to be detected when ECP+EPP mode
enabled.

I also appreciate if someone can test a fairy recent kernel with the
LPT port configured into ECP+EPP mode in BIOS and check whether EPP is
detected along with ECP.

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