Re: [hpoj-devel] 2.4 kernel issues

[<pa...@rc...>]

Burkhard Kohl wrote:
> Somewhere between test8 and test12 the parport interface has changed
> substantially enough to break the ieee12844 modules.
> 
> I have tried to take care of this changes by adapting ieee12844pp.c
> and managed to compile with the patch appended. 
Hi, Burkhard.  Thanks for looking into this problem.  (I'm actually replying
to your earlier version of this message that didn't make it to the mailing
list.)

> But my compilate does not work properly:
> When I try ./hpo list_pml I get:
> 	IEEE1284.4 protocol layer for Linux installed
> 	ieee12844pp: init_module.
> 	mlcpp_attach: New device found on parport0
> 	ieee12844pp: IEEE1284.4 device found on parport0:
> 	HEWLETT-PACKARD OFFICEJET R40;
> 	device registered to IEEE1284.4 protocol layer as link mlcpp0
> 	mlcpp_attach: links: 1.
> 	parport0 (mlcpp): use data_reverse for this!
> 	do_neg(c9067d1c,mode=0x04): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 	mlcpp0: mlcpp_intr ERROR -110
> 	state=2 event=23 reset=1 recv=0 rcv=0 send=0
> 	do_neg(c9067d1c,mode=0x00): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 
> David, can you make sense out of these messages? Does it mean that
> I did not successfully set the ECR to bidirectional? 
It looks like it failed during the termination phase (event 23) of getting
the device ID string (do_neg(mode=0x04)), which is before it even attempts
to change the ECR.  The problem might have to do with the polling-timer
changes, because when it's waiting for a signal response from the
peripheral, it spins in a poll loop for a bit, then reschedules itself
in the task queue, which as you discovered has been changed.

> The message "use data_reverse for this!" stems from 
> parport_pc_write_control in the parport_pc module which means, that
> now an inline parport_pc_data_reverse() is calling parport_pc_frob_control()
> with the value of 0x20. This is just a cosmetical change but it 
> looks that the parport interface in future 2.4 kernels will change
> further and more breakage has to be expected. I have the feeling
> that ieee12844pp.c will need some redesign to work with 2.4.
All this madness of a constantly changing/breaking kernel interface is one
of many reasons why I'm trying to move towards a user-level driver approach.
I'm actively pursuing a solution to that problem at work, and if all goes
well (keep your fingers crossed!) I may be able to provide a solution in the
near future.  Of course, for now we should do what we can to fix the current
code just in case things don't work out in our favor.

> It looks
> that access to some parport registers is now considered lowlevel 
> enough to justify hiding it from driver developers.
I can understand removing direct register access from individual drivers,
but I can't understand not providing an alternative interface.

> A further note on compiling the kernel modules: egcs 1.1.2
> is now the recommended compiler. But on the other hand many 
> distributions supply users with gcc 2.95.2. Linux/Documentation/Changes 
> strongly recommends to use 2.95.x with the -fno-strict_aliasing option.
> I thus added EXTRA_CFLAGS to ieee12844/Makefile which has to be 
> activated by gcc 2.95.x users. Is there a way to handle this via 
> configure?
That shouldn't be a problem.

David