Remove of old NCR53C9x/esp family of drivers

James
Could you at least put the following patch in scsi-pending
so it can attract some acknowledgment, and retract futile attempts from people at coding these drivers.
(And also git is better than me in maintaining it synced)

Christoph Hellwig!
I need your Recommended-by: on this. I had my regular
convert-to-accessors, and because of your recommendation I'm pushing this removal. And I keep doing it again and again because a removal patch is a conflict-to-any by definition.

David S. Miller & Maciej W. Rozycki
Please add a comment in favor of this move. And a few words for
the few users left for this hardware.

Boaz

As recommended by Christoph Hellwig. There is no use of Fixing these drivers, since there is a much simpler and modern esp infrastructure with David Miller's esp_scsi

- Remove all driver files dependent on NCR53C9x.c

	deleted:    drivers/scsi/NCR53C9x.c
	deleted:    drivers/scsi/NCR53C9x.h
	deleted:    drivers/scsi/blz1230.c
	deleted:    drivers/scsi/blz2060.c
	deleted:    drivers/scsi/cyberstorm.c
	deleted:    drivers/scsi/cyberstormII.c
	deleted:    drivers/scsi/dec_esp.c
	deleted:    drivers/scsi/fastlane.c
	deleted:    drivers/scsi/mac_esp.c
	deleted:    drivers/scsi/mca_53c9x.c
	deleted:    drivers/scsi/oktagon_esp.c
	deleted:    drivers/scsi/oktagon_io.S
	deleted:    drivers/scsi/sun3x_esp.c

- Remove above list from drivers/scsi/Kconfig && drivers/scsi/Makefile

---
 drivers/scsi/Kconfig        |   85 -
 drivers/scsi/Makefile       |   11 -
 drivers/scsi/NCR53C9x.c     | 3654 -------------------------------------------
 drivers/scsi/NCR53C9x.h     |  668 --------
 drivers/scsi/blz1230.c      |  353 -----
 drivers/scsi/blz2060.c      |  306 ----
 drivers/scsi/cyberstorm.c   |  377 -----
 drivers/scsi/cyberstormII.c |  314 ----
 drivers/scsi/dec_esp.c      |  687 --------
 drivers/scsi/fastlane.c     |  421 -----
 drivers/scsi/mac_esp.c      |  751 ---------
 drivers/scsi/mca_53c9x.c    |  520 ------
 drivers/scsi/oktagon_esp.c  |  606 -------
 drivers/scsi/oktagon_io.S   |  194 ---
 drivers/scsi/sun3x_esp.c    |  392 -----
 15 files changed, 0 insertions(+), 9339 deletions(-)
 delete mode 100644 drivers/scsi/NCR53C9x.c
 delete mode 100644 drivers/scsi/NCR53C9x.h
 delete mode 100644 drivers/scsi/blz1230.c
 delete mode 100644 drivers/scsi/blz2060.c
 delete mode 100644 drivers/scsi/cyberstorm.c
 delete mode 100644 drivers/scsi/cyberstormII.c
 delete mode 100644 drivers/scsi/dec_esp.c
 delete mode 100644 drivers/scsi/fastlane.c
 delete mode 100644 drivers/scsi/mac_esp.c
 delete mode 100644 drivers/scsi/mca_53c9x.c
 delete mode 100644 drivers/scsi/oktagon_esp.c
 delete mode 100644 drivers/scsi/oktagon_io.S
 delete mode 100644 drivers/scsi/sun3x_esp.c

index 0b243e0..1ee71d9 100644
@@ -350,13 +350,6 @@ config SGIWD93_SCSI
 	  If you have a Western Digital WD93 SCSI controller on
 	  an SGI MIPS system, say Y.  Otherwise, say N.
 
-config SCSI_DECNCR
-	tristate "DEC NCR53C94 Scsi Driver"
-	depends on MACH_DECSTATION && SCSI && TC
-	help
-	  Say Y here to support the NCR53C94 SCSI controller chips on IOASIC
-	  based TURBOchannel DECstations and TURBOchannel PMAZ-A cards.
-
 config SCSI_DECSII
 	tristate "DEC SII Scsi Driver"
 	depends on MACH_DECSTATION && SCSI && 32BIT

@@ -1263,17 +1256,6 @@ config SCSI_NCR53C8XX_NO_DISCONNECT
 	  not allow targets to disconnect is not reasonable if there is more
 	  than 1 device on a SCSI bus. The normal answer therefore is N.
 
-config SCSI_MCA_53C9X
-	tristate "NCR MCA 53C9x SCSI support"
-	depends on MCA_LEGACY && SCSI && BROKEN_ON_SMP
-	help
-	  Some MicroChannel machines, notably the NCR 35xx line, use a SCSI
-	  controller based on the NCR 53C94.  This driver will allow use of
-	  the controller on the 3550, and very possibly others.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called mca_53c9x.
-
 config SCSI_PAS16
 	tristate "PAS16 SCSI support"
 	depends on ISA && SCSI

@@ -1600,45 +1582,6 @@ config GVP11_SCSI
 	  To compile this driver as a module, choose M here: the
 	  module will be called gvp11.
 
-config CYBERSTORM_SCSI
-	tristate "CyberStorm SCSI support"
-	depends on ZORRO && SCSI
-	help
-	  If you have an Amiga with an original (MkI) Phase5 Cyberstorm
-	  accelerator board and the optional Cyberstorm SCSI controller,
-	  answer Y. Otherwise, say N.
-
-config CYBERSTORMII_SCSI
-	tristate "CyberStorm Mk II SCSI support"
-	depends on ZORRO && SCSI
-	help
-	  If you have an Amiga with a Phase5 Cyberstorm MkII accelerator board
-	  and the optional Cyberstorm SCSI controller, say Y. Otherwise,
-	  answer N.
-
-config BLZ2060_SCSI
-	tristate "Blizzard 2060 SCSI support"
-	depends on ZORRO && SCSI
-	help
-	  If you have an Amiga with a Phase5 Blizzard 2060 accelerator board
-	  and want to use the onboard SCSI controller, say Y. Otherwise,
-	  answer N.
-
-config BLZ1230_SCSI
-	tristate "Blizzard 1230IV/1260 SCSI support"
-	depends on ZORRO && SCSI
-	help
-	  If you have an Amiga 1200 with a Phase5 Blizzard 1230IV or Blizzard
-	  1260 accelerator, and the optional SCSI module, say Y. Otherwise,
-	  say N.
-
-config FASTLANE_SCSI
-	tristate "Fastlane SCSI support"
-	depends on ZORRO && SCSI
-	help
-	  If you have the Phase5 Fastlane Z3 SCSI controller, or plan to use
-	  one in the near future, say Y to this question. Otherwise, say N.
-
 config SCSI_A4000T
 	tristate "A4000T NCR53c710 SCSI support (EXPERIMENTAL)"
 	depends on AMIGA && SCSI && EXPERIMENTAL

@@ -1666,15 +1609,6 @@ config SCSI_ZORRO7XX
 	      accelerator card for the Amiga 1200,
 	    - the SCSI controller on the GVP Turbo 040/060 accelerator.
 
-config OKTAGON_SCSI
-	tristate "BSC Oktagon SCSI support (EXPERIMENTAL)"
-	depends on ZORRO && SCSI && EXPERIMENTAL
-	help
-	  If you have the BSC Oktagon SCSI disk controller for the Amiga, say
-	  Y to this question.  If you're in doubt about whether you have one,
-	  see the picture at
-	  <http://amiga.resource.cx/exp/search.pl?product=oktagon>.
-
 config ATARI_SCSI
 	tristate "Atari native SCSI support"
 	depends on ATARI && SCSI

@@ -1727,18 +1661,6 @@ config MAC_SCSI
 	  SCSI-HOWTO, available from
 	  <http://www.tldp.org/docs.html#howto>.
 
-config SCSI_MAC_ESP
-	tristate "Macintosh NCR53c9[46] SCSI"
-	depends on MAC && SCSI
-	help
-	  This is the NCR 53c9x SCSI controller found on most of the 68040
-	  based Macintoshes.  If you have one of these say Y and read the
-	  SCSI-HOWTO, available from
-	  <http://www.tldp.org/docs.html#howto>.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called mac_esp.
-
 config MVME147_SCSI
 	bool "WD33C93 SCSI driver for MVME147"
 	depends on MVME147 && SCSI=y

@@ -1776,13 +1698,6 @@ config SUN3_SCSI
 	  General Linux information on the Sun 3 series (now discontinued)
 	  is at <http://www.angelfire.com/ca2/tech68k/sun3.html>.
 
-config SUN3X_ESP
-	bool "Sun3x ESP SCSI"
-	depends on SUN3X && SCSI=y
-	help
-	  The ESP was an on-board SCSI controller used on Sun 3/80
-	  machines.  Say Y here to compile in support for it.
-
 config SCSI_SUNESP
 	tristate "Sparc ESP Scsi Driver"
 	depends on SBUS && SCSI

index 93e1428..6fe6202 100644
@@ -44,15 +44,8 @@ obj-$(CONFIG_A2091_SCSI)	+= a2091.o	wd33c93.o
 obj-$(CONFIG_GVP11_SCSI)	+= gvp11.o	wd33c93.o
 obj-$(CONFIG_MVME147_SCSI)	+= mvme147.o	wd33c93.o
 obj-$(CONFIG_SGIWD93_SCSI)	+= sgiwd93.o	wd33c93.o
-obj-$(CONFIG_CYBERSTORM_SCSI)	+= NCR53C9x.o	cyberstorm.o
-obj-$(CONFIG_CYBERSTORMII_SCSI)	+= NCR53C9x.o	cyberstormII.o
-obj-$(CONFIG_BLZ2060_SCSI)	+= NCR53C9x.o	blz2060.o
-obj-$(CONFIG_BLZ1230_SCSI)	+= NCR53C9x.o	blz1230.o
-obj-$(CONFIG_FASTLANE_SCSI)	+= NCR53C9x.o	fastlane.o
-obj-$(CONFIG_OKTAGON_SCSI)	+= NCR53C9x.o	oktagon_esp_mod.o
 obj-$(CONFIG_ATARI_SCSI)	+= atari_scsi.o
 obj-$(CONFIG_MAC_SCSI)		+= mac_scsi.o
-obj-$(CONFIG_SCSI_MAC_ESP)	+= mac_esp.o	NCR53C9x.o
 obj-$(CONFIG_SUN3_SCSI)		+= sun3_scsi.o  sun3_scsi_vme.o
 obj-$(CONFIG_MVME16x_SCSI)	+= 53c700.o	mvme16x_scsi.o
 obj-$(CONFIG_BVME6000_SCSI)	+= 53c700.o	bvme6000_scsi.o

@@ -95,7 +88,6 @@ obj-$(CONFIG_SCSI_SYM53C8XX_2)	+= sym53c8xx_2/
 obj-$(CONFIG_SCSI_ZALON)	+= zalon7xx.o
 obj-$(CONFIG_SCSI_EATA_PIO)	+= eata_pio.o
 obj-$(CONFIG_SCSI_7000FASST)	+= wd7000.o
-obj-$(CONFIG_SCSI_MCA_53C9X)	+= NCR53C9x.o	mca_53c9x.o
 obj-$(CONFIG_SCSI_IBMMCA)	+= ibmmca.o
 obj-$(CONFIG_SCSI_EATA)		+= eata.o
 obj-$(CONFIG_SCSI_DC395x)	+= dc395x.o

@@ -112,13 +104,11 @@ obj-$(CONFIG_SCSI_QLOGICPTI)	+= qlogicpti.o
 obj-$(CONFIG_BLK_DEV_IDESCSI)	+= ide-scsi.o
 obj-$(CONFIG_SCSI_MESH)		+= mesh.o
 obj-$(CONFIG_SCSI_MAC53C94)	+= mac53c94.o
-obj-$(CONFIG_SCSI_DECNCR)	+= NCR53C9x.o	dec_esp.o
 obj-$(CONFIG_BLK_DEV_3W_XXXX_RAID) += 3w-xxxx.o
 obj-$(CONFIG_SCSI_3W_9XXX)	+= 3w-9xxx.o
 obj-$(CONFIG_SCSI_PPA)		+= ppa.o
 obj-$(CONFIG_SCSI_IMM)		+= imm.o
 obj-$(CONFIG_JAZZ_ESP)		+= esp_scsi.o	jazz_esp.o
-obj-$(CONFIG_SUN3X_ESP)		+= NCR53C9x.o	sun3x_esp.o
 obj-$(CONFIG_SCSI_LASI700)	+= 53c700.o lasi700.o
 obj-$(CONFIG_SCSI_SNI_53C710)	+= 53c700.o sni_53c710.o
 obj-$(CONFIG_SCSI_NSP32)	+= nsp32.o

@@ -162,7 +152,6 @@ ncr53c8xx-flags-$(CONFIG_SCSI_ZALON) \
 CFLAGS_ncr53c8xx.o	:= $(ncr53c8xx-flags-y) $(ncr53c8xx-flags-m)
 zalon7xx-objs	:= zalon.o ncr53c8xx.o
 NCR_Q720_mod-objs	:= NCR_Q720.o ncr53c8xx.o
-oktagon_esp_mod-objs	:= oktagon_esp.o oktagon_io.o
 
 # Files generated that shall be removed upon make clean
 clean-files :=	53c700_d.h 53c700_u.h

1.5.3.3

Part of the diff is not shown here. View the raw message.

OK, I'll split this into four pieces for scsi-pending, since there are three separate interest groups with signoffs to collect (MCA, m68k and alpha) plus the core removal.

James

Anybody who can look into converting the m68k NCR53C9x drivers and has hardware to test (some of) them? I don't think we can afford losing one third of our SCSI drivers...

You can use the following as guidance:

commit 5ff263667798946abc15314eae3f341345877d7a

Author: Thomas Bogendoerfer <[email protected]>
Date:   Tue May 22 17:03:44 2007 -0700

[SCSI] jazz_esp: Converted to use esp_core.

Use new esp_scsi for JAZZ SCSI host adapter driver

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

I can also offer help to anyone who tries this. It's also a good opportunity to let die drivers that have no committed users.

Just to be clear on why we're doing this: the NCR53C9x driver on which these are all based is in a pretty horrendous state of repair. The esp_scsi one is much nicer, actually nicely tested and has a host of features the old driver didn't. However, the principle driving force is the conversion of the SCSI subsystem to the sg_list accessors. esp_scsi is already coverted. NCR53C9x looks like a nasty job. Thus, the moment the conversion patch goes in, all your drivers will break. However, since breakage excites a whole bunch of kernel compile checkers (and lands me with a flood of email), I'm prepared to remove them to prevent this from happening ... unless we can get them converted over to esp_scsi.

I'll put the removal in the scsi-pending tree, so it won't be picked up by -mm, but we need to get this situation resolved by 2.6.25 at the latest.

James

Hi all,

I can look into converting some (having worked on the m68k Mac ESP driver in the past - I do recall the Mac driver needs special hacks so it won't be the easiest one to convert). I have no hardware to test these on, however.

Hasn't this come up before on linux-m68k? Someone asked me for information when converting the Mac driver, I think. That could be a good start.

I'll contact you about this, then.

Hmm, does that also affect another of the m68k drivers, the 5380 one? More headache for me...

Michael

From: Geert Uytterhoeven <[email protected]>
Date: Thu, 3 Jan 2008 20:05:27 +0100 (CET)

We can't wait forever, and effort spent maintaining the old rotting drivers is effort that should instead be spent on the converted new drivers.

Instead of seeing conversions being written, we've been hearing this swan song from the m68k crowd forever, it's getting quite old.

I totally object to keeping these things around any longer. And this I support these changes going in.

quite old == the new esp_scsi arrived in April 2007. On the m68k timescale, this is just a split-second ago. Following this logic, it's a surprise OSS hasn't been removed completely ;-)

BTW, I hope you do remember why NCR53C9x.[ch] incarnated in the first place...

OK, we'll see what we can do...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

I have a partially written replacement for mac_esp. Unlike the other NCR53C9x drivers it needs PIO or pseudo DMA depending on the machine -- so it is not as straight-forward as jazz_esp. The new esp_scsi core assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released.

Finn

From: Finn Thain <[email protected]>
Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST)

It does actually support such things.

You can hide it completely your ->irq_pending() handler. Process any pending pseudo DMA and return 0 until there is a pseudo DMA error or the pseudo DMA is complete and the ESP is signalling an IRQ.

Does it? When I looked at this around 2.6.22, I found that esp_scsi would always negotiate sync transfers if the target supported that. PIO cannot do sync transfers, so I had to modify esp_scsi in order that the chip's Synchronous Offset register was set to zero (asynch).

I didn't attempt any processing in irq_pending. I'll look into it.

Finn

Hi All,

At the end of this message is the replacement mac_esp driver I've been working on. It isn't finished but it works fine.

The only remaining concerns I have are some of the changes to esp_scsi:
firstly I'm hoping that there's a better way to negotiate async transfers, and secondly I'm unsure about exporting esp_dma_length_limit (perhaps it would be better just to add an integer to struct esp for that value? The other front-ends could leave it zeroed for the original behaviour.)

David, some more discussion of the asynch problem follows...

I think it would be better to bypass Domain Validation for PIO. The hack I used (ESP_FLAG_DISABLE_SYNC) is a bit messy because it seems to confuse domain validation. For example, here's the log from probing the bus:

mac_esp: using PIO for controller 0
esp: esp0, regs[50f18000:0] irq[19]
esp: esp0 is a ESP236, 25 MHz (ccf=5), SCSI ID 7
scsi0 : esp
scsi 0:0:3:0: CD-ROM MATSHITA CD-ROM CR-8004 1.0p PQ: 0
ANSI: 2
target0:0:3: Beginning Domain Validation
target0:0:3: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e048] len[00000000]
target0:0:3: Domain Validation detected failure, dropping back target0:0:3: asynchronous
target0:0:3: Domain Validation skipping write tests target0:0:3: Ending Domain Validation
scsi 0:0:6:0: Direct-Access QUANTUM LPS540S 590S PQ: 0
ANSI: 2 CCS
target0:0:6: Beginning Domain Validation
target0:0:6: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e104] len[00000000]
target0:0:6: Domain Validation detected failure, dropping back target0:0:6: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e104] len[00000000]
target0:0:6: Domain Validation detected failure, dropping back target0:0:6: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e104] len[00000000]
target0:0:6: Domain Validation detected failure, dropping back target0:0:6: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e104] len[00000000]
target0:0:6: Domain Validation detected failure, dropping back target0:0:6: asynchronous
mac_esp: FIFO is empty (sreg 81).
esp: esp0: DMA length is zero!
esp: esp0: cur adr[0050e104] len[00000000]
target0:0:6: Domain Validation Failure, dropping back to Asynchronous target0:0:6: Domain Validation skipping write tests target0:0:6: Ending Domain Validation
sd 0:0:6:0: [sda] 1057616 512-byte hardware sectors (541 MB) sd 0:0:6:0: [sda] Write Protect is off
sd 0:0:6:0: [sda] Mode Sense: 93 00 00 08
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:6:0: [sda] 1057616 512-byte hardware sectors (541 MB) sd 0:0:6:0: [sda] Write Protect is off
sd 0:0:6:0: [sda] Mode Sense: 93 00 00 08
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6
sda: p6 exceeds device capacity
sd 0:0:6:0: [sda] Attached SCSI disk

...which may be inefficient but it is a lot quicker than waiting for command timeouts, which is what happens without my hack:

[snipped first part of validation and half a dozen command timeouts]

target0:0:6: Domain Validation detected failure, dropping back target0:0:6: FAST-5 SCSI 1.5 MB/s ST (672 ns, offset 8)
mac_esp: IRQ timeout (sreg 01).
esp: esp0: Aborting command [0045ccb0:12]
esp: esp0: Current command [0045ccb0:12]
esp: esp0: Active command [0045ccb0:12]
esp: esp0: Dumping command log
esp: esp0: ent[3] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[4] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[5] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[6] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[7] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[8] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[9] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[10] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[11] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[12] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[13] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[14] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[15] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[16] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[17] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[18] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[19] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[20] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[21] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[22] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[23] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[24] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[25] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[26] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[27] EVENT val[01] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[28] CMD val[01] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[29] CMD val[10] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[30] EVENT val[02] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[31] EVENT val[0d] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
esp: esp0: ent[0] EVENT val[03] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[1] CMD val[10] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[03]
esp: esp0: ent[2] EVENT val[05] sreg[01] seqreg[01] sreg2[00] ireg[10] ss[00] event[03]
target0:0:6: FAST-5 SCSI 1.5 MB/s ST (672 ns, offset 8)
target0:0:6: Domain Validation detected failure, dropping back target0:0:6: FAST-5 SCSI 1.0 MB/s ST (1008 ns, offset 8)
mac_esp: IRQ timeout (sreg 01).
esp: esp0: Aborting command [0045ccb0:12]
esp: esp0: Current command [0045ccb0:12]
esp: esp0: Active command [0045ccb0:12]
esp: esp0: Dumping command log
esp: esp0: ent[1] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[2] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[3] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[4] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[5] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[6] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[7] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[8] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[9] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[10] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[11] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[12] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[13] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[14] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[15] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[16] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[17] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[18] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[19] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[20] EVENT val[06] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[21] CMD val[01] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[22] CMD val[10] sreg[87] seqreg[01] sreg2[00] ireg[10] ss[00] event[06]
esp: esp0: ent[23] CMD val[12] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[24] EVENT val[0d] sreg[87] seqreg[01] sreg2[00] ireg[08] ss[00] event[06]
esp: esp0: ent[25] EVENT val[01] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[26] CMD val[01] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[27] CMD val[10] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[28] EVENT val[02] sreg[82] seqreg[01] sreg2[00] ireg[10] ss[00] event[01]
esp: esp0: ent[29] EVENT val[0d] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[02]
esp: esp0: ent[30] EVENT val[03] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[0d]
esp: esp0: ent[31] CMD val[10] sreg[81] seqreg[01] sreg2[00] ireg[10] ss[00] event[03]
esp: esp0: ent[0] EVENT val[05] sreg[01] seqreg[01] sreg2[00] ireg[10] ss[00] event[03]
target0:0:6: FAST-5 SCSI 1.0 MB/s ST (1008 ns, offset 8)
target0:0:6: Domain Validation Failure, dropping back to Asynchronous target0:0:6: Domain Validation skipping write tests
target0:0:6: Ending Domain Validation
target0:0:6: asynchronous

Well, I've looked into it. It turns out that I can't report an error from irq_pending() because it is never called. What happens is that the domain validation algorithm will issue a synchronous command (like a 36 byte read from the CDROM drive) but, given only PIO, the chip raises no interrupt:

mac_esp: using PIO for controller 0
esp: esp0, regs[50f18000:0] irq[19]
esp: esp0 is a ESP236, 25 MHz (ccf=5), SCSI ID 7
scsi0 : esp

scsi 0:0:3:0: CD-ROM MATSHITA CD-ROM CR-8004 1.0p PQ: 0 ANSI: 2
target0:0:3: Beginning Domain Validation

target0:0:3: FAST-5 SCSI 2.1 MB/s ST (472 ns, offset 8)

mac_esp: IRQ timeout (sreg 01).
esp: esp0: Aborting command [004e0cb0:12]
esp: esp0: Current command [004e0cb0:12]
esp: esp0: Active command [004e0cb0:12]
esp: esp0: Dumping command log
...

Hence the ESP_FLAG_DISABLE_SYNC hack... but I have to wonder, is there no better way to short circuit domain validation?

Cheers,
Finn

---
 drivers/scsi/Makefile    |    1 
 drivers/scsi/esp_scsi.c  |   27 +
 drivers/scsi/esp_scsi.h  |    9 
 drivers/scsi/jazz_esp.c  |   25 -
 drivers/scsi/mac_esp.c   |  650 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/sun_esp.c   |   25 -
 drivers/scsi/sun3x_esp.c |   25 -
 6 files changed, 700 insertions(+), 37 deletions(-)

Index: linux-2.6.22/drivers/scsi/esp_scsi.c
===================================================================
@@ -477,7 +477,7 @@ static void esp_write_tgt_sync(struct es
 	}
 }
 
-static u32 esp_dma_length_limit(struct esp *esp, u32 dma_addr, u32 dma_len)
+u32 esp_dma_length_limit(struct esp *esp, u32 dma_addr, u32 dma_len)
 {
 	if (esp->rev == FASHME) {
 		/* Arbitrary segment boundaries, 24-bit counts.  */

@@ -506,6 +506,7 @@ static u32 esp_dma_length_limit(struct e
 	}
 	return dma_len;
 }
+EXPORT_SYMBOL(esp_dma_length_limit);
 
 static int esp_need_to_nego_wide(struct esp_target_data *tp)
 {

@@ -982,7 +983,7 @@ static int esp_check_spur_intr(struct es
 			 */
 			if (!esp->ops->dma_error(esp)) {
 				printk(KERN_ERR PFX "esp%d: Spurious irq, "
-				       "sreg=%x.\n",
+				       "sreg=%02x.\n",
 				       esp->host->unique_id, esp->sreg);
 				return -1;
 			}

@@ -1451,6 +1452,9 @@ static void esp_msgin_sdtr(struct esp *e
 	if (offset > 15)
 		goto do_reject;
 
+	if (esp->flags & ESP_FLAG_DISABLE_SYNC)
+		offset = 0;
+
 	if (offset) {
 		int rounded_up, one_clock;
 

@@ -1701,7 +1705,7 @@ again:
 		else
 			ent->flags &= ~ESP_CMD_FLAG_WRITE;
 
-		dma_len = esp_dma_length_limit(esp, dma_addr, dma_len);
+		dma_len = esp->ops->dma_length_limit(esp, dma_addr, dma_len);
 		esp->data_dma_len = dma_len;
 
 		if (!dma_len) {

@@ -1765,7 +1769,6 @@ again:
 		esp_advance_dma(esp, ent, cmd, bytes_sent);
 		esp_event(esp, ESP_EVENT_CHECK_PHASE);
 		goto again;
-		break;
 	}
 
 	case ESP_EVENT_STATUS: {

@@ -2239,7 +2242,7 @@ static void esp_bootup_reset(struct esp 
 
 static void __devinit esp_set_clock_params(struct esp *esp)
 {
-	int fmhz;
+	int fhz;
 	u8 ccf;
 
 	/* This is getting messy but it has to be done correctly or else

@@ -2274,9 +2277,9 @@ static void __devinit esp_set_clock_para
 	 *    This entails the smallest and largest sync period we could ever
 	 *    handle on this ESP.
 	 */
-	fmhz = esp->cfreq;
+	fhz = esp->cfreq;
 
-	ccf = ((fmhz / 1000000) + 4) / 5;
+	ccf = ((fhz / 1000000) + 4) / 5;
 	if (ccf == 1)
 		ccf = 2;
 

@@ -2285,16 +2288,16 @@ static void __devinit esp_set_clock_para
 	 * been unable to find the clock-frequency PROM property.  All
 	 * other machines provide useful values it seems.
 	 */
-	if (fmhz <= 5000000 || ccf < 1 || ccf > 8) {
-		fmhz = 20000000;
+	if (fhz <= 5000000 || ccf < 1 || ccf > 8) {
+		fhz = 20000000;
 		ccf = 4;
 	}
 
 	esp->cfact = (ccf == 8 ? 0 : ccf);
-	esp->cfreq = fmhz;
-	esp->ccycle = ESP_MHZ_TO_CYCLE(fmhz);
+	esp->cfreq = fhz;
+	esp->ccycle = ESP_HZ_TO_CYCLE(fhz);
 	esp->ctick = ESP_TICK(ccf, esp->ccycle);
-	esp->neg_defp = ESP_NEG_DEFP(fmhz, ccf);
+	esp->neg_defp = ESP_NEG_DEFP(fhz, ccf);
 	esp->sync_defp = SYNC_DEFP_SLOW;
 }
 

Index: linux-2.6.22/drivers/scsi/esp_scsi.h
===================================================================
@@ -224,7 +224,7 @@
 #define ESP_TIMEO_CONST       8192
 #define ESP_NEG_DEFP(mhz, cfact) \
         ((ESP_BUS_TIMEOUT * ((mhz) / 1000)) / (8192 * (cfact)))
-#define ESP_MHZ_TO_CYCLE(mhertz)  ((1000000000) / ((mhertz) / 1000))
+#define ESP_HZ_TO_CYCLE(hertz)  ((1000000000) / ((hertz) / 1000))
 #define ESP_TICK(ccf, cycle)  ((7682 * (ccf) * (cycle) / 1000))
 
 /* For slow to medium speed input clock rates we shoot for 5mb/s, but for high

@@ -368,6 +368,12 @@ struct esp_driver_ops {
 	 */
 	int (*irq_pending)(struct esp *esp);
 
+	/* Return the maximum allowable size of a DMA transfer for a
+	 * given buffer.
+	 */
+	u32 (*dma_length_limit)(struct esp *esp, u32 dma_addr,
+	                        u32 dma_len);
+
 	/* Reset the DMA engine entirely.  On return, ESP interrupts
 	 * should be enabled.  Often the interrupt enabling is
 	 * controlled in the DMA engine.

@@ -471,6 +477,7 @@ struct esp {
 #define ESP_FLAG_DOING_SLOWCMD	0x00000004
 #define ESP_FLAG_WIDE_CAPABLE	0x00000008
 #define ESP_FLAG_QUICKIRQ_CHECK	0x00000010
+#define ESP_FLAG_DISABLE_SYNC	0x00000020
 
 	u8			select_state;
 #define ESP_SELECT_NONE		0x00 /* Not selecting */

Index: linux-2.6.22/drivers/scsi/Makefile
===================================================================
@@ -52,6 +52,7 @@ obj-$(CONFIG_FASTLANE_SCSI)	+= NCR53C9x.
 obj-$(CONFIG_OKTAGON_SCSI)	+= NCR53C9x.o	oktagon_esp_mod.o
 obj-$(CONFIG_ATARI_SCSI)	+= atari_scsi.o
 obj-$(CONFIG_MAC_SCSI)		+= mac_scsi.o
+obj-$(CONFIG_SCSI_MAC_ESP)	+= esp_scsi.o	mac_esp.o
 obj-$(CONFIG_SUN3_SCSI)		+= sun3_scsi.o  sun3_scsi_vme.o
 obj-$(CONFIG_MVME16x_SCSI)	+= 53c700.o	mvme16x_scsi.o
 obj-$(CONFIG_BVME6000_SCSI)	+= 53c700.o	bvme6000_scsi.o

Index: linux-2.6.22/drivers/scsi/sun_esp.c
===================================================================
@@ -461,18 +461,19 @@ static int sbus_esp_dma_error(struct esp
 }
 
 static const struct esp_driver_ops sbus_esp_ops = {
-	.esp_write8	=	sbus_esp_write8,
-	.esp_read8	=	sbus_esp_read8,
-	.map_single	=	sbus_esp_map_single,
-	.map_sg		=	sbus_esp_map_sg,
-	.unmap_single	=	sbus_esp_unmap_single,
-	.unmap_sg	=	sbus_esp_unmap_sg,
-	.irq_pending	=	sbus_esp_irq_pending,
-	.reset_dma	=	sbus_esp_reset_dma,
-	.dma_drain	=	sbus_esp_dma_drain,
-	.dma_invalidate	=	sbus_esp_dma_invalidate,
-	.send_dma_cmd	=	sbus_esp_send_dma_cmd,
-	.dma_error	=	sbus_esp_dma_error,
+	.esp_write8       =	sbus_esp_write8,
+	.esp_read8        =	sbus_esp_read8,
+	.map_single       =	sbus_esp_map_single,
+	.map_sg           =	sbus_esp_map_sg,
+	.unmap_single     =	sbus_esp_unmap_single,
+	.unmap_sg         =	sbus_esp_unmap_sg,
+	.irq_pending      =	sbus_esp_irq_pending,
+	.dma_length_limit =	esp_dma_length_limit,
+	.reset_dma        =	sbus_esp_reset_dma,
+	.dma_drain        =	sbus_esp_dma_drain,
+	.dma_invalidate   =	sbus_esp_dma_invalidate,
+	.send_dma_cmd     =	sbus_esp_send_dma_cmd,
+	.dma_error        =	sbus_esp_dma_error,
 };
 
 static int __devinit esp_sbus_probe_one(struct device *dev,

Index: linux-2.6.22/drivers/scsi/jazz_esp.c
===================================================================
@@ -114,18 +114,19 @@ static int jazz_esp_dma_error(struct esp
 }
 
 static const struct esp_driver_ops jazz_esp_ops = {
-	.esp_write8	=	jazz_esp_write8,
-	.esp_read8	=	jazz_esp_read8,
-	.map_single	=	jazz_esp_map_single,
-	.map_sg		=	jazz_esp_map_sg,
-	.unmap_single	=	jazz_esp_unmap_single,
-	.unmap_sg	=	jazz_esp_unmap_sg,
-	.irq_pending	=	jazz_esp_irq_pending,
-	.reset_dma	=	jazz_esp_reset_dma,
-	.dma_drain	=	jazz_esp_dma_drain,
-	.dma_invalidate	=	jazz_esp_dma_invalidate,
-	.send_dma_cmd	=	jazz_esp_send_dma_cmd,
-	.dma_error	=	jazz_esp_dma_error,
+	.esp_write8       =	jazz_esp_write8,
+	.esp_read8        =	jazz_esp_read8,
+	.map_single       =	jazz_esp_map_single,
+	.map_sg           =	jazz_esp_map_sg,
+	.unmap_single     =	jazz_esp_unmap_single,
+	.unmap_sg         =	jazz_esp_unmap_sg,
+	.irq_pending      =	jazz_esp_irq_pending,
+	.dma_length_limit =	esp_dma_length_limit,
+	.reset_dma        =	jazz_esp_reset_dma,
+	.dma_drain        =	jazz_esp_dma_drain,
+	.dma_invalidate   =	jazz_esp_dma_invalidate,
+	.send_dma_cmd     =	jazz_esp_send_dma_cmd,
+	.dma_error        =	jazz_esp_dma_error,
 };
 
 static int __devinit esp_jazz_probe(struct platform_device *dev)

Index: linux/drivers/scsi/sun3x_esp.c
===================================================================
@@ -179,18 +179,19 @@ static int sun3x_esp_dma_error(struct es
 }
 
 static const struct esp_driver_ops sun3x_esp_ops = {
-	.esp_write8	=	sun3x_esp_write8,
-	.esp_read8	=	sun3x_esp_read8,
-	.map_single	=	sun3x_esp_map_single,
-	.map_sg		=	sun3x_esp_map_sg,
-	.unmap_single	=	sun3x_esp_unmap_single,
-	.unmap_sg	=	sun3x_esp_unmap_sg,
-	.irq_pending	=	sun3x_esp_irq_pending,
-	.reset_dma	=	sun3x_esp_reset_dma,
-	.dma_drain	=	sun3x_esp_dma_drain,
-	.dma_invalidate	=	sun3x_esp_dma_invalidate,
-	.send_dma_cmd	=	sun3x_esp_send_dma_cmd,
-	.dma_error	=	sun3x_esp_dma_error,
+	.esp_write8       =	sun3x_esp_write8,
+	.esp_read8        =	sun3x_esp_read8,
+	.map_single       =	sun3x_esp_map_single,
+	.map_sg           =	sun3x_esp_map_sg,
+	.unmap_single     =	sun3x_esp_unmap_single,
+	.unmap_sg         =	sun3x_esp_unmap_sg,
+	.irq_pending      =	sun3x_esp_irq_pending,
+	.dma_length_limit =	esp_dma_length_limit,
+	.reset_dma        =	sun3x_esp_reset_dma,
+	.dma_drain        =	sun3x_esp_dma_drain,
+	.dma_invalidate   =	sun3x_esp_dma_invalidate,
+	.send_dma_cmd     =	sun3x_esp_send_dma_cmd,
+	.dma_error        =	sun3x_esp_dma_error,
 };
 
 static int __devinit esp_sun3x_probe(struct platform_device *dev)

I'll have a look at this. I can only test it on Blizzard 1260 hardware though.

Kind regards,

Kars.

OK, time's up.

These drivers are now unbuildable in mainline because of the promised sg_table updates. They either get removed, fixed or marked as BROKEN. Which is it to be?

James

Is git smart enough to follow history between files that get removed and readded?
If yes, I think you can remove them.
If no, please mark them as BROKEN.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

I did submit a fix to all these drivers, but It was said by people that these drivers should not be fixed because they have a better alternative with the other esp family. And any devices not supported by the other family should be not more then a day of work to support. So doing the better job of supporting them in the new form is less effort then resurrecting junk code from the graveyard.

I say dump it. Christoph ??!

Boaz

Yes. git revert on the removal changeset will re-add all the files and try to put the entries back into Kconfig and Makefile.

OK ... I'll wave the magic wand.

James

Note that it doesn't really matter. Looking at the existing conversion there's been no line left the same except for the standard #include statements.