Since 2.5.31, the compilation of kernel/dma.c is conditional on
CONFIG_GENERIC_ISA_DMA. However, drivers/scsi/hosts.c unconditionally calls
free_dma(), which breaks machines with SCSI that don't have ISA.
Please apply!
--- linux-2.5.46/drivers/scsi/hosts.c Thu Oct 31 10:15:33 2002
+++ linux-m68k-2.5.46/drivers/scsi/hosts.c Fri Nov 8 14:27:59 2002
@@ -27,6 +27,7 @@
* hosts currently present in the system.
*/
+#include <linux/config.h>
#include <linux/module.h>
#include <linux/blk.h>
#include <linux/kernel.h>
@@ -98,8 +99,10 @@
{
if (shost->irq)
free_irq(shost->irq, NULL);
+#ifdef CONFIG_GENERIC_ISA_DMA
if (shost->dma_channel != 0xff)
free_dma(shost->dma_channel);
+#endif
if (shost->io_port && shost->n_io_port)
release_region(shost->io_port, shost->n_io_port);
}
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
On Fri, Nov 08, 2002 at 02:46:40PM +0100, Geert Uytterhoeven wrote:
> Since 2.5.31, the compilation of kernel/dma.c is conditional on
> CONFIG_GENERIC_ISA_DMA. However, drivers/scsi/hosts.c unconditionally calls
> free_dma(), which breaks machines with SCSI that don't have ISA.
This isn't actually the original purpose of CONFIG_GENERIC_ISA_DMA (it
was to allow an architecture to provide ISA-like DMA without having to
use the ISA DMA request/free functions - eg, they need to claim interrupts
on request_dma() and free them on free_dma()).
However, since this function isn't used on ARM, it doesn't affect me,
and so I don't have any problem with this patch. 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 8 Nov 2002, Russell King wrote:
> On Fri, Nov 08, 2002 at 02:46:40PM +0100, Geert Uytterhoeven wrote:
> > Since 2.5.31, the compilation of kernel/dma.c is conditional on
> > CONFIG_GENERIC_ISA_DMA. However, drivers/scsi/hosts.c unconditionally calls
> > free_dma(), which breaks machines with SCSI that don't have ISA.
>
> This isn't actually the original purpose of CONFIG_GENERIC_ISA_DMA (it
> was to allow an architecture to provide ISA-like DMA without having to
> use the ISA DMA request/free functions - eg, they need to claim interrupts
> on request_dma() and free them on free_dma()).
Then what's the correct(TM) fix? Unconditionally #define
CONFIG_GENERIC_ISA_DMA, so it behaves like before?
> However, since this function isn't used on ARM, it doesn't affect me,
> and so I don't have any problem with this patch. 8)
Hehe ;-)
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
On Fri, Nov 08, 2002 at 03:22:55PM +0100, Geert Uytterhoeven wrote:
> On Fri, 8 Nov 2002, Russell King wrote:
> > This isn't actually the original purpose of CONFIG_GENERIC_ISA_DMA (it
> > was to allow an architecture to provide ISA-like DMA without having to
> > use the ISA DMA request/free functions - eg, they need to claim interrupts
> > on request_dma() and free them on free_dma()).
>
> Then what's the correct(TM) fix? Unconditionally #define
> CONFIG_GENERIC_ISA_DMA, so it behaves like before?
Probably the correct answer is to get everyone to use an explicit release
function and just kill scsi_host_generic_release() entirely.
However, I'm sure other people will have differing views on that.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 2002-11-08 at 14:42, Russell King wrote:
> Probably the correct answer is to get everyone to use an explicit release
> function and just kill scsi_host_generic_release() entirely.
>
> However, I'm sure other people will have differing views on that.
There are three things I'd like to do in that area
1. Make a release function mandatory (and I'm happy to paste it into the
old scsi drivers)
2. Call eh_abort/eh_reset_* without taking the lock as we do now
3. Make all the midlayer callers use scatter gather lists for all
requests.
#1 and #3 are I think doable for 2.6, #2 is a bit more questionable.
(#3 is easy because drivers supporting the old non sg case still work
just fine)
Alan Cox [[email protected]] wrote:
> On Fri, 2002-11-08 at 14:42, Russell King wrote:
> > Probably the correct answer is to get everyone to use an explicit release
> > function and just kill scsi_host_generic_release() entirely.
> >
> > However, I'm sure other people will have differing views on that.
>
> There are three things I'd like to do in that area
>
> 1. Make a release function mandatory (and I'm happy to paste it into the
> old scsi drivers)
This sounds good to get rid of this function. My list of drivers having
detect functions shows only 16 of 103 would need the addition of a
release function.
There is already a check for detect at the top of the scsi_register_host
function. When release is added a printk would also be nice to indicate
lack of these required functions. Douglas Gilbert is starting to work on
updating the api document so we can change the required field to yes if
the driver is using the scsi_register_host / scsi_unregister_host
interface and not-required if it using Christoph's newer scsi_add_host /
scsi_remove_host.
-andmike
--
Michael Anderson
[email protected]
On Fri, Nov 08, 2002 at 04:20:21PM +0000, Alan Cox wrote:
> On Fri, 2002-11-08 at 14:42, Russell King wrote:
> > Probably the correct answer is to get everyone to use an explicit release
> > function and just kill scsi_host_generic_release() entirely.
> >
> > However, I'm sure other people will have differing views on that.
>
> There are three things I'd like to do in that area
>
> 1. Make a release function mandatory (and I'm happy to paste it into the
> old scsi drivers)
No. I restructured the BHA interfaces to get rid of ->detect and
->release. Makeing it mandatory is a step backwards. Not having a
default fallback is a good idea, though.
On Sat, 2002-11-09 at 00:53, Christoph Hellwig wrote:
> No. I restructured the BHA interfaces to get rid of ->detect and
> ->release. Makeing it mandatory is a step backwards. Not having a
> default fallback is a good idea, though.
That IMHO is not a 2.6 change
On Sat, Nov 09, 2002 at 01:13:05PM +0000, Alan Cox wrote:
> On Sat, 2002-11-09 at 00:53, Christoph Hellwig wrote:
> > No. I restructured the BHA interfaces to get rid of ->detect and
> > ->release. Makeing it mandatory is a step backwards. Not having a
> > default fallback is a good idea, though.
>
> That IMHO is not a 2.6 change
My restructuring? It's already in 2.5..