Re: ultrastor.c is a bit-rot

[James Bottomley]

On Mon, 2008-03-17 at 18:00 +0200, Boaz Harrosh wrote:
> On Mon, Mar 17 2008 at 17:23 +0200, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 2008-03-17 at 16:59 +0200, Boaz Harrosh wrote:
> >> Inspecting ultrastor.c it is clear to me that this was never used for
> >> a loooooooooong time. Not since a PC has more then 2^24 bit of memory.
> >> Let me explain below.
> >>
> >> Now I'm not saying it should be fixed. I'm saying that it should be dumped
> >> in the account that it is not used by any one and that it does not work.
> >>
> >> Why it never worked?
> >> ~~~~~~~~~~~~~~~~~~~~~
> >>
> >> The driver's header says it supports 3 cards
> >>
> >>  *	14F - ISA first-party DMA HA with floppy support and WD1003 emulation.
> >>  *	24F - EISA Bus Master HA with floppy support and WD1003 emulation.
> >>  *	34F - VL-Bus Bus Master HA with floppy support (no WD1003 emulation).
> >>
> >> But Kconfig only specifies ISA. I'm not sure what a VL-Bus is.
> > 
> > VL is vesa local ... it was an ISA like graphics bus that was fast and
> > could reach > 16MB.
> > 
> >> now the driver defines a static array of structures like this:
> >>
> >> 	struct {
> >> 	  ...
> >> 	
> >> 	  struct mscp mscp[ULTRASTOR_MAX_CMDS];
> >> 	} config = {0};
> >>
> >> and allocates a struct mscp in .queuecommand like this:
> >> 	    my_mscp = &config.mscp[mscp_index];
> >>
> >> it will go on preparing this my_mscp structure including stuffing
> >> some mapped pointers. Lets put that aside for now.
> >> At the very end it will pass this my_mscp structure to the card's 
> >> firmware like this:
> >>
> >> 	    /* Store pointer in OGM address bytes */
> >> 	outl(isa_virt_to_bus(my_mscp), config.ogm_address);
> >>
> >> Now this is one hell of a smart ISA card. But putting this aside.
> >>
> >> if the machine has more then 2^24 of memory. Then this will never
> >> work, right? or I'm missing it completely?
> > 
> > It will definitely work for EISA and VL bus.  I think if you analyse the
> > placement of kernel data segments for compiled in drivers, it might also
> > work for ISA too, since I think the pfn will be low enough.  It should
> > fail as a module not just because the area will be out of range for ISA,
> > but also because the module data segment is in vmalloc space, so the
> > virt_to_bus assumptions of contiguity could be violated.
> > 
> > James
> > 
> 
> So what is the verdict? is it removed? marked broken for ISA?

It's probably obvious enough to apply the best straight line fix.

> can I safely say that unchecked_isa_dma can be removed?

No ... ISA definitely requires it.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/