Re: [PATCH] 2.4.30: Atari EtherNEC driver
> > Please integrate into the Debian 2.4 kernel images :-)
>
> There are no official 2.4 images anymore, however I just built an
> "experimental" one for the atari users:
>
> http://people.debian.org/~cts/debian-m68k/ct60/linux-image-2.4.30-atari_2.4.30-1_m68k.deb
>
> The source package for this is also there, which includes some instructions
> for rebuilding the image. The deb should work on a Falcon/CT60 machine, but
> I haven't tried it on mine yet. I had to remove the atari_scc driver to make
> it build, so expect to see updated packages as soon as Michael has a new
> patch ready.
Just remove the atari_SCC_init_done and atari_SCC_reset_done declarations
in atari_scc.c (around line 112) and recompile. Or turn them into
externs, like this:
-------------------------------- %< -------------------------------
--- drivers/char/atari_scc.c~ 2006-11-14 15:30:55.000000000 +0100
+++ drivers/char/atari_scc.c 2006-11-14 15:30:55.000000000 +0100
@@ -109,10 +109,10 @@
*/
/* Flag that Modem1 port is already initialized and used */
-int atari_SCC_init_done = 0;
+extern int atari_SCC_init_done;
/* Can be set somewhere, if a SCC master reset has already be done and should
* not be repeated; used by kgdb */
-int atari_SCC_reset_done = 0;
+extern int atari_SCC_reset_done;
/*---------------------------------------------------------------------------
* Interface from generic_serial.c back here
-------------------------------- %< -------------------------------
That's leftover crud I never got around implementing - if the serial debug
code, or the kgdb code have already initialized the chip this driver
should not trample over those settings. Is kgdb still alive? The init_done
stuff looks like it belongs in scc_open. The reset_done should protect the
SCC master reset. Just in case someone wants to play with SCC serial
debugging (hint: I prefer ARAnyM these days :-)
On a different note: EtherNEC now works in 2.6 also. Throughput is half
that of 2.4, which may be due to the schedule_delayed_work() delay of 1
jiffy. Plus I get weird warnings (DMAing conflict in block_output); maybe
I'm reentering the driver...
Michael
Reply to: