[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#2470: in kernel Attached ether adapter driver interferes with lp module init



Package: (kernel) image
Version: 1.2.13r5 included with Debian 0.93R6
precisely: atp.c:v1.01 1/18/95 Donald Becker (becker@cesdis.gsfc.nasa.gov)

My computer, an AST Ascentia 800N, has just one parallel port at
address 0x378.

The Attached (packet) ether adapter driver (atp.o) linked with the std kernel
image checks for the presence of the adapter leaving the parallel port 0x378
in such a state, that the lp module when loaded doesn't detect the presence of
any parallel port even if he writes 0x00 to 0x378 because it gets 0xff
as there's no active port.

I have investigated the problem:
 the atp driver save the control reg (0x37a) status and when it fails
 dectecting it restores it. But on my hardware:
 the bit 0x20 of the control reg is always set when we read it.
 Sending a byte with bit 0x20 off changes nothing.
 But sending a byte with this bit set, practically turns the port off.
 Then we get always 0xff at 0x378. To switch the port on we must
 send a byte with 0x20 off to the control reg.
 The 0xe0 bits should, I think, (on normal hardware) not be used,
 masking them all before restoring could be an idea
 (I don't know how much general).

Suggested Patch:
*** /usr/src/linux-1.2.13/drivers/net/atp.c	Tue Mar  7 15:25:26 1995
--- atp.c	Thu Feb 29 17:38:58 1996
***************
*** 179,186 ****
--- 179,189 ----
  	outb(0xff, ioaddr + PAR_DATA);
  	/* Save the original value of the Control register, in case we guessed
  	   wrong. */
  	saved_ctrl_reg = inb(ioaddr + PAR_CONTROL);
+ 	/* !!! Should prevent hw compatibility problem,
+ 	   only common usage bits will be restored (spedroni@math.ethz.ch) */
+ 	saved_ctrl_reg &= 0x1f;
  	/* IRQEN=0, SLCTB=high INITB=high, AUTOFDB=high, STBB=high. */
  	outb(0x04, ioaddr + PAR_CONTROL);
  	write_reg_high(ioaddr, CMR1, CMR1h_RESET);
  	eeprom_delay(2048);

This problem is likely very hardware specific but also very confusing.

__________________________________________________________________

	Samuele Pedroni / spedroni@math.ethz.ch  Mar 5 1996.


Reply to: