Removing BROKEN scsi drivers

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 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.

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 3 lines · Andi Kleen

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 ...

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines · Andi Kleen

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 3 lines

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.

Quoted 6 lines · Christoph Hellwig

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines · Andi Kleen

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 7 lines

Quoted 3 lines

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.

Quoted 15 lines · Richard Hirst

Quoted 6 lines · Christoph Hellwig

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines · Andi Kleen

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

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.

Quoted 10 lines · Kars de Jong

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

Quoted 15 lines · Richard Hirst

Quoted 6 lines · Christoph Hellwig

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines · Andi Kleen

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 24 lines · Kars de Jong

Quoted 15 lines · Richard Hirst

Quoted 6 lines · Christoph Hellwig

Quoted 5 lines · Matthew Wilcox

Quoted 3 lines · Andi Kleen

SCSI_AMIGA7XX - no maintainer, broken forever
MVME16x_SCSI - no maintainer, broken forever
BVME6000_SCSI - same

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

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 -- [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-m68k" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines · Geert Uytterhoeven

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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 6 lines · Kars de Jong

Quoted 3 lines

Quoted 2 lines

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?

Quoted 1 line

Did you make any progress on this?

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

53c700: Version 2.8 By [email protected]
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)...

Quoted 9 lines · Ingo Juergensmann

Quoted 1 line

Did you make any progress on this?

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

53c700: Version 2.8 By [email protected]
scsi0: 53c710 rev 2
53c700: dmode=80 dcntl=01 ctest7=02
scsi0 : WarpEngine 40xx

Quoted 6 lines

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?

Quoted 1 line

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.

Quoted 17 lines · Christoph Hellwig

Quoted 15 lines · Ingo Juergensmann

Quoted 1 line

Did you make any progress on this?

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

53c700: Version 2.8 By [email protected]
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)...

Quoted 1 line

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.

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.

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.

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.

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

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?

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.

Quoted 3 lines · James Bottomley

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:

Quoted 4 lines

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.

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.

+#ifdef CONFIG_53C700_BE_BUS)

I noticed one thing in the patch:

Quoted 1 line

+#ifdef CONFIG_53C700_BE_BUS)

                              ^

There's a trailing ) there.

Quoted 3 lines · James Bottomley

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:

Quoted 1 line

+#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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

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.

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.

Quoted 6 lines · Richard Hirst

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?

Quoted 4 lines · Christoph Hellwig

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.

Quoted 5 lines · Kars de Jong

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.

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.

Quoted 4 lines · Christoph Hellwig

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.

Quoted 4 lines · Christoph Hellwig

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.

Quoted 6 lines · Kars de Jong

Quoted 4 lines · Christoph Hellwig

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.

Quoted 1 line

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.

Quoted 7 lines · James Bottomley

Quoted 6 lines · Kars de Jong

Quoted 4 lines · Christoph Hellwig

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.

Quoted 5 lines

Quoted 1 line

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

Quoted 1 line

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'

Quoted 4 lines · Al Viro

Quoted 1 line

m68k-generic-io.diff

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

Quoted 8 lines

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.

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

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.

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.