Remove of old NCR53C9x/esp family of drivers
cover 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
PATCH 1/1 Remove of old NCR53C9x/esp family of drivers
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
drivers/scsi/Kconfig +0 -85
@@ -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
drivers/scsi/Makefile +0 -11
@@ -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
drivers/scsi/NCR53C9x.c deleted +0 -3654
2,837 lines not on this page · raw message
drivers/scsi/NCR53C9x.h deleted +0 -668
668 lines not on this page · raw message
drivers/scsi/blz1230.c deleted +0 -353
353 lines not on this page · raw message
drivers/scsi/blz2060.c deleted +0 -306
306 lines not on this page · raw message
drivers/scsi/cyberstorm.c deleted +0 -377
377 lines not on this page · raw message
drivers/scsi/cyberstormII.c deleted +0 -314
314 lines not on this page · raw message
drivers/scsi/dec_esp.c deleted +0 -687
687 lines not on this page · raw message
drivers/scsi/fastlane.c deleted +0 -421
421 lines not on this page · raw message
drivers/scsi/mac_esp.c deleted +0 -751
751 lines not on this page · raw message
drivers/scsi/mca_53c9x.c deleted +0 -520
520 lines not on this page · raw message
drivers/scsi/oktagon_esp.c deleted +0 -606
606 lines not on this page · raw message
drivers/scsi/oktagon_io.S deleted +0 -194
194 lines not on this page · raw message
drivers/scsi/sun3x_esp.c deleted +0 -392
392 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
1.5.3.3
Part of the diff is not shown here. View the raw message.
James Bottomley
maintainerQuoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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
Quoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/Makefile
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
Quoted 20 lines · James Bottomley
Quoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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
Quoted 6 lines
Quoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/MakefileOK, 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.
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
James Bottomley
maintainerQuoted 34 lines · Geert Uytterhoeven
Quoted 20 lines · James Bottomley
Quoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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.cQuoted 6 lines
Quoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/MakefileOK, 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.
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:
Quoted 7 lines
commit
5ff263667798946abc15314eae3f341345877d7aAuthor: Thomas Bogendoerfer <[email protected]> Date: Tue May 22 17:03:44 2007 -0700[SCSI]
jazz_esp: Converted to useesp_core.Use new
esp_scsifor JAZZ SCSI host adapter driver
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
David Miller
Acked-byFrom: Geert Uytterhoeven <[email protected]>
Date: Thu, 3 Jan 2008 20:05:27 +0100 (CET)
Quoted 24 lines · James Bottomley
Quoted 23 lines · Boaz Harrosh
Quoted 21 lines
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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
Quoted 7 lines
Quoted 3 lines
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.
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...
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.
Hi all,
Quoted 3 lines
Quoted 3 lines
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...
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.
Quoted 9 lines
Quoted 9 lines
You can use the following as guidance:
commit
5ff263667798946abc15314eae3f341345877d7aAuthor: Thomas Bogendoerfer <[email protected]> Date: Tue May 22 17:03:44 2007 -0700[SCSI]
jazz_esp: Converted to useesp_core.Use new
esp_scsifor JAZZ SCSI host adapter driver
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.
Quoted 2 lines
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.
I'll contact you about this, then.
Quoted 7 lines
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_scsione 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 thesg_listaccessors.esp_scsiis already coverted. NCR53C9x looks like a nasty job. Thus, the moment the conversion patch goes in, all your drivers will break. However,
Hmm, does that also affect another of the m68k drivers, the 5380 one? More headache for me...
Michael
Quoted 33 lines · David Miller
From: Geert Uytterhoeven <[email protected]>
Quoted 24 lines · James Bottomley
Quoted 23 lines · Boaz Harrosh
Quoted 21 lines
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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/MakefileQuoted 7 lines
Quoted 3 lines
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.
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...
Quoted 6 lines
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.
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 ;-)
Quoted 2 lines
I totally object to keeping these things around any longer. And this I support these changes going in.
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
Quoted 8 lines · Geert Uytterhoeven
Quoted 3 lines
I totally object to keeping these things around any longer. And this I support these changes going in.
BTW, I hope you do remember why NCR53C9x.[ch] incarnated in the first place...
OK, we'll see what we can do...
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
Quoted 4 lines
Gr{oetje,eeting}s,
Geert
From: Finn Thain <[email protected]>
Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST)
Quoted 5 lines
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 asjazz_esp. The newesp_scsicore assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released.
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.
Quoted 10 lines · David Miller
From: Finn Thain <[email protected]>
Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST)Quoted 5 lines
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 asjazz_esp. The newesp_scsicore assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released.It does actually support such things.
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).
Quoted 3 lines
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.
I didn't attempt any processing in irq_pending. I'll look into it.
Finn
Quoted 5 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 24 lines · Geert Uytterhoeven
Quoted 23 lines · James Bottomley
Quoted 21 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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
Quoted 7 lines
Quoted 3 lines
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.
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...
I'll have a look at this. I can only test it on Blizzard 1260 hardware though.
Kind regards,
Kars.
James Bottomley
maintainerQuoted 29 lines · Kars de Jong
Quoted 28 lines · Geert Uytterhoeven
Quoted 26 lines · James Bottomley
Quoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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.cQuoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/MakefileOK, 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.
Quoted 6 lines
Quoted 3 lines
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...
I'll have a look at this. I can only test it on Blizzard 1260 hardware though.
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
Quoted 34 lines · James Bottomley
Quoted 33 lines · Kars de Jong
Quoted 31 lines · Geert Uytterhoeven
Quoted 20 lines · James Bottomley
Quoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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.cQuoted 6 lines
Quoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/MakefileOK, 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.
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...
Quoted 8 lines
Quoted 2 lines
I'll have a look at this. I can only test it on Blizzard 1260 hardware though.
OK, time's up.
These drivers are now unbuildable in mainline because of the promised
sg_tableupdates. They either get removed, fixed or marked as BROKEN. Which is it to be?
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
Quoted 49 lines · Geert Uytterhoeven
Quoted 31 lines · James Bottomley
Quoted 30 lines · Kars de Jong
Quoted 29 lines · Geert Uytterhoeven
Quoted 20 lines · James Bottomley
Quoted 19 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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.cQuoted 5 lines
Quoted 2 lines
- Remove above list from
drivers/scsi/Kconfig&&drivers/scsi/MakefileOK, 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.
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...
Quoted 7 lines
Quoted 2 lines
I'll have a look at this. I can only test it on Blizzard 1260 hardware though.
OK, time's up.
These drivers are now unbuildable in mainline because of the promised
sg_tableupdates. They either get removed, fixed or marked as BROKEN. Which is it to be?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
Quoted 7 lines
--
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
James Bottomley
maintainerQuoted 38 lines · Geert Uytterhoeven
Quoted 37 lines · James Bottomley
Quoted 35 lines · Kars de Jong
Quoted 24 lines · Geert Uytterhoeven
Quoted 23 lines · James Bottomley
Quoted 21 lines · Boaz Harrosh
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'sesp_scsi- Remove all driver files dependent on
NCR53C9x.cdeleted: 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/MakefileQuoted 7 lines
Quoted 3 lines
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.
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...
I'll have a look at this. I can only test it on Blizzard 1260 hardware though.
Quoted 8 lines
Quoted 5 lines
OK, time's up.
These drivers are now unbuildable in mainline because of the promised
sg_tableupdates. They either get removed, fixed or marked as BROKEN. Which is it to be?Is git smart enough to follow history between files that get removed and readded?
Yes. git revert on the removal changeset will re-add all the files and try to put the entries back into Kconfig and Makefile.
Quoted 2 lines
If yes, I think you can remove them.
If no, please mark them as BROKEN.
OK ... I'll wave the magic wand.
James
Quoted 5 lines · James Bottomley
Quoted 2 lines
Is git smart enough to follow history between files that get removed and readded?
Yes. git revert on the removal changeset will re-add all the files and try to put the entries back into
KconfigandMakefile.
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.
mac_esp and PIO, was Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
In reply to Finn ThainHi 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...
Quoted 12 lines · On Sat, 5 Jan 2008, I wrote:
Quoted 9 lines · David Miller
From: Finn Thain <[email protected]>
Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST)Quoted 5 lines
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 asjazz_esp. The newesp_scsicore assumes DMA and doesn't support asynch transfers. But I'll try to get it finished before 2.6.25 is released.
Quoted 6 lines
Quoted 1 line
It does actually support such things.
Does it? When I looked at this around 2.6.22, I found that
esp_scsiwould always negotiate sync transfers if the target supported that. PIO cannot do sync transfers, so I had to modifyesp_scsiin order that the chip's Synchronous Offset register was set to zero (asynch).
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: asynchronousmac_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: asynchronousmac_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: asynchronousmac_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: asynchronousmac_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: asynchronousmac_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: asynchronousmac_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
Quoted 6 lines
Quoted 4 lines
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.
I didn't attempt any processing in
irq_pending. I'll look into it.
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
Quoted 5 lines
write 0, cmd
0xC2, fifo 0,esp_count7
write 0, cmd0xC2, fifo 7,esp_count7
write 0, cmd0xC2, fifo 7,esp_count7
write 0, cmd0xC2, fifo 7,esp_count7
write 1, cmd0x90, fifo 0,esp_count36
scsi 0:0:3:0: CD-ROM MATSHITA CD-ROM CR-8004 1.0p PQ: 0 ANSI: 2
target0:0:3: Beginning Domain Validation
Quoted 10 lines
write 0, cmd
0xC2, fifo 0,esp_count7
write 1, cmd0x90, fifo 0,esp_count36
write 0, cmd0xC2, fifo 0,esp_count7
write 1, cmd0x90, fifo 0,esp_count36
write 0, cmd0xC2, fifo 0,esp_count7
write 1, cmd0x90, fifo 0,esp_count36
write 0, cmd0xC2, fifo 0,esp_count7
write 1, cmd0x90, fifo 0,esp_count36
write 0, cmd0xC3, fifo 0,esp_count1
write 0, cmd0x90, fifo 0,esp_count5
target0:0:3: FAST-5 SCSI 2.1 MB/s ST (472 ns, offset 8)
Quoted 2 lines
write 0, cmd
0x90, fifo 0,esp_count6
write 1, cmd0x90, fifo 0,esp_count36
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(-)
drivers/scsi/esp_scsi.c +15 -12
@@ -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 *eif (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 espstatic 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 ; }
drivers/scsi/esp_scsi.h +8 -1
@@ -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 0x00000020u8 select_state;#define ESP_SELECT_NONE 0x00/* Not selecting */
drivers/scsi/Makefile +1 -0
@@ -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
drivers/scsi/mac_esp.c new file +653 -0
653 lines not on this page · raw message
drivers/scsi/sun_esp.c +13 -12
@@ -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,
drivers/scsi/jazz_esp.c +13 -12
@@ -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)
drivers/scsi/sun3x_esp.c +13 -12
@@ -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)