Messages in this thread | | | Date | Sat, 7 Mar 2009 01:07:22 +0300 | Subject | [BUG] parport_pc: ECP+EPP mode doesn't work | From | 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
| |