mac_esp and PIO, was Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
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... On Sat, 5 Jan 2008, I wrote: On Fri, 4 Jan 2008, David Miller wrote: From: Finn Thain [EMAIL PROTECTED] Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST) 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. 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). 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-ROMMATSHITA 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[] 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[] 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[] 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[] 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[] 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[] 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:
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, Jan 31, 2008 at 01:31:56PM -0600, James Bottomley wrote: 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. 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. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Mon, 2008-01-07 at 07:07 +0100, Kars de Jong wrote: On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote: On Thu, 3 Jan 2008, James Bottomley wrote: On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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. 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 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, Jan 31 2008 at 20:55 +0200, Geert Uytterhoeven [EMAIL PROTECTED]
wrote:
On Thu, 31 Jan 2008, James Bottomley wrote:
On Mon, 2008-01-07 at 07:07 +0100, Kars de Jong wrote:
On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote:
On Thu, 3 Jan 2008, James Bottomley wrote:
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
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
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.
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?
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
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 31 Jan 2008, James Bottomley wrote:
On Mon, 2008-01-07 at 07:07 +0100, Kars de Jong wrote:
On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote:
On Thu, 3 Jan 2008, James Bottomley wrote:
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
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
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.
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?
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
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 2008-01-31 at 19:55 +0100, Geert Uytterhoeven wrote: On Thu, 31 Jan 2008, James Bottomley wrote: On Mon, 2008-01-07 at 07:07 +0100, Kars de Jong wrote: On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote: On Thu, 3 Jan 2008, James Bottomley wrote: On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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. 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? 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. If yes, I think you can remove them. If no, please mark them as BROKEN. OK ... I'll wave the magic wand. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote: On Thu, 3 Jan 2008, James Bottomley wrote: On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Fri, 4 Jan 2008, Geert Uytterhoeven wrote:
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
Gr{oetje,eeting}s,
Geert
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 3 Jan 2008, David Miller wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
On Thu, 3 Jan 2008, James Bottomley wrote:
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
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
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.
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 ;-)
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
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
From: Finn Thain [EMAIL PROTECTED] Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST) 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. 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. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Fri, 4 Jan 2008, David Miller wrote: From: Finn Thain [EMAIL PROTECTED] Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST) 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. 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). 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 - 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 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 3 Jan 2008, James Bottomley wrote:
On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
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
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...
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
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote: On Thu, 3 Jan 2008, James Bottomley wrote: On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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... 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 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 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
From: Geert Uytterhoeven [EMAIL PROTECTED] Date: Thu, 3 Jan 2008 20:05:27 +0100 (CET) On Thu, 3 Jan 2008, James Bottomley wrote: On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote: 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 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. Acked-by: David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
Hi all, 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. 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 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 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. 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, Hmm, does that also affect another of the m68k drivers, the 5380 one? More headache for me... Michael - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
