Removing BROKEN scsi drivers

Removing BROKEN scsi drivers

[Andi Kleen]

In 2.6.14rc3:

linux/drivers/scsi> grep -c BROKEN Kconfig
11

There are a lot of SCSI drivers who have been marked BROKEN forever. Or at 
least for all of 2.6 and one would expect if there are users left they would 
have fixed them by now. Would it make sense to remove them?

In particular:

SCSI_ADVANSYS - vendor went out of market afaik. Probably not many left.
SCSI_CPQFCTS - suboption of another driver, incredibly ugly code defying all 
coding standards.
SCSI_EATA_PIO - really old ISA cards. Probably all left over cards are way 
over their MTBF by now.
SCSI_SEAGATE - extremly scary code, i doubt there is any such card left
SCSI_MCA_53C9X - BROKEN_ON_SMP only. Ok I guess there are no SMP
Micro Channel systems.
SCSI_QLOGIC_ISP - afaik there is a newer driver for this
SCSI_AMIGA7XX - no maintainer, broken forever
ATARI_SCSI - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same
SUN3_SCSI - sun3 never worked in mainline anyways

I think they could all go except perhaps the MCA driver. Or at least added
to Documentation/feature-removal-schedule.txt and then removed in a few 
months.

-Andi 

Re: Removing BROKEN scsi drivers

[Arjan van de Ven]

On Wed, 2005-10-05 at 13:14 +0200, Andi Kleen wrote:
> In 2.6.14rc3:
> 
> linux/drivers/scsi> grep -c BROKEN Kconfig
> 11
> 
> There are a lot of SCSI drivers who have been marked BROKEN forever. Or at 
> least for all of 2.6 and one would expect if there are users left they would 
> have fixed them by now. Would it make sense to remove them?

I'd say so yes


> I think they could all go except perhaps the MCA driver. Or at least added
> to Documentation/feature-removal-schedule.txt and then removed in a few 
> months.

sounds like the feature-removal should be done now before 2.6.14, and
the removal right after 2.6.14 goes out (if anyone later wants to revive
a driver they can always find the driver in the 2.6.14 tarbal after all)

Re: Removing BROKEN scsi drivers

[Matthew Wilcox]

On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> SCSI_AMIGA7XX - no maintainer, broken forever
> MVME16x_SCSI - no maintainer, broken forever
> BVME6000_SCSI - same

I don't think there's any point in deleting these.  I'm not even sure
why they're marked BROKEN.  They share 99% of their code with drivers
which are working.  And I thought Richard Hirst was maintaining them ...

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > SCSI_AMIGA7XX - no maintainer, broken forever
> > MVME16x_SCSI - no maintainer, broken forever
> > BVME6000_SCSI - same
> 
> I don't think there's any point in deleting these.  I'm not even sure
> why they're marked BROKEN.  They share 99% of their code with drivers
> which are working.  And I thought Richard Hirst was maintaining them ...

They don't.  All these use the broken and obsolete 53c7xx driver, not
James new 53c700 core.  The driver should be easy to reimplement based
on the 53x700 for someone who has the hardware and cares about it.

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> SCSI_ADVANSYS - vendor went out of market afaik. Probably not many left.

there's quite a lot left.  And the driver isn't really broken, just not
converted to the proper dma mapping API.  It works okay on x86, but not
on the more advanced hardware.  I have a pending new driver for the wide
scsi advansys cards but it's stuck for me to get some new wide scsi disks.

> SCSI_CPQFCTS - suboption of another driver, incredibly ugly code defying all 
> coding standards.

cpqfc should go.  mkp is working on a proper driver for the hardware.

> SCSI_EATA_PIO - really old ISA cards. Probably all left over cards are way 
> over their MTBF by now.

absolutely.

> SCSI_SEAGATE - extremly scary code, i doubt there is any such card left
> SCSI_MCA_53C9X - BROKEN_ON_SMP only. Ok I guess there are no SMP
> Micro Channel systems.
> SCSI_QLOGIC_ISP - afaik there is a newer driver for this

yes, qla1280 supports the hardware.  the only thing missing is support
for reading settings from the nvram. someone who has a qla1020/qla1040
pci card should be able to port that over easily, but when I added support
for the chips I only had sgi hardware with onboard chips available that
didn't have the nvram.

> SCSI_AMIGA7XX - no maintainer, broken forever
> ATARI_SCSI - no maintainer, broken forever
> MVME16x_SCSI - no maintainer, broken forever
> BVME6000_SCSI - same
> SUN3_SCSI - sun3 never worked in mainline anyways

yes, we should probably kill them.  the 53c7xx core driver needs to die
and the users ported over to the 53c700 core.  sun3_scsi needs to be
reimplemented using the common 5380 core instead of it's own out of
date copy.

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Wed, Oct 05, 2005 at 12:39:25PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> > On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > > SCSI_AMIGA7XX - no maintainer, broken forever
> > > MVME16x_SCSI - no maintainer, broken forever
> > > BVME6000_SCSI - same
> > 
> > I don't think there's any point in deleting these.  I'm not even sure
> > why they're marked BROKEN.  They share 99% of their code with drivers
> > which are working.  And I thought Richard Hirst was maintaining them ...
> 
> They don't.  All these use the broken and obsolete 53c7xx driver, not
> James new 53c700 core.  The driver should be easy to reimplement based
> on the 53x700 for someone who has the hardware and cares about it.

I never claimed to maintain the amiga stuff, but you are right that they
all use the 53c7xx driver that I originally created.  The sensible thing
to do is to migrate those systems to use James 53c700 core, but it seems
wise to poll the linux-m68k list before removing them.  I don't do much
with my VME hardware these days but I know there have been patches
posted for the serial driver recently so maybe someone has the scsi
working.

Richard

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On wo, 2005-10-05 at 13:32 +0100, Richard Hirst wrote:
> On Wed, Oct 05, 2005 at 12:39:25PM +0100, Christoph Hellwig wrote:
> > On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> > > On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > > > SCSI_AMIGA7XX - no maintainer, broken forever
> > > > MVME16x_SCSI - no maintainer, broken forever
> > > > BVME6000_SCSI - same
> > > 
> > > I don't think there's any point in deleting these.  I'm not even sure
> > > why they're marked BROKEN.  They share 99% of their code with drivers
> > > which are working.  And I thought Richard Hirst was maintaining them ...
> > 
> > They don't.  All these use the broken and obsolete 53c7xx driver, not
> > James new 53c700 core.  The driver should be easy to reimplement based
> > on the 53x700 for someone who has the hardware and cares about it.
> 
> I never claimed to maintain the amiga stuff, but you are right that they
> all use the 53c7xx driver that I originally created.  The sensible thing
> to do is to migrate those systems to use James 53c700 core, but it seems
> wise to poll the linux-m68k list before removing them.  I don't do much
> with my VME hardware these days but I know there have been patches
> posted for the serial driver recently so maybe someone has the scsi
> working.

I have at least the 53c7xx driver and the MVME16X driver working, the
Amiga and BVME stuff is untested (but does compile).

I patched the 53c7xx core to get it to work again, but the patch is ugly
and uses some mid level SCSI driver internals, which it shouldn't. It's
currently only present in the m68k CVS repository.

Are you sure it's that easy to use the new 53c700 core? These boards all
have 53c710 chips, and are quite some changes in the 53c7xx driver
compared to the 53c8xx driver it originated from.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Wed, Oct 05, 2005 at 03:30:33PM +0200, Kars de Jong wrote:
> On wo, 2005-10-05 at 13:32 +0100, Richard Hirst wrote:
> > On Wed, Oct 05, 2005 at 12:39:25PM +0100, Christoph Hellwig wrote:
> > > On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> > > > On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > > > > SCSI_AMIGA7XX - no maintainer, broken forever
> > > > > MVME16x_SCSI - no maintainer, broken forever
> > > > > BVME6000_SCSI - same
> > > > 
> > > > I don't think there's any point in deleting these.  I'm not even sure
> > > > why they're marked BROKEN.  They share 99% of their code with drivers
> > > > which are working.  And I thought Richard Hirst was maintaining them ...
> > > 
> > > They don't.  All these use the broken and obsolete 53c7xx driver, not
> > > James new 53c700 core.  The driver should be easy to reimplement based
> > > on the 53x700 for someone who has the hardware and cares about it.
> > 
> > I never claimed to maintain the amiga stuff, but you are right that they
> > all use the 53c7xx driver that I originally created.  The sensible thing
> > to do is to migrate those systems to use James 53c700 core, but it seems
> > wise to poll the linux-m68k list before removing them.  I don't do much
> > with my VME hardware these days but I know there have been patches
> > posted for the serial driver recently so maybe someone has the scsi
> > working.
> 
> I have at least the 53c7xx driver and the MVME16X driver working, the
> Amiga and BVME stuff is untested (but does compile).

Great :-)

> I patched the 53c7xx core to get it to work again, but the patch is ugly
> and uses some mid level SCSI driver internals, which it shouldn't. It's
> currently only present in the m68k CVS repository.
> 
> Are you sure it's that easy to use the new 53c700 core? These boards all
> have 53c710 chips, and are quite some changes in the 53c7xx driver
> compared to the 53c8xx driver it originated from.

The 53c700 core code handles 53c710 as well, so it should be easy.  Not
that I've actually tried..

Richard

Re: Removing BROKEN scsi drivers

[James Bottomley]

On Wed, 2005-10-05 at 15:30 +0200, Kars de Jong wrote:
> I have at least the 53c7xx driver and the MVME16X driver working, the
> Amiga and BVME stuff is untested (but does compile).
> 
> I patched the 53c7xx core to get it to work again, but the patch is ugly
> and uses some mid level SCSI driver internals, which it shouldn't. It's
> currently only present in the m68k CVS repository.
> 
> Are you sure it's that easy to use the new 53c700 core? These boards all
> have 53c710 chips, and are quite some changes in the 53c7xx driver
> compared to the 53c8xx driver it originated from.

The 53c700 driver is a bit misnamed, it also has a 710 mode which is set
by a flag.  It's actually in common use driving three different
chipsets:

53c700: parisc 715 machines
53c700-66: Voyager systems
53c710: Voyager and parisc 712 systems

For the 53c720, we're using the ncr53c8xx driver on both voyager and
parisc.

James

Re: Removing BROKEN scsi drivers

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

James Bottomley wrote:
>On Wed, 2005-10-05 at 15:30 +0200, Kars de Jong wrote:
>> I have at least the 53c7xx driver and the MVME16X driver working, the
>> Amiga and BVME stuff is untested (but does compile).
>>
>> I patched the 53c7xx core to get it to work again, but the patch is ugly
>> and uses some mid level SCSI driver internals, which it shouldn't. It's
>> currently only present in the m68k CVS repository.
>>
>> Are you sure it's that easy to use the new 53c700 core? These boards all
>> have 53c710 chips, and are quite some changes in the 53c7xx driver
>> compared to the 53c8xx driver it originated from.
>
>The 53c700 driver is a bit misnamed, it also has a 710 mode which is set
>by a flag.  It's actually in common use driving three different
>chipsets:
>
>53c700: parisc 715 machines
>53c700-66: Voyager systems
>53c710: Voyager and parisc 712 systems

And PC. I've two of them running in EISA slots of an old Compaq 486 using 
sim710 driver.

Richard, remember this machine?

Eike

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Removing BROKEN scsi drivers

[Douglas Gilbert]

Andi Kleen wrote:
> In 2.6.14rc3:
> 
> linux/drivers/scsi> grep -c BROKEN Kconfig
> 11
> 
> There are a lot of SCSI drivers who have been marked BROKEN forever. Or at 
> least for all of 2.6 and one would expect if there are users left they would 
> have fixed them by now. Would it make sense to remove them?
> 
> In particular:
> 
> SCSI_ADVANSYS - vendor went out of market afaik. Probably not many left.

Andi,
My advansys controllers work fine in lk 2.6 .
Advansys itself (or its SCSI HBA line) was onsold
several times. I'm not sure if they are still
available (the last ones for sale that I noticed
were for SCSI (SPI-based) scanners). When lk 2.5
development changes broke the drivers, patches came
in from several contributors to fix them (usually
the minimum required). I believe they are still
out there, probably in decreasing numbers (e.g.
I decommissioned a server using one last week).
It's nice (albeit aging) hardware whose reliability
exceeds that of a few other HBA manufacturers'
products I could name.

So whoever marked the advansys driver as broken
was making some political statement IMO. If it
ain't broken, it shouldn't be marked as BROKEN.


If the kernel source was split up at some stage (rather
than one big source tarball), it may be appropriate
to put the advansys driver in with the second tier
(looking for a better term than "legacy") drivers.

Doug Gilbert

Re: Removing BROKEN scsi drivers

[Andi Kleen]

On Thursday 06 October 2005 00:36, Douglas Gilbert wrote:

>
> So whoever marked the advansys driver as broken
> was making some political statement IMO. If it
> ain't broken, it shouldn't be marked as BROKEN.

Well if it's not broken it should be marked unbroken.

If it only works on x86 as hch stated one way would
be to make it dependent on (X86 && !X86_64)

-Andi

Re: Removing BROKEN scsi drivers

[Geert Uytterhoeven]

On Wed, 5 Oct 2005, Kars de Jong wrote:
> On wo, 2005-10-05 at 13:32 +0100, Richard Hirst wrote:
> > On Wed, Oct 05, 2005 at 12:39:25PM +0100, Christoph Hellwig wrote:
> > > On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> > > > On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > > > > SCSI_AMIGA7XX - no maintainer, broken forever
> > > > > MVME16x_SCSI - no maintainer, broken forever
> > > > > BVME6000_SCSI - same
> > > > 
> > > > I don't think there's any point in deleting these.  I'm not even sure
> > > > why they're marked BROKEN.  They share 99% of their code with drivers
> > > > which are working.  And I thought Richard Hirst was maintaining them ...
> > > 
> > > They don't.  All these use the broken and obsolete 53c7xx driver, not
> > > James new 53c700 core.  The driver should be easy to reimplement based
> > > on the 53x700 for someone who has the hardware and cares about it.
> > 
> > I never claimed to maintain the amiga stuff, but you are right that they
> > all use the 53c7xx driver that I originally created.  The sensible thing
> > to do is to migrate those systems to use James 53c700 core, but it seems
> > wise to poll the linux-m68k list before removing them.  I don't do much
> > with my VME hardware these days but I know there have been patches
> > posted for the serial driver recently so maybe someone has the scsi
> > working.
> 
> I have at least the 53c7xx driver and the MVME16X driver working, the
> Amiga and BVME stuff is untested (but does compile).
> 
> I patched the 53c7xx core to get it to work again, but the patch is ugly
> and uses some mid level SCSI driver internals, which it shouldn't. It's
> currently only present in the m68k CVS repository.

Indeed:

http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/POSTPONED/520-53c7xx.diff

It was rejected upstream because patches for the 53c7xx driver are no longer
accepted. we should use the 53c700 core instead.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Fri, Oct 07, 2005 at 10:27:09AM +0200, Geert Uytterhoeven wrote:
> On Wed, 5 Oct 2005, Kars de Jong wrote:
> > On wo, 2005-10-05 at 13:32 +0100, Richard Hirst wrote:
> > > On Wed, Oct 05, 2005 at 12:39:25PM +0100, Christoph Hellwig wrote:
> > > > On Wed, Oct 05, 2005 at 05:31:08AM -0600, Matthew Wilcox wrote:
> > > > > On Wed, Oct 05, 2005 at 01:14:32PM +0200, Andi Kleen wrote:
> > > > > > SCSI_AMIGA7XX - no maintainer, broken forever
> > > > > > MVME16x_SCSI - no maintainer, broken forever
> > > > > > BVME6000_SCSI - same
> > > > > 
> > > > > I don't think there's any point in deleting these.  I'm not even sure
> > > > > why they're marked BROKEN.  They share 99% of their code with drivers
> > > > > which are working.  And I thought Richard Hirst was maintaining them ...
> > > > 
> > > > They don't.  All these use the broken and obsolete 53c7xx driver, not
> > > > James new 53c700 core.  The driver should be easy to reimplement based
> > > > on the 53x700 for someone who has the hardware and cares about it.
> > > 
> > > I never claimed to maintain the amiga stuff, but you are right that they
> > > all use the 53c7xx driver that I originally created.  The sensible thing
> > > to do is to migrate those systems to use James 53c700 core, but it seems
> > > wise to poll the linux-m68k list before removing them.  I don't do much
> > > with my VME hardware these days but I know there have been patches
> > > posted for the serial driver recently so maybe someone has the scsi
> > > working.
> > 
> > I have at least the 53c7xx driver and the MVME16X driver working, the
> > Amiga and BVME stuff is untested (but does compile).
> > 
> > I patched the 53c7xx core to get it to work again, but the patch is ugly
> > and uses some mid level SCSI driver internals, which it shouldn't. It's
> > currently only present in the m68k CVS repository.
> 
> Indeed:
> 
> http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/POSTPONED/520-53c7xx.diff
> 
> It was rejected upstream because patches for the 53c7xx driver are no longer
> accepted. we should use the 53c700 core instead.

Yep; I'll find time later this month to look at switching to use 53c700.

Richard


> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On vr, 2005-10-07 at 14:42 +0100, Richard Hirst wrote:
> On Fri, Oct 07, 2005 at 10:27:09AM +0200, Geert Uytterhoeven wrote:
> > Indeed:
> > 
> > http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/POSTPONED/520-53c7xx.diff
> > 
> > It was rejected upstream because patches for the 53c7xx driver are no longer
> > accepted. we should use the 53c700 core instead.
> 
> Yep; I'll find time later this month to look at switching to use 53c700.

I already did that, including the modifications needed to use the iomap
interface on m68k. I'll hopefully get around to testing it on an MVME167
this weekend.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Fri, Oct 07, 2005 at 03:53:52PM +0200, Kars de Jong wrote:
> > > It was rejected upstream because patches for the 53c7xx driver are no longer
> > > accepted. we should use the 53c700 core instead.
> > 
> > Yep; I'll find time later this month to look at switching to use 53c700.
> 
> I already did that, including the modifications needed to use the iomap
> interface on m68k. I'll hopefully get around to testing it on an MVME167
> this weekend.

Did you make any progress on this? 

Re: Removing BROKEN scsi drivers

[Ingo Juergensmann]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Tue, Nov 15, 2005 at 09:51:52AM +0000, Christoph Hellwig wrote:
> On Fri, Oct 07, 2005 at 03:53:52PM +0200, Kars de Jong wrote:
> > > > It was rejected upstream because patches for the 53c7xx driver are no longer
> > > > accepted. we should use the 53c700 core instead.
> > > Yep; I'll find time later this month to look at switching to use 53c700.
> > I already did that, including the modifications needed to use the iomap
> > interface on m68k. I'll hopefully get around to testing it on an MVME167
> > this weekend.
> Did you make any progress on this? 

I guess he made... Kars gave me a kernel image for Amiga:

53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi0: 53c710 rev 2
53c700: dmode=80 dcntl=01 ctest7=02
scsi0 : WarpEngine 40xx

spice:/home/ij# uptime
 11:13:14 up 4 days, 14:59,  3 users,  load average: 0.02, 0.20, 0.13

So far, I haven't experienced any problems with that new driver. I intend to
try that kernel on an Amiga 4000T with its implementation of that chip
(A4091-alike)...

-- 
Ciao...                //        Fon: 0381-2744150 
      Ingo           \X/         SIP: 2744150@sipgate.de

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Tue, Nov 15, 2005 at 11:17:09AM +0100, Ingo Juergensmann wrote:
> > Did you make any progress on this? 
> 
> I guess he made... Kars gave me a kernel image for Amiga:
> 
> 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
> scsi0: 53c710 rev 2
> 53c700: dmode=80 dcntl=01 ctest7=02
> scsi0 : WarpEngine 40xx
> 
> spice:/home/ij# uptime
>  11:13:14 up 4 days, 14:59,  3 users,  load average: 0.02, 0.20, 0.13
> 
> So far, I haven't experienced any problems with that new driver. I intend to
> try that kernel on an Amiga 4000T with its implementation of that chip
> (A4091-alike)...

Very nice.  Kars, could you send your patches to linux-scsi please?

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Tue, Nov 15, 2005 at 10:30:34AM +0000, Christoph Hellwig wrote:
> On Tue, Nov 15, 2005 at 11:17:09AM +0100, Ingo Juergensmann wrote:
> > > Did you make any progress on this? 
> > 
> > I guess he made... Kars gave me a kernel image for Amiga:
> > 
> > 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
> > scsi0: 53c710 rev 2
> > 53c700: dmode=80 dcntl=01 ctest7=02
> > scsi0 : WarpEngine 40xx
> > 
> > spice:/home/ij# uptime
> >  11:13:14 up 4 days, 14:59,  3 users,  load average: 0.02, 0.20, 0.13
> > 
> > So far, I haven't experienced any problems with that new driver. I intend to
> > try that kernel on an Amiga 4000T with its implementation of that chip
> > (A4091-alike)...
> 
> Very nice.  Kars, could you send your patches to linux-scsi please?

Between us it seems Kars and I have this driver working on Amiga, MVME,
and BVME boards.  That is everything that used the old 53c7xx driver.  I
don't believe there is a combined set of patches yet (at least, I havn't
seen the patches for Amiga).  One complication is that we're relying on
some m68k-specific dma support patches from Roman Zippel that are not
yet integrated.

Richard

Re: Removing BROKEN scsi drivers

[Roman Zippel]

Hi,

On Tue, 15 Nov 2005, Richard Hirst wrote:

> > Very nice.  Kars, could you send your patches to linux-scsi please?
> 
> Between us it seems Kars and I have this driver working on Amiga, MVME,
> and BVME boards.  That is everything that used the old 53c7xx driver.  I
> don't believe there is a combined set of patches yet (at least, I havn't
> seen the patches for Amiga).  One complication is that we're relying on
> some m68k-specific dma support patches from Roman Zippel that are not
> yet integrated.

Where I'm waiting for upstream blockage to get resolved before I continue 
with this.

bye, Roman

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On di, 2005-11-15 at 11:32 +0000, Richard Hirst wrote:
> On Tue, Nov 15, 2005 at 10:30:34AM +0000, Christoph Hellwig wrote:
> > On Tue, Nov 15, 2005 at 11:17:09AM +0100, Ingo Juergensmann wrote:
> > > > Did you make any progress on this? 
> > > 
> > > I guess he made... Kars gave me a kernel image for Amiga:
> > > 
> > > 53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
> > > scsi0: 53c710 rev 2
> > > 53c700: dmode=80 dcntl=01 ctest7=02
> > > scsi0 : WarpEngine 40xx
> > > 
> > > spice:/home/ij# uptime
> > >  11:13:14 up 4 days, 14:59,  3 users,  load average: 0.02, 0.20, 0.13
> > > 
> > > So far, I haven't experienced any problems with that new driver. I intend to
> > > try that kernel on an Amiga 4000T with its implementation of that chip
> > > (A4091-alike)...
> > 
> > Very nice.  Kars, could you send your patches to linux-scsi please?
> 
> Between us it seems Kars and I have this driver working on Amiga, MVME,
> and BVME boards.  That is everything that used the old 53c7xx driver.  I
> don't believe there is a combined set of patches yet (at least, I havn't
> seen the patches for Amiga).  One complication is that we're relying on
> some m68k-specific dma support patches from Roman Zippel that are not
> yet integrated.

Indeed, and there's issues with the iomap interface to solve as well. 

Also, I don't know the proper chip register settings for all supported
boards yet (hence the printk() with register settings).

With all m68k 53c700 implementations currently supported there should be
no byteswapping done in io{read,write}32(), but that doesn't hold for
each bus.

So until we can specify in some way how the io{read,write}{16,32}()
function should behave on a certain memory region, I see no way to
integrate this cleanly. For now I am inclined to do something like this
in 53c700.h:

#ifdef CONFIG_M68K
        iowrite32be(bS_to_io(value), hostdata->base + reg);
#else
        iowrite32(bS_to_io(value), hostdata->base + reg);
#endif

etc.

IMHO that's cleaner than hardcoding these functions to do no
byteswapping at all in include/asm-m68k/io.h. Plus that breaks when a
multi-config kernel is built (like one with PCMCIA and this SCSI driver,
because the Amiga PCMCIA implementation does need byteswapping). Much
like what you get now when you build a kernel with APNE and ZORRO8390
drivers for instance.

Comments, anyone?


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Matthew Wilcox]

On Tue, Nov 15, 2005 at 01:11:47PM +0100, Kars de Jong wrote:
> With all m68k 53c700 implementations currently supported there should be
> no byteswapping done in io{read,write}32(), but that doesn't hold for
> each bus.
> 
> So until we can specify in some way how the io{read,write}{16,32}()
> function should behave on a certain memory region, I see no way to
> integrate this cleanly. For now I am inclined to do something like this
> in 53c700.h:
> 
> #ifdef CONFIG_M68K
>         iowrite32be(bS_to_io(value), hostdata->base + reg);
> #else
>         iowrite32(bS_to_io(value), hostdata->base + reg);
> #endif
> 
> etc.
> 
> IMHO that's cleaner than hardcoding these functions to do no
> byteswapping at all in include/asm-m68k/io.h. Plus that breaks when a
> multi-config kernel is built (like one with PCMCIA and this SCSI driver,
> because the Amiga PCMCIA implementation does need byteswapping). Much
> like what you get now when you build a kernel with APNE and ZORRO8390
> drivers for instance.

I thought that was what the bS_to_io() and friends were for.

In any case, I agree with you.  The iomap call should let you specify
whether this is a big-endian or little-endian region.  Unfortunately,
James Bottomley disagreed and we now have the ioread16be family of
functions.

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Tue, Nov 15, 2005 at 01:11:47PM +0100, Kars de Jong wrote:
> Indeed, and there's issues with the iomap interface to solve as well. 
> 
> Also, I don't know the proper chip register settings for all supported
> boards yet (hence the printk() with register settings).
> 
> With all m68k 53c700 implementations currently supported there should be
> no byteswapping done in io{read,write}32(), but that doesn't hold for
> each bus.
> 
> So until we can specify in some way how the io{read,write}{16,32}()
> function should behave on a certain memory region, I see no way to
> integrate this cleanly. For now I am inclined to do something like this
> in 53c700.h:
> 
> #ifdef CONFIG_M68K
>         iowrite32be(bS_to_io(value), hostdata->base + reg);
> #else
>         iowrite32(bS_to_io(value), hostdata->base + reg);
> #endif

The 53c700 already has a rather awkward mechanism to deal with different
bus byte orders, I'd suggest you use that now and switch the driver to
use ioread*be later, without introducing arch-specific config symbols.

Anyway, could you folks please submit what you have now? The 53c7xx hasn't
worked ever in 2.6.x, and we're gonna remove it for 2.6.16.  It would be
nice to keep the m68k glue drivers switched over to use 53c700 even if there's
still some odd hacks required to actually make it work - we'll surely sort
them out once the basics are in.

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On di, 2005-11-22 at 08:36 +0000, Christoph Hellwig wrote: 
> The 53c700 already has a rather awkward mechanism to deal with different
> bus byte orders, I'd suggest you use that now and switch the driver to
> use ioread*be later, without introducing arch-specific config symbols.

I don't really understand the current mechanism. It seems to result in
different behaviour for BE systems depending on the definition of
CONFIG_53C700_LE_ON_BE.

I would have expected the behaviour on BE systems without defining
CONFIG_53C700_LE_ON_BE to be the same as on BE systems with
CONFIG_53C700_LE_ON_BE defined but with hostdata->force_le_on_be set to
0.

Was this driver ever used on BE systems without CONFIG_53C700_LE_ON_BE
being defined?

For reference:

BE with CONFIG_53C700_LE_ON_BE defined but hostdata->force_le_on_be set
to 0:

/* This is terrible, but there's no raw version of ioread32.  That means
 * that on a be board we swap twice (once in ioread32 and once again to
 * get the value correct) */
#define bS_to_io(x)     ((hostdata->force_le_on_be) ? (x) : cpu_to_le32(x))

evaluates to
                                      0   ---------->       cpu_to_le32(x)

And without CONFIG_53C700_LE_ON_BE defined:

#define bS_to_io(x)     (x)

I think this last define should be cpu_to_le32() as well, then the
driver would work on m68k out-of-the-box.

James, can you comment on this?

> Anyway, could you folks please submit what you have now? The 53c7xx hasn't
> worked ever in 2.6.x, and we're gonna remove it for 2.6.16.  It would be
> nice to keep the m68k glue drivers switched over to use 53c700 even if there's
> still some odd hacks required to actually make it work - we'll surely sort
> them out once the basics are in.

They wouldn't compile, because I'm not going to submit Romans DMA patch
myself.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Matthew Wilcox]

On Tue, Nov 22, 2005 at 10:43:56PM +0100, Kars de Jong wrote:
> I don't really understand the current mechanism. It seems to result in
> different behaviour for BE systems depending on the definition of
> CONFIG_53C700_LE_ON_BE.

I think you misunderstand the meaning of that symbol.  It means "Support
little endian chips on a big endian processor".  Without it set, the
driver supports only little endian chips on little endian processors and
big endian chips on big endian processors.

> Was this driver ever used on BE systems without CONFIG_53C700_LE_ON_BE
> being defined?

I doubt it.

Re: Removing BROKEN scsi drivers

[James Bottomley]

On Tue, 2005-11-22 at 22:43 +0100, Kars de Jong wrote:
> I don't really understand the current mechanism. It seems to result in
> different behaviour for BE systems depending on the definition of
> CONFIG_53C700_LE_ON_BE.
> 
> I would have expected the behaviour on BE systems without defining
> CONFIG_53C700_LE_ON_BE to be the same as on BE systems with
> CONFIG_53C700_LE_ON_BE defined but with hostdata->force_le_on_be set to
> 0.
> 
> Was this driver ever used on BE systems without CONFIG_53C700_LE_ON_BE
> being defined?
> 
> For reference:
> 
> BE with CONFIG_53C700_LE_ON_BE defined but hostdata->force_le_on_be set
> to 0:
> 
> /* This is terrible, but there's no raw version of ioread32.  That means
>  * that on a be board we swap twice (once in ioread32 and once again to
>  * get the value correct) */
> #define bS_to_io(x)     ((hostdata->force_le_on_be) ? (x) : cpu_to_le32(x))
> 
> evaluates to
>                                       0   ---------->       cpu_to_le32(x)
> 
> And without CONFIG_53C700_LE_ON_BE defined:
> 
> #define bS_to_io(x)     (x)
> 
> I think this last define should be cpu_to_le32() as well, then the
> driver would work on m68k out-of-the-box.
> 
> James, can you comment on this?

OK, let me try to explain.

ioread/write32 came with a slight design flaw in that it *always*
converts to LE.  By and large, no-one notices this because almost every
platform has the PCI bus, which is LE.  However, PA also has the GSC
bus, which is BE.  We already introduced the ioread/write<n>be macros
which work for a BE bus.  You're right, the only current BE consumer of
the driver is PA-RISC, which has a cockup on one of the 53c700 chips
which is wired in LE mode on the BE GSC bus, so we need that flag.

I assume your problems is also that the 53c7x0 chip on the MAC is also
on a BE bus, so I think what you want is another flag:

53c700_BE_BUS

which causes all the io macros to be ioread/write<n>be.  Which will
avoid the nasty double swap we do on PA.

James

Re: Removing BROKEN scsi drivers

[James Bottomley]

On Sun, 2005-11-27 at 11:47 -0500, James Bottomley wrote:
> I assume your problems is also that the 53c7x0 chip on the MAC is also
> on a BE bus, so I think what you want is another flag:
> 
> 53c700_BE_BUS
> 
> which causes all the io macros to be ioread/write<n>be.  Which will
> avoid the nasty double swap we do on PA.

How about the attached.  I've tested it out on parisc and it works
fine ... in fact I'm tempted to commit it simply because we now avoid
the double swap for every I/O operation.

James

diff --git a/drivers/scsi/53c700.h b/drivers/scsi/53c700.h
--- a/drivers/scsi/53c700.h
+++ b/drivers/scsi/53c700.h
@@ -232,21 +232,23 @@ struct NCR_700_Host_Parameters {
 #ifdef CONFIG_53C700_LE_ON_BE
 #define bE	(hostdata->force_le_on_be ? 0 : 3)
 #define	bSWAP	(hostdata->force_le_on_be)
-/* This is terrible, but there's no raw version of ioread32.  That means
- * that on a be board we swap twice (once in ioread32 and once again to 
- * get the value correct) */
-#define bS_to_io(x)	((hostdata->force_le_on_be) ? (x) : cpu_to_le32(x))
+#define bEBus	(!hostdata->force_le_on_be)
 #elif defined(__BIG_ENDIAN)
 #define bE	3
 #define bSWAP	0
-#define bS_to_io(x)	(x)
 #elif defined(__LITTLE_ENDIAN)
 #define bE	0
 #define bSWAP	0
-#define bS_to_io(x)	(x)
 #else
 #error "__BIG_ENDIAN or __LITTLE_ENDIAN must be defined, did you include byteorder.h?"
 #endif
+#ifndef bEBus
+#ifdef CONFIG_53C700_BE_BUS)
+#define bEBus	1
+#else
+#define bEBus	0
+#endif
+#endif
 #define bS_to_cpu(x)	(bSWAP ? le32_to_cpu(x) : (x))
 #define bS_to_host(x)	(bSWAP ? cpu_to_le32(x) : (x))
 
@@ -460,14 +462,15 @@ NCR_700_readl(struct Scsi_Host *host, __
 {
 	const struct NCR_700_Host_Parameters *hostdata
 		= (struct NCR_700_Host_Parameters *)host->hostdata[0];
-	__u32 value = ioread32(hostdata->base + reg);
+	__u32 value = bEBus ? ioread32be(hostdata->base + reg) :
+		ioread32(hostdata->base + reg);
 #if 1
 	/* sanity check the register */
 	if((reg & 0x3) != 0)
 		BUG();
 #endif
 
-	return bS_to_io(value);
+	return value;
 }
 
 static inline void
@@ -491,7 +494,8 @@ NCR_700_writel(__u32 value, struct Scsi_
 		BUG();
 #endif
 
-	iowrite32(bS_to_io(value), hostdata->base + reg);
+	bEBus ? iowrite32be(value, hostdata->base + reg): 
+		iowrite32(value, hostdata->base + reg);
 }
 
 #endif

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On di, 2005-11-29 at 16:24 -0600, James Bottomley wrote:
> On Sun, 2005-11-27 at 11:47 -0500, James Bottomley wrote:
> > I assume your problems is also that the 53c7x0 chip on the MAC is also
> > on a BE bus, so I think what you want is another flag:
> > 
> > 53c700_BE_BUS
> > 
> > which causes all the io macros to be ioread/write<n>be.  Which will
> > avoid the nasty double swap we do on PA.
> 
> How about the attached.  I've tested it out on parisc and it works
> fine ... in fact I'm tempted to commit it simply because we now avoid
> the double swap for every I/O operation.

Looks fine to me. I'll see if I can try it out on m68k tonight. The
driver isn't used on MACs by the way, it's used on Amigas and VME single
board computers.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Ingo Juergensmann]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Wed, Nov 30, 2005 at 09:31:23AM +0100, Kars de Jong wrote:

> Looks fine to me. I'll see if I can try it out on m68k tonight. The
> driver isn't used on MACs by the way, it's used on Amigas and VME single
> board computers.

I'll look forward to test it on my machines... :-> 

-- 
Ciao...                //        Fon: 0381-2744150 
      Ingo           \X/         SIP: 2744150@sipgate.de

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On di, 2005-11-29 at 16:24 -0600, James Bottomley wrote:
> How about the attached.  I've tested it out on parisc and it works
> fine ... in fact I'm tempted to commit it simply because we now avoid
> the double swap for every I/O operation.

I've tested it on my MVME167, using the generic iomap() interface
implementation, and it seems to work fine.

I noticed one thing in the patch:

> +#ifdef CONFIG_53C700_BE_BUS)
                              ^
There's a trailing ) there.

Ingo, can you test the kernel at
http://members.home.nl/karsdejong/vmlinuz-2.6.14-amiga-4 on your
hardware? It also has NFS client and AFFS support.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[James Bottomley]

On Thu, 2005-12-01 at 21:43 +0100, Kars de Jong wrote:
> I noticed one thing in the patch:
> 
> > +#ifdef CONFIG_53C700_BE_BUS)
>                               ^
> There's a trailing ) there.

Well .. since you'll be the first user of the config option, could you
fix it when you add your driver ...

Thanks,

James

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Thu, Dec 01, 2005 at 09:43:13PM +0100, Kars de Jong wrote:
> On di, 2005-11-29 at 16:24 -0600, James Bottomley wrote:
> > How about the attached.  I've tested it out on parisc and it works
> > fine ... in fact I'm tempted to commit it simply because we now avoid
> > the double swap for every I/O operation.
> 
> I've tested it on my MVME167, using the generic iomap() interface
> implementation, and it seems to work fine.

Hi Kars, do you have my changes for BMVE6000 too?  It'd be nice to
submit them all together, when we get to that stage.

Cheers,
  Richard

> 
> I noticed one thing in the patch:
> 
> > +#ifdef CONFIG_53C700_BE_BUS)
>                               ^
> There's a trailing ) there.
> 
> Ingo, can you test the kernel at
> http://members.home.nl/karsdejong/vmlinuz-2.6.14-amiga-4 on your
> hardware? It also has NFS client and AFFS support.
> 
> 
> Kind regards,
> 
> Kars.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Removing BROKEN scsi drivers

[Ingo Juergensmann]

Kars de Jong wrote:

> Ingo, can you test the kernel at
> http://members.home.nl/karsdejong/vmlinuz-2.6.14-amiga-4 on your
> hardware? It also has NFS client and AFFS support.

Thx, it's already running on the A3000 with WarpEngine... no problems so
far (30 mins uptime ;-)

-- 
Ciao...        //
      Ingo   \X/

Re: Removing BROKEN scsi drivers

[Ingo Juergensmann]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Thu, Dec 01, 2005 at 09:43:13PM +0100, Kars de Jong wrote:

> Ingo, can you test the kernel at
> http://members.home.nl/karsdejong/vmlinuz-2.6.14-amiga-4 on your
> hardware? It also has NFS client and AFFS support.

It now runs on both of my NCR based Amigas... no problems so far... 

-- 
Ciao...                //        Fon: 0381-2744150 
      Ingo           \X/         SIP: 2744150@sipgate.de

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Tue, Nov 15, 2005 at 11:32:25AM +0000, Richard Hirst wrote:
> Between us it seems Kars and I have this driver working on Amiga, MVME,
> and BVME boards.  That is everything that used the old 53c7xx driver.  I
> don't believe there is a combined set of patches yet (at least, I havn't
> seen the patches for Amiga).  One complication is that we're relying on
> some m68k-specific dma support patches from Roman Zippel that are not
> yet integrated.

After only half a year of waiting the m68k dma api bits finally made it in..

Could you please submit your patches again now that everything should be
in place?

Re: Removing BROKEN scsi drivers

[Richard Hirst]

On Fri, Jul 07, 2006 at 01:44:44PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 15, 2005 at 11:32:25AM +0000, Richard Hirst wrote:
> > Between us it seems Kars and I have this driver working on Amiga, MVME,
> > and BVME boards.  That is everything that used the old 53c7xx driver.  I
> > don't believe there is a combined set of patches yet (at least, I havn't
> > seen the patches for Amiga).  One complication is that we're relying on
> > some m68k-specific dma support patches from Roman Zippel that are not
> > yet integrated.
> 
> After only half a year of waiting the m68k dma api bits finally made it in..
> 
> Could you please submit your patches again now that everything should be
> in place?

I'm trying to figure out where we got to with this, but my problem is I
never saw a patch from Kars that included Amiga and [BM]VME changes in
one patch, and I only generated the [BM]VME parts.  Also  Kars changed
things to work with the new "bEBus" option James added to the 53c700
driver.

Kars, do you have such a patch handy as a starting point, or even
better, do you have a current patch that can go to liunx-scsi ?

Thanks,
  Richard

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On zo, 2006-07-09 at 12:16 +0100, Richard Hirst wrote:
> On Fri, Jul 07, 2006 at 01:44:44PM +0100, Christoph Hellwig wrote:
> > After only half a year of waiting the m68k dma api bits finally made it in..
> > 
> > Could you please submit your patches again now that everything should be
> > in place?
> 
> I'm trying to figure out where we got to with this, but my problem is I
> never saw a patch from Kars that included Amiga and [BM]VME changes in
> one patch, and I only generated the [BM]VME parts.  Also  Kars changed
> things to work with the new "bEBus" option James added to the 53c700
> driver.
> 
> Kars, do you have such a patch handy as a starting point, or even
> better, do you have a current patch that can go to liunx-scsi ?

Yes, I have a current patch which integrates all of the above mentioned
changes. Didn't get around to testing it yet with the integrated DMA API
patches.

I hope to be able to send it later this week.


Kind regards,

Kars.

Re: Removing BROKEN scsi drivers

[Christoph Hellwig]

On Sun, Jul 09, 2006 at 01:25:04PM +0200, Kars de Jong wrote:
> Yes, I have a current patch which integrates all of the above mentioned
> changes. Didn't get around to testing it yet with the integrated DMA API
> patches.
> 
> I hope to be able to send it later this week.

Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
mess in the upoming request_buffer transition, and unless the m68k
folks provide the new 53c700-based driver I'll just submit a patch to
rip 53c7xx and users out without replacement.

Re: Removing BROKEN scsi drivers

[Kars de Jong]

On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> On Sun, Jul 09, 2006 at 01:25:04PM +0200, Kars de Jong wrote:
> > Yes, I have a current patch which integrates all of the above mentioned
> > changes. Didn't get around to testing it yet with the integrated DMA API
> > patches.
> > 
> > I hope to be able to send it later this week.
> 
> Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> mess in the upoming request_buffer transition, and unless the m68k
> folks provide the new 53c700-based driver I'll just submit a patch to
> rip 53c7xx and users out without replacement.

Unfortunately real life got in the way. I don't have much time to work
on m68k anymore.

This weekend I did a test with 2.6.18 and the new 53c700-based driver on
my MVME167 which didn't work very well. It locked up several times, and
the exception handler got stuck in some loop.

I did not have these problems with 2.6.16.

I will send the patch in its current form, so that the old 53c7xx driver
can be removed.


Kind regards,

Kars.

[RFC PATCH] m68k: switch to 53c700 driver

[Kars de Jong]

On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> mess in the upoming request_buffer transition, and unless the m68k
> folks provide the new 53c700-based driver I'll just submit a patch to
> rip 53c7xx and users out without replacement.

OK, here's the patch, without the m68k generic iomap changes.

If there are no objections, I will commit it to our CVS repository so
Geert can send it upstream (with proper Signed-Off-By: headers and
everything).

This patch is relative to the m68k CVS repository, which is at kernel
version 2.6.18.

I have renamed the mvme16x.c and bvme6000.c files to mvme16x_scsi.c and
bvme6000_scsi.c respectively, I'm not sure if this is a good idea
though.


Kind regards,

Kars.


Index: linux-2.6-m68k-vme/drivers/scsi/53c700.c
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/53c700.c,v
retrieving revision 1.1.1.37
diff -u -r1.1.1.37 53c700.c
--- linux-2.6-m68k-vme/drivers/scsi/53c700.c	23 Sep 2006 16:55:51 -0000	1.1.1.37
+++ linux-2.6-m68k-vme/drivers/scsi/53c700.c	31 Oct 2006 21:38:48 -0000
@@ -660,20 +660,20 @@
 {
 	struct NCR_700_Host_Parameters *hostdata = 
 		(struct NCR_700_Host_Parameters *)host->hostdata[0];
-	__u32 dcntl_extra = 0;
 	__u8 min_period;
 	__u8 min_xferp = (hostdata->chip710 ? NCR_710_MIN_XFERP : NCR_700_MIN_XFERP);
 
 	if(hostdata->chip710) {
 		__u8 burst_disable = hostdata->burst_disable
 			? BURST_DISABLE : 0;
-		dcntl_extra = COMPAT_700_MODE;
+		hostdata->dcntl_extra |= COMPAT_700_MODE;
 
-		NCR_700_writeb(dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(hostdata->dcntl_extra, host, DCNTL_REG);
 		NCR_700_writeb(BURST_LENGTH_8  | hostdata->dmode_extra,
 			       host, DMODE_710_REG);
-		NCR_700_writeb(burst_disable | (hostdata->differential ? 
-						DIFF : 0), host, CTEST7_REG);
+		NCR_700_writeb(burst_disable | hostdata->ctest7_extra |
+			       (hostdata->differential ? DIFF : 0),
+			       host, CTEST7_REG);
 		NCR_700_writeb(BTB_TIMER_DISABLE, host, CTEST0_REG);
 		NCR_700_writeb(FULL_ARBITRATION | ENABLE_PARITY | PARITY
 			       | AUTO_ATN, host, SCNTL0_REG);
@@ -708,13 +708,13 @@
 		 * of spec: sync divider 2, async divider 3 */
 		DEBUG(("53c700: sync 2 async 3\n"));
 		NCR_700_writeb(SYNC_DIV_2_0, host, SBCL_REG);
-		NCR_700_writeb(ASYNC_DIV_3_0 | dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(ASYNC_DIV_3_0 | hostdata->dcntl_extra, host, DCNTL_REG);
 		hostdata->sync_clock = hostdata->clock/2;
 	} else	if(hostdata->clock > 50  && hostdata->clock <= 75) {
 		/* sync divider 1.5, async divider 3 */
 		DEBUG(("53c700: sync 1.5 async 3\n"));
 		NCR_700_writeb(SYNC_DIV_1_5, host, SBCL_REG);
-		NCR_700_writeb(ASYNC_DIV_3_0 | dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(ASYNC_DIV_3_0 | hostdata->dcntl_extra, host, DCNTL_REG);
 		hostdata->sync_clock = hostdata->clock*2;
 		hostdata->sync_clock /= 3;
 		
@@ -722,18 +722,18 @@
 		/* sync divider 1, async divider 2 */
 		DEBUG(("53c700: sync 1 async 2\n"));
 		NCR_700_writeb(SYNC_DIV_1_0, host, SBCL_REG);
-		NCR_700_writeb(ASYNC_DIV_2_0 | dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(ASYNC_DIV_2_0 | hostdata->dcntl_extra, host, DCNTL_REG);
 		hostdata->sync_clock = hostdata->clock;
 	} else if(hostdata->clock > 25 && hostdata->clock <=37) {
 		/* sync divider 1, async divider 1.5 */
 		DEBUG(("53c700: sync 1 async 1.5\n"));
 		NCR_700_writeb(SYNC_DIV_1_0, host, SBCL_REG);
-		NCR_700_writeb(ASYNC_DIV_1_5 | dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(ASYNC_DIV_1_5 | hostdata->dcntl_extra, host, DCNTL_REG);
 		hostdata->sync_clock = hostdata->clock;
 	} else {
 		DEBUG(("53c700: sync 1 async 1\n"));
 		NCR_700_writeb(SYNC_DIV_1_0, host, SBCL_REG);
-		NCR_700_writeb(ASYNC_DIV_1_0 | dcntl_extra, host, DCNTL_REG);
+		NCR_700_writeb(ASYNC_DIV_1_0 | hostdata->dcntl_extra, host, DCNTL_REG);
 		/* sync divider 1, async divider 1 */
 		hostdata->sync_clock = hostdata->clock;
 	}
Index: linux-2.6-m68k-vme/drivers/scsi/53c700.h
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/53c700.h,v
retrieving revision 1.1.1.20
diff -u -r1.1.1.20 53c700.h
--- linux-2.6-m68k-vme/drivers/scsi/53c700.h	23 Sep 2006 16:55:52 -0000	1.1.1.20
+++ linux-2.6-m68k-vme/drivers/scsi/53c700.h	31 Oct 2006 21:38:48 -0000
@@ -177,6 +177,7 @@
 	__u8	state;
 	#define NCR_700_FLAG_AUTOSENSE	0x01
 	__u8	flags;
+	__u8	pad1[2];	/* Needed for m68k where min alignment is 2 bytes */
 	int	tag;
 	__u32	resume_offset;
 	struct scsi_cmnd *cmnd;
@@ -196,6 +197,8 @@
 	void __iomem	*base;		/* the base for the port (copied to host) */
 	struct device	*dev;
 	__u32	dmode_extra;	/* adjustable bus settings */
+	__u32	dcntl_extra;	/* adjustable bus settings */
+	__u32	ctest7_extra;	/* adjustable bus settings */
 	__u32	differential:1;	/* if we are differential */
 #ifdef CONFIG_53C700_LE_ON_BE
 	/* This option is for HP only.  Set it if your chip is wired for
@@ -352,6 +355,7 @@
 #define		SEL_TIMEOUT_DISABLE	0x10 /* 710 only */
 #define         DFP                     0x08
 #define         EVP                     0x04
+#define         CTEST7_TT1              0x02
 #define		DIFF			0x01
 #define CTEST6_REG                      0x1A
 #define	TEMP_REG			0x1C
@@ -385,6 +389,7 @@
 #define		SOFTWARE_RESET		0x01
 #define		COMPAT_700_MODE		0x01
 #define 	SCRPTS_16BITS		0x20
+#define		EA_710			0x20
 #define		ASYNC_DIV_2_0		0x00
 #define		ASYNC_DIV_1_5		0x40
 #define		ASYNC_DIV_1_0		0x80
Index: linux-2.6-m68k-vme/drivers/scsi/Kconfig
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/Kconfig,v
retrieving revision 1.24
diff -u -r1.24 Kconfig
--- linux-2.6-m68k-vme/drivers/scsi/Kconfig	21 Oct 2006 18:47:48 -0000	1.24
+++ linux-2.6-m68k-vme/drivers/scsi/Kconfig	31 Oct 2006 21:38:49 -0000
@@ -1053,6 +1053,11 @@
 	depends on SCSI_LASI700
 	default y
 
+config 53C700_BE_BUS
+	bool
+	depends on SCSI_AMIGA7XX || MVME16x_SCSI || BVME6000_SCSI
+	default y
+
 config SCSI_SYM53C8XX_2
 	tristate "SYM53C8XX Version 2 SCSI support"
 	depends on PCI && SCSI
@@ -1670,7 +1675,7 @@
 	  one in the near future, say Y to this question. Otherwise, say N.
 
 config SCSI_AMIGA7XX
-	bool "Amiga NCR53c710 SCSI support (EXPERIMENTAL)"
+	tristate "Amiga NCR53c710 SCSI support (EXPERIMENTAL)"
 	depends on AMIGA && SCSI && EXPERIMENTAL
 	select SCSI_SPI_ATTRS
 	help
@@ -1771,7 +1776,7 @@
 	  single-board computer.
 
 config MVME16x_SCSI
-	bool "NCR53C710 SCSI driver for MVME16x"
+	tristate "NCR53C710 SCSI driver for MVME16x"
 	depends on MVME16x && SCSI
 	select SCSI_SPI_ATTRS
 	help
@@ -1780,7 +1785,7 @@
 	  will want to say Y to this question.
 
 config BVME6000_SCSI
-	bool "NCR53C710 SCSI driver for BVME6000"
+	tristate "NCR53C710 SCSI driver for BVME6000"
 	depends on BVME6000 && SCSI
 	select SCSI_SPI_ATTRS
 	help
@@ -1788,14 +1793,6 @@
 	  SCSI controller chip.  Almost everyone using one of these boards
 	  will want to say Y to this question.
 
-config SCSI_NCR53C7xx_FAST
-	bool "allow FAST-SCSI [10MHz]"
-	depends on SCSI_AMIGA7XX || MVME16x_SCSI || BVME6000_SCSI
-	help
-	  This will enable 10MHz FAST-SCSI transfers with your host
-	  adapter. Some systems have problems with that speed, so it's safest
-	  to say N here.
-
 config SUN3_SCSI
 	tristate "Sun3 NCR5380 SCSI"
 	depends on SUN3 && SCSI
Index: linux-2.6-m68k-vme/drivers/scsi/Makefile
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/Makefile,v
retrieving revision 1.1.1.46
diff -u -r1.1.1.46 Makefile
--- linux-2.6-m68k-vme/drivers/scsi/Makefile	23 Sep 2006 16:55:57 -0000	1.1.1.46
+++ linux-2.6-m68k-vme/drivers/scsi/Makefile	31 Oct 2006 21:38:49 -0000
@@ -35,7 +35,7 @@
 
 obj-$(CONFIG_ISCSI_TCP) 	+= libiscsi.o	iscsi_tcp.o
 obj-$(CONFIG_INFINIBAND_ISER) 	+= libiscsi.o
-obj-$(CONFIG_SCSI_AMIGA7XX)	+= amiga7xx.o	53c7xx.o
+obj-$(CONFIG_SCSI_AMIGA7XX)	+= 53c700.o	amiga7xx.o
 obj-$(CONFIG_A3000_SCSI)	+= a3000.o	wd33c93.o
 obj-$(CONFIG_A2091_SCSI)	+= a2091.o	wd33c93.o
 obj-$(CONFIG_GVP11_SCSI)	+= gvp11.o	wd33c93.o
@@ -51,8 +51,8 @@
 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)	+= mvme16x.o	53c7xx.o
-obj-$(CONFIG_BVME6000_SCSI)	+= bvme6000.o	53c7xx.o
+obj-$(CONFIG_MVME16x_SCSI)	+= 53c700.o	mvme16x_scsi.o
+obj-$(CONFIG_BVME6000_SCSI)	+= 53c700.o	bvme6000_scsi.o
 obj-$(CONFIG_SCSI_SIM710)	+= 53c700.o	sim710.o
 obj-$(CONFIG_SCSI_ADVANSYS)	+= advansys.o
 obj-$(CONFIG_SCSI_PSI240I)	+= psi240i.o
@@ -170,10 +170,8 @@
 oktagon_esp_mod-objs	:= oktagon_esp.o oktagon_io.o
 
 # Files generated that shall be removed upon make clean
-clean-files :=	53c7xx_d.h 53c700_d.h	\
-		53c7xx_u.h 53c700_u.h
+clean-files :=	53c700_d.h 53c700_u.h
 
-$(obj)/53c7xx.o:   $(obj)/53c7xx_d.h $(obj)/53c7xx_u.h
 $(obj)/53c700.o $(MODVERDIR)/$(obj)/53c700.ver: $(obj)/53c700_d.h
 
 # If you want to play with the firmware, uncomment
@@ -181,11 +179,6 @@
 
 ifdef GENERATE_FIRMWARE
 
-$(obj)/53c7xx_d.h: $(src)/53c7xx.scr $(src)/script_asm.pl
-	$(CPP) -traditional -DCHIP=710 - < $< | grep -v '^#' | $(PERL) -s $(src)/script_asm.pl -ncr7x0_family $@ $(@:_d.h=_u.h)
-
-$(obj)/53c7xx_u.h: $(obj)/53c7xx_d.h
-
 $(obj)/53c700_d.h: $(src)/53c700.scr $(src)/script_asm.pl
 	$(PERL) -s $(src)/script_asm.pl -ncr7x0_family $@ $(@:_d.h=_u.h) < $<
 
Index: linux-2.6-m68k-vme/drivers/scsi/amiga7xx.c
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/amiga7xx.c,v
retrieving revision 1.11
diff -u -r1.11 amiga7xx.c
--- linux-2.6-m68k-vme/drivers/scsi/amiga7xx.c	23 Sep 2006 20:44:56 -0000	1.11
+++ linux-2.6-m68k-vme/drivers/scsi/amiga7xx.c	31 Oct 2006 21:38:49 -0000
@@ -6,143 +6,287 @@
  *
  * Written 1997 by Alan Hourihane <alanh@fairlite.demon.co.uk>
  * plus modifications of the 53c7xx.c driver to support the Amiga.
+ *
+ * Rewritten to use 53c700.c by Kars de Jong <jongk@linux-m68k.org>
  */
-#include <linux/types.h>
-#include <linux/mm.h>
+
+#include <linux/module.h>
 #include <linux/blkdev.h>
-#include <linux/sched.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
 #include <linux/zorro.h>
-#include <linux/stat.h>
-
-#include <asm/setup.h>
-#include <asm/page.h>
-#include <asm/pgtable.h>
-#include <asm/amigaints.h>
 #include <asm/amigahw.h>
-#include <asm/dma.h>
-#include <asm/irq.h>
-
-#include "scsi.h"
+#include <asm/amigaints.h>
 #include <scsi/scsi_host.h>
-#include "53c7xx.h"
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_transport.h>
+#include <scsi/scsi_transport_spi.h>
+
+#include "53c700.h"
+
+MODULE_AUTHOR("Alan Hourihane <alanh@fairlite.demon.co.uk> / Kars de Jong <jongk@linux-m68k.org>");
+MODULE_DESCRIPTION("Amiga NCR53C710 driver");
+MODULE_LICENSE("GPL");
+
+static struct scsi_host_template amiga7xx_scsi_driver_template = {
+	.name		= "A4000T builtin SCSI",
+	.proc_name	= "Amiga7xx",
+	.this_id	= 7,
+	.module		= THIS_MODULE,
+};
 
-#ifndef CMD_PER_LUN
-#define CMD_PER_LUN 3
-#endif
+static struct platform_device *a4000t_scsi_device;
 
-#ifndef CAN_QUEUE
-#define CAN_QUEUE 24
-#endif
+#ifdef CONFIG_ZORRO
+
+static struct zorro_driver_data {
+	const char *name;
+	unsigned long offset;
+	int absolute;	/* offset is absolute address */
+} amiga7xx_driver_data[] __devinitdata = {
+	{ .name = "PowerUP 603e+", .offset = 0xf40000, .absolute = 1 },
+	{ .name = "WarpEngine 40xx", .offset = 0x40000 },
+	{ .name = "A4091", .offset = 0x800000 },
+	{ .name = "GForce 040/060", .offset = 0x40000 },
+	{ 0 }
+};
+
+static struct zorro_device_id amiga7xx_zorro_tbl[] __devinitdata = {
+	{
+		.id = ZORRO_PROD_PHASE5_BLIZZARD_603E_PLUS,
+		.driver_data = (unsigned long)&amiga7xx_driver_data[0],
+	},
+	{
+		.id = ZORRO_PROD_MACROSYSTEMS_WARP_ENGINE_40xx,
+		.driver_data = (unsigned long)&amiga7xx_driver_data[1],
+	},
+	{
+		.id = ZORRO_PROD_CBM_A4091_1,
+		.driver_data = (unsigned long)&amiga7xx_driver_data[2],
+	},
+	{
+		.id = ZORRO_PROD_CBM_A4091_2,
+		.driver_data = (unsigned long)&amiga7xx_driver_data[2],
+	},
+	{
+		.id = ZORRO_PROD_GVP_GFORCE_040_060,
+		.driver_data = (unsigned long)&amiga7xx_driver_data[3],
+	},
+	{ 0 }
+};
 
-static int amiga7xx_register_one(struct scsi_host_template *tpnt,
-				 unsigned long address)
+static int __devinit amiga7xx_init_one(struct zorro_dev *z,
+				   const struct zorro_device_id *ent)
 {
-    long long options;
-    int clock;
+	struct Scsi_Host * host = NULL;
+	struct NCR_700_Host_Parameters *hostdata;
+	struct zorro_driver_data *zdd;
+	unsigned long board, ioaddr;
+
+	board = zorro_resource_start(z);
+	zdd = (struct zorro_driver_data *)ent->driver_data;
+
+	if (zdd->absolute) {
+		ioaddr = zdd->offset;
+	} else {
+		ioaddr = board + zdd->offset;
+	}
+
+	if (!zorro_request_device(z, zdd->name)) {
+		printk(KERN_ERR "amiga7xx: cannot reserve region 0x%lx, abort\n",
+		       board);
+		return -EBUSY;
+	}
+
+	hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
+
+	if (hostdata == NULL) {
+		printk(KERN_ERR "amiga7xx: Failed to allocate host data\n");
+		goto out_release;
+	}
+
+	memset(hostdata, 0, sizeof(struct NCR_700_Host_Parameters));
+
+	/* Fill in the required pieces of hostdata */
+	if (ioaddr > 0x01000000)
+		hostdata->base = ioremap(ioaddr, zorro_resource_len(z));
+	else
+		hostdata->base = (void __iomem *)ZTWO_VADDR(ioaddr);
 
-    if (!request_mem_region(address, 0x1000, "ncr53c710"))
-	return 0;
+	hostdata->clock = 50;
+	hostdata->chip710 = 1;
 
-    address = (unsigned long)z_ioremap(address, 0x1000);
-    options = OPTION_MEMORY_MAPPED | OPTION_DEBUG_TEST1 | OPTION_INTFLY |
-	      OPTION_SYNCHRONOUS | OPTION_ALWAYS_SYNCHRONOUS |
-	      OPTION_DISCONNECT;
-    clock = 50000000;	/* 50 MHz SCSI Clock */
-    ncr53c7xx_init(tpnt, 0, 710, address, 0, IRQ_AMIGA_PORTS, DMA_NONE,
-		   options, clock);
-    return 1;
-}
+	/* Settings for at least WarpEngine 40xx */
+	hostdata->ctest7_extra = CTEST7_TT1;
 
+	amiga7xx_scsi_driver_template.name = zdd->name;
 
-#ifdef CONFIG_ZORRO
+	/* and register the chip */
+	if ((host = NCR_700_detect(&amiga7xx_scsi_driver_template, hostdata, &z->dev))
+	   == NULL) {
+		printk(KERN_ERR "amiga7xx-scsi: No host detected; board configuration problem?\n");
+		goto out_free;
+	}
 
-static struct {
-    zorro_id id;
-    unsigned long offset;
-    int absolute;	/* offset is absolute address */
-} amiga7xx_table[] = {
-    { .id = ZORRO_PROD_PHASE5_BLIZZARD_603E_PLUS, .offset = 0xf40000,
-      .absolute = 1 },
-    { .id = ZORRO_PROD_MACROSYSTEMS_WARP_ENGINE_40xx, .offset = 0x40000 },
-    { .id = ZORRO_PROD_CBM_A4091_1, .offset = 0x800000 },
-    { .id = ZORRO_PROD_CBM_A4091_2, .offset = 0x800000 },
-    { .id = ZORRO_PROD_GVP_GFORCE_040_060, .offset = 0x40000 },
-    { 0 }
-};
+	host->this_id = 7;
+	host->base = ioaddr;
+	host->irq = IRQ_AMIGA_PORTS;
 
-static int __init amiga7xx_zorro_detect(struct scsi_host_template *tpnt)
+	if (request_irq(host->irq, NCR_700_intr, IRQF_SHARED, "amiga7xx-scsi", host)) {
+		printk(KERN_ERR "amiga7xx-scsi: request_irq failed\n");
+		goto out_put_host;
+	}
+
+	scsi_scan_host(host);
+
+	return 0;
+
+ out_put_host:
+	scsi_host_put(host);
+ out_free:
+	if (ioaddr > 0x01000000)
+		iounmap(hostdata->base);
+	kfree(hostdata);
+ out_release:
+	zorro_release_device(z);
+
+	return -ENODEV;
+}
+
+static __devexit void amiga7xx_remove_one(struct zorro_dev *z)
 {
-    int num = 0, i;
-    struct zorro_dev *z = NULL;
-    unsigned long address;
-
-    while ((z = zorro_find_device(ZORRO_WILDCARD, z))) {
-	for (i = 0; amiga7xx_table[i].id; i++)
-	    if (z->id == amiga7xx_table[i].id)
-		break;
-	if (!amiga7xx_table[i].id)
-	    continue;
-	if (amiga7xx_table[i].absolute)
-	    address = amiga7xx_table[i].offset;
-	else
-	    address = z->resource.start + amiga7xx_table[i].offset;
-	num += amiga7xx_register_one(tpnt, address);
-    }
-    return num;
+	struct Scsi_Host *host = dev_to_shost(&z->dev);
+	struct NCR_700_Host_Parameters *hostdata =
+		(struct NCR_700_Host_Parameters *)host->hostdata[0];
+
+	scsi_remove_host(host);
+
+	NCR_700_release(host);
+	kfree(hostdata);
+	free_irq(host->irq, host);
+	zorro_release_device(z);
 }
 
+static struct zorro_driver amiga7xx_driver = {
+	.name	  = "amiga7xx-scsi",
+	.id_table = amiga7xx_zorro_tbl,
+	.probe	  = amiga7xx_init_one,
+	.remove	  = __devexit_p(amiga7xx_remove_one),
+};
+
 #endif /* CONFIG_ZORRO */
 
+#define A4000T_SCSI_ADDR 0xdd0040
 
-int __init amiga7xx_detect(struct scsi_host_template *tpnt)
+static int __devinit a4000t_probe(struct device *dev)
 {
-    static unsigned char called = 0;
-    int num = 0;
+	struct Scsi_Host * host = NULL;
+	struct NCR_700_Host_Parameters *hostdata;
+
+	if (!(MACH_IS_AMIGA && AMIGAHW_PRESENT(A4000_SCSI)))
+		goto out;
+	
+	if (!request_mem_region(A4000T_SCSI_ADDR, 0x1000, "A4000T builtin SCSI"))
+		goto out;
+
+	hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
+	if (hostdata == NULL) {
+		printk(KERN_ERR "a4000t-scsi: Failed to allocate host data\n");
+		goto out_release;
+	}
+	memset(hostdata, 0, sizeof(struct NCR_700_Host_Parameters));
+
+	/* Fill in the required pieces of hostdata */
+	hostdata->base = (void __iomem *)ZTWO_VADDR(A4000T_SCSI_ADDR);
+	hostdata->clock = 50;
+	hostdata->chip710 = 1;
+	hostdata->dmode_extra = DMODE_FC2;
+	hostdata->dcntl_extra = EA_710;
+
+	/* and register the chip */
+	if ((host = NCR_700_detect(&amiga7xx_scsi_driver_template, hostdata, dev))
+	   == NULL) {
+		printk(KERN_ERR "a4000t-scsi: No host detected; board configuration problem?\n");
+		goto out_free;
+	}
+
+	host->this_id = 7;
+	host->base = A4000T_SCSI_ADDR;
+	host->irq = IRQ_AMIGA_PORTS;
+
+	if (request_irq(host->irq, NCR_700_intr, IRQF_SHARED, "a4000t-scsi", host)) {
+		printk(KERN_ERR "a4000t-scsi: request_irq failed\n");
+		goto out_put_host;
+	}
+
+	scsi_scan_host(host);
 
-    if (called || !MACH_IS_AMIGA)
 	return 0;
 
-    tpnt->proc_name = "Amiga7xx";
+ out_put_host:
+	scsi_host_put(host);
+ out_free:
+	kfree(hostdata);
+ out_release:
+	release_mem_region(A4000T_SCSI_ADDR, 0x1000);
+ out:
+	return -ENODEV;
+}
+
+static __devexit int a4000t_device_remove(struct device *dev)
+{
+	struct Scsi_Host *host = dev_to_shost(dev);
+	struct NCR_700_Host_Parameters *hostdata =
+		(struct NCR_700_Host_Parameters *)host->hostdata[0];
+
+	scsi_remove_host(host);
+
+	NCR_700_release(host);
+	kfree(hostdata);
+	free_irq(host->irq, host);
+	release_mem_region(A4000T_SCSI_ADDR, 0x1000);
 
-    if (AMIGAHW_PRESENT(A4000_SCSI))
-	num += amiga7xx_register_one(tpnt, 0xdd0040);
+	return 0;
+}
+
+static struct device_driver a4000t_scsi_driver = {
+	.name	= "a4000t-scsi",
+	.bus	= &platform_bus_type,
+	.probe	= a4000t_probe,
+	.remove	= __devexit_p(a4000t_device_remove),
+};
+
+static int __init amiga7xx_scsi_init(void)
+{
+	int err;
+
+	if ((err = driver_register(&a4000t_scsi_driver)))
+		return err;
+
+	a4000t_scsi_device = platform_device_register_simple("a4000t-scsi", -1, NULL, 0);
+
+	if (IS_ERR(a4000t_scsi_device)) {
+		driver_unregister(&a4000t_scsi_driver);
+		return PTR_ERR(a4000t_scsi_device);
+	}
 
 #ifdef CONFIG_ZORRO
-    num += amiga7xx_zorro_detect(tpnt);
+	err = zorro_module_init(&amiga7xx_driver);
 #endif
 
-    called = 1;
-    return num;
+	return err;
 }
 
-static int amiga7xx_release(struct Scsi_Host *shost)
+static void __exit amiga7xx_scsi_exit(void)
 {
-	if (shost->irq)
-		free_irq(shost->irq, NULL);
-#ifdef CONFIG_ISA
-	if (shost->dma_channel != 0xff)
-		free_dma(shost->dma_channel);
+	platform_device_unregister(a4000t_scsi_device);
+	driver_unregister(&a4000t_scsi_driver);
+#ifdef CONFIG_ZORRO
+	zorro_unregister_driver(&amiga7xx_driver);
 #endif
-	if (shost->io_port && shost->n_io_port)
-		release_region(shost->io_port, shost->n_io_port);
-	scsi_unregister(shost);
-	return 0;
 }
 
-static struct scsi_host_template driver_template = {
-	.name			= "Amiga NCR53c710 SCSI",
-	.detect			= amiga7xx_detect,
-	.release		= amiga7xx_release,
-	.queuecommand		= NCR53c7xx_queue_command,
-	.eh_abort_handler	= NCR53c7xx_abort,
-	.eh_bus_reset_handler	= NCR53c7xx_reset,
-	.slave_configure	= NCR53c7xx_slave_configure,
-	.can_queue		= 24,
-	.this_id		= 7,
-	.sg_tablesize		= 63,
-	.cmd_per_lun		= 3,
-	.use_clustering		= DISABLE_CLUSTERING
-};
-
-
-#include "scsi_module.c"
+module_init(amiga7xx_scsi_init);
+module_exit(amiga7xx_scsi_exit);
Index: linux-2.6-m68k-vme/drivers/scsi/bvme6000_scsi.c
===================================================================
RCS file: linux-2.6-m68k-vme/drivers/scsi/bvme6000_scsi.c
diff -N linux-2.6-m68k-vme/drivers/scsi/bvme6000_scsi.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ linux-2.6-m68k-vme/drivers/scsi/bvme6000_scsi.c	31 Oct 2006 21:38:49 -0000
@@ -0,0 +1,132 @@
+/*
+ * Detection routine for the NCR53c710 based BVME6000 SCSI Controllers for Linux.
+ *
+ * Based on work by Alan Hourihane and Kars de Jong
+ *
+ * Rewritten to use 53c700.c by Richard Hirst <richard@sleepie.demon.co.uk>
+ */
+
+#include <linux/module.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <asm/bvme6000hw.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_transport.h>
+#include <scsi/scsi_transport_spi.h>
+
+#include "53c700.h"
+
+MODULE_AUTHOR("Richard Hirst <richard@sleepie.demon.co.uk>");
+MODULE_DESCRIPTION("BVME6000 NCR53C710 driver");
+MODULE_LICENSE("GPL");
+
+static struct scsi_host_template bvme6000_scsi_driver_template = {
+	.name			= "BVME6000 NCR53c710 SCSI",
+	.proc_name		= "BVME6000",
+	.this_id		= 7,
+	.module			= THIS_MODULE,
+};
+
+static struct platform_device *bvme6000_scsi_device;
+
+static __devinit int
+bvme6000_probe(struct device *dev)
+{
+	struct Scsi_Host * host = NULL;
+	struct NCR_700_Host_Parameters *hostdata;
+
+	if (!MACH_IS_BVME6000)
+		goto out;
+
+	hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
+	if (hostdata == NULL) {
+		printk(KERN_ERR "bvme6000-scsi: Failed to allocate host data\n");
+		goto out;
+	}
+	memset(hostdata, 0, sizeof(struct NCR_700_Host_Parameters));
+
+	/* Fill in the required pieces of hostdata */
+	hostdata->base = (void __iomem *)BVME_NCR53C710_BASE;
+	hostdata->clock = 40;	/* XXX - depends on the CPU clock! */
+	hostdata->chip710 = 1;
+	hostdata->dmode_extra = DMODE_FC2;
+	hostdata->dcntl_extra = EA_710;
+	hostdata->ctest7_extra = CTEST7_TT1;
+
+	/* and register the chip */
+	if ((host = NCR_700_detect(&bvme6000_scsi_driver_template, hostdata, dev))
+	   == NULL) {
+		printk(KERN_ERR "bvme6000-scsi: No host detected; board configuration problem?\n");
+		goto out_free;
+	}
+	host->base = BVME_NCR53C710_BASE;
+	host->this_id = 7;
+	host->irq = BVME_IRQ_SCSI;
+	if (request_irq(BVME_IRQ_SCSI, NCR_700_intr, 0, "bvme6000-scsi", host)) {
+		printk(KERN_ERR "bvme6000-scsi: request_irq failed\n");
+		goto out_put_host;
+	}
+
+	scsi_scan_host(host);
+
+	return 0;
+
+ out_put_host:
+	scsi_host_put(host);
+ out_free:
+	kfree(hostdata);
+ out:
+	return -ENODEV;
+}
+
+static __devexit int
+bvme6000_device_remove(struct device *dev)
+{
+	struct Scsi_Host *host = dev_to_shost(dev);
+	struct NCR_700_Host_Parameters *hostdata =
+		(struct NCR_700_Host_Parameters *)host->hostdata[0];
+
+	scsi_remove_host(host);
+	NCR_700_release(host);
+	kfree(hostdata);
+	free_irq(host->irq, host);
+
+	return 0;
+}
+
+static struct device_driver bvme6000_scsi_driver = {
+	.name	= "bvme6000-scsi",
+	.bus	= &platform_bus_type,
+	.probe	= bvme6000_probe,
+	.remove	= __devexit_p(bvme6000_device_remove),
+};
+
+static int __init bvme6000_scsi_init(void)
+{
+	int err;
+
+	if ((err = driver_register(&bvme6000_scsi_driver)))
+		return err;
+
+	bvme6000_scsi_device = platform_device_register_simple("bvme6000-scsi", -1, NULL, 0);
+
+	if (IS_ERR(bvme6000_scsi_device)) {
+		driver_unregister(&bvme6000_scsi_driver);
+		return PTR_ERR(bvme6000_scsi_device);
+	}
+
+	return 0;
+}
+
+static void __exit bvme6000_scsi_exit(void)
+{
+	platform_device_unregister(bvme6000_scsi_device);
+	driver_unregister(&bvme6000_scsi_driver);
+}
+
+module_init(bvme6000_scsi_init);
+module_exit(bvme6000_scsi_exit);
Index: linux-2.6-m68k-vme/drivers/scsi/mvme16x_scsi.c
===================================================================
RCS file: linux-2.6-m68k-vme/drivers/scsi/mvme16x_scsi.c
diff -N linux-2.6-m68k-vme/drivers/scsi/mvme16x_scsi.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ linux-2.6-m68k-vme/drivers/scsi/mvme16x_scsi.c	31 Oct 2006 21:38:49 -0000
@@ -0,0 +1,155 @@
+/*
+ * Detection routine for the NCR53c710 based MVME16x SCSI Controllers for Linux.
+ *
+ * Based on work by Alan Hourihane
+ *
+ * Rewritten to use 53c700.c by Kars de Jong <jongk@linux-m68k.org>
+ */
+
+#include <linux/module.h>
+#include <linux/blkdev.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <asm/mvme16xhw.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_transport.h>
+#include <scsi/scsi_transport_spi.h>
+
+#include "53c700.h"
+
+MODULE_AUTHOR("Kars de Jong <jongk@linux-m68k.org>");
+MODULE_DESCRIPTION("MVME16x NCR53C710 driver");
+MODULE_LICENSE("GPL");
+
+static struct scsi_host_template mvme16x_scsi_driver_template = {
+	.name			= "MVME16x NCR53c710 SCSI",
+	.proc_name		= "MVME16x",
+	.this_id		= 7,
+	.module			= THIS_MODULE,
+};
+
+static struct platform_device *mvme16x_scsi_device;
+
+static __devinit int
+mvme16x_probe(struct device *dev)
+{
+	struct Scsi_Host * host = NULL;
+	struct NCR_700_Host_Parameters *hostdata;
+
+	if (!MACH_IS_MVME16x)
+		goto out;
+
+	if (mvme16x_config & MVME16x_CONFIG_NO_SCSICHIP) {
+		printk(KERN_INFO "mvme16x-scsi: detection disabled, SCSI chip not present\n");
+		goto out;
+	}
+
+	hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
+	if (hostdata == NULL) {
+		printk(KERN_ERR "mvme16x-scsi: Failed to allocate host data\n");
+		goto out;
+	}
+	memset(hostdata, 0, sizeof(struct NCR_700_Host_Parameters));
+
+	/* Fill in the required pieces of hostdata */
+	hostdata->base = (void __iomem *)0xfff47000UL;
+	hostdata->clock = 50;	/* XXX - depends on the CPU clock! */
+	hostdata->chip710 = 1;
+	hostdata->dmode_extra = DMODE_FC2;
+	hostdata->dcntl_extra = EA_710;
+	hostdata->ctest7_extra = CTEST7_TT1;
+
+	/* and register the chip */
+	if ((host = NCR_700_detect(&mvme16x_scsi_driver_template, hostdata, dev))
+	   == NULL) {
+		printk(KERN_ERR "mvme16x-scsi: No host detected; board configuration problem?\n");
+		goto out_free;
+	}
+	host->this_id = 7;
+	host->base = 0xfff47000UL;
+	host->irq = MVME16x_IRQ_SCSI;
+	if (request_irq(host->irq, NCR_700_intr, 0, "mvme16x-scsi", host)) {
+		printk(KERN_ERR "mvme16x-scsi: request_irq failed\n");
+		goto out_put_host;
+	}
+
+	/* Enable scsi chip ints */
+	{
+		volatile unsigned long v;
+
+		/* Enable scsi interrupts at level 4 in PCCchip2 */
+		v = in_be32(0xfff4202c);
+		v = (v & ~0xff) | 0x10 | 4;
+		out_be32(0xfff4202c, v);
+	}
+
+	scsi_scan_host(host);
+
+	return 0;
+
+ out_put_host:
+	scsi_host_put(host);
+ out_free:
+	kfree(hostdata);
+ out:
+	return -ENODEV;
+}
+
+static __devexit int
+mvme16x_device_remove(struct device *dev)
+{
+	struct Scsi_Host *host = dev_to_shost(dev);
+	struct NCR_700_Host_Parameters *hostdata =
+		(struct NCR_700_Host_Parameters *)host->hostdata[0];
+
+	/* Disable scsi chip ints */
+	{
+		volatile unsigned long v;
+
+		v = in_be32(0xfff4202c);
+		v &= ~0x10;
+		out_be32(0xfff4202c, v);
+	}
+	scsi_remove_host(host);
+	NCR_700_release(host);
+	kfree(hostdata);
+	free_irq(host->irq, host);
+
+	return 0;
+}
+
+static struct device_driver mvme16x_scsi_driver = {
+	.name	= "mvme16x-scsi",
+	.bus	= &platform_bus_type,
+	.probe	= mvme16x_probe,
+	.remove	= __devexit_p(mvme16x_device_remove),
+};
+
+static int __init mvme16x_scsi_init(void)
+{
+	int err;
+
+	if ((err = driver_register(&mvme16x_scsi_driver)))
+		return err;
+
+	mvme16x_scsi_device = platform_device_register_simple("mvme16x-scsi", -1, NULL, 0);
+
+	if (IS_ERR(mvme16x_scsi_device)) {
+		driver_unregister(&mvme16x_scsi_driver);
+		return PTR_ERR(mvme16x_scsi_device);
+	}
+
+	return 0;
+}
+
+static void __exit mvme16x_scsi_exit(void)
+{
+	platform_device_unregister(mvme16x_scsi_device);
+	driver_unregister(&mvme16x_scsi_driver);
+}
+
+module_init(mvme16x_scsi_init);
+module_exit(mvme16x_scsi_exit);

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Geert Uytterhoeven]

On Tue, 31 Oct 2006, Kars de Jong wrote:
> On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> > Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> > mess in the upoming request_buffer transition, and unless the m68k
> > folks provide the new 53c700-based driver I'll just submit a patch to
> > rip 53c7xx and users out without replacement.
> 
> OK, here's the patch, without the m68k generic iomap changes.

Ah, the missing io{read,write}*() stuff :-)

> If there are no objections, I will commit it to our CVS repository so
> Geert can send it upstream (with proper Signed-Off-By: headers and
> everything).
> 
> This patch is relative to the m68k CVS repository, which is at kernel
> version 2.6.18.

You forgot this part, as zorro_module_init was removed in 2.6.17-rc1:

--- linux-m68k-2.6.19-rc4/drivers/scsi/amiga7xx.c.orig	2006-11-02 21:44:14.000000000 +0100
+++ linux-m68k-2.6.19-rc4/drivers/scsi/amiga7xx.c	2006-11-02 21:45:44.000000000 +0100
@@ -273,7 +273,7 @@ static int __init amiga7xx_scsi_init(voi
 	}
 
 #ifdef CONFIG_ZORRO
-	err = zorro_module_init(&amiga7xx_driver);
+	err = zorro_register_driver(&amiga7xx_driver);
 #endif
 
 	return err;

> I have renamed the mvme16x.c and bvme6000.c files to mvme16x_scsi.c and
> bvme6000_scsi.c respectively, I'm not sure if this is a good idea
> though.

I guess that's OK, as it makes the module name more sensible.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [RFC PATCH] m68k: switch to 53c700 driver

[James Bottomley]

On Tue, 2006-10-31 at 22:47 +0100, Kars de Jong wrote:
> On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> > Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> > mess in the upoming request_buffer transition, and unless the m68k
> > folks provide the new 53c700-based driver I'll just submit a patch to
> > rip 53c7xx and users out without replacement.
> 
> OK, here's the patch, without the m68k generic iomap changes.

Could you regenerate this against the current git-head?  I've tried
several merge points and I still can't get it to apply ... I suspect it
had additional m68k fixes in the original file.

Thanks,

James

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Geert Uytterhoeven]

On Sun, 17 Dec 2006, James Bottomley wrote:
> On Tue, 2006-10-31 at 22:47 +0100, Kars de Jong wrote:
> > On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> > > Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> > > mess in the upoming request_buffer transition, and unless the m68k
> > > folks provide the new 53c700-based driver I'll just submit a patch to
> > > rip 53c7xx and users out without replacement.
> > 
> > OK, here's the patch, without the m68k generic iomap changes.
> 
> Could you regenerate this against the current git-head?  I've tried
> several merge points and I still can't get it to apply ... I suspect it
> had additional m68k fixes in the original file.

Yes, it was against the m68k tree.

If Kars doesn't respond, you can try

m68k-generic-io.diff
m68k-mvme-scsi-rename.diff
m68k-53c700-scsi.diff

from http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/. These are
against 2.6.19.

BTW, are you interested in more Scsi_Cmnd -> struct scsi_cmnd patches? I have a
few of them lying around.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Al Viro]

On Mon, Dec 18, 2006 at 10:34:21AM +0100, Geert Uytterhoeven wrote:
> On Sun, 17 Dec 2006, James Bottomley wrote:
> > On Tue, 2006-10-31 at 22:47 +0100, Kars de Jong wrote:
> > > On ma, 2006-10-30 at 11:13 +0000, Christoph Hellwig wrote:
> > > > Any updates?  Honestly, I do not plan to touch the current 53c7xx/etc
> > > > mess in the upoming request_buffer transition, and unless the m68k
> > > > folks provide the new 53c700-based driver I'll just submit a patch to
> > > > rip 53c7xx and users out without replacement.
> > > 
> > > OK, here's the patch, without the m68k generic iomap changes.
> > 
> > Could you regenerate this against the current git-head?  I've tried
> > several merge points and I still can't get it to apply ... I suspect it
> > had additional m68k fixes in the original file.
> 
> Yes, it was against the m68k tree.
> 
> If Kars doesn't respond, you can try
> 
> m68k-generic-io.diff

Hmm...  That breaks when you have ISA && !PCI (e.g. amiga or q40 defconfig):

lib/built-in.o: In function `ioread32_rep':
(.text+0xc31a): undefined reference to `insl'
lib/built-in.o: In function `iowrite32_rep':
(.text+0xc43e): undefined reference to `outsl'
lib/built-in.o: In function `ioread32':
(.text+0xc7da): undefined reference to `readl'
lib/built-in.o: In function `iowrite32':
(.text+0xca6a): undefined reference to `writel'

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Kars de Jong]

On di, 2006-12-19 at 03:09 +0000, Al Viro wrote:
> > m68k-generic-io.diff
> 
> Hmm...  That breaks when you have ISA && !PCI (e.g. amiga or q40 defconfig):
> 
> lib/built-in.o: In function `ioread32_rep':
> (.text+0xc31a): undefined reference to `insl'
> lib/built-in.o: In function `iowrite32_rep':
> (.text+0xc43e): undefined reference to `outsl'
> lib/built-in.o: In function `ioread32':
> (.text+0xc7da): undefined reference to `readl'
> lib/built-in.o: In function `iowrite32':
> (.text+0xca6a): undefined reference to `writel'

Thanks for spotting that. I'll update the patch.

Kars.

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Christoph Hellwig]

On Fri, Dec 22, 2006 at 10:21:52PM +0100, Kars de Jong wrote:
> On di, 2006-12-19 at 03:09 +0000, Al Viro wrote:
> > > m68k-generic-io.diff
> > 
> > Hmm...  That breaks when you have ISA && !PCI (e.g. amiga or q40 defconfig):
> > 
> > lib/built-in.o: In function `ioread32_rep':
> > (.text+0xc31a): undefined reference to `insl'
> > lib/built-in.o: In function `iowrite32_rep':
> > (.text+0xc43e): undefined reference to `outsl'
> > lib/built-in.o: In function `ioread32':
> > (.text+0xc7da): undefined reference to `readl'
> > lib/built-in.o: In function `iowrite32':
> > (.text+0xca6a): undefined reference to `writel'
> 
> Thanks for spotting that. I'll update the patch.

Where do we stand on this?  IMHO we should just put the scsi driver
update in now so we can kill all the old cruft and let the notoriously
lagging m68k arch support catch up once they get the time for it.