public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, garloff@suse.de,
	matthias.andree@gmx.de, gl@dsa-ac.de
Subject: Re: [PATCH] Re: AMD 53c974 SCSI driver in 2.6
Date: Fri, 31 Oct 2003 11:46:17 +0000	[thread overview]
Message-ID: <20031031114616.A16435@infradead.org> (raw)
In-Reply-To: <24432.1067599508@www47.gmx.net>; from g.liakhovetski@gmx.de on Fri, Oct 31, 2003 at 12:25:08PM +0100

On Fri, Oct 31, 2003 at 12:25:08PM +0100, Guennadi Liakhovetski wrote:
> (Replying fromo the web-interface, hope, the email will not be scrued up 
> completely).

Seems fine.

> > Any reason you fix this driver?  The tmcsim one for the same hardware
> > looks like much better structured (though a bit obsufacted :))?
> 
> This is the easiest to asnwer: Kurt Garloff wrote to me, saying that he 
> would fix the tmcsim driver, so, I didn't want to duplicate the work. Also, 
> I was considering this mostly as a fun-excersice, not really hoping / aiming

Ah, okay.

> > > +#ifdef AM53C974_MULTIPLE_CARD
> > > +#error "FIXME! Multiple card support is broken. Looks like it never
> > really worked. Might have to be fixed."
> > >  static struct Scsi_Host *first_host;	/* Head of list of AMD boards */
> > > +#endif
> > 
> > Why do you need the undef?  It looks like you need to kill a #define for
> > this symbol somewhere else :)
> 
> So that, when it is fixed, somebody can easily switch it on / off:-)

Then just comment ou the #define.  Rule of the thumb:  #undef always means
you screwed up elsewhere :)

> 
> > > -	save_flags(flags);
> > > -	cli();
> > > +	local_irq_save(flags);
> > 
> > That's not safe on SMP, you must mark the driver BROKEN_ON_SMP or better
> > fix this.
> 
> Yes. Again - the fix was pretty much mechanical. I didn't understand why it
> was considered SMP-safe to just disable local interrupts, so, just preferred
> to go the "minimal modifications" path.

cli() disabled all intereupts in 2.4 which was safe, you only disable local
interrupts which is ok on UP but doesn't work on SMP.  The right fix would
be to introduce spinlocks.  But given the driver design this might be
everything but easy - that's why I think killing the driver in favour of tmcsim
might be the better idea.

> > Not sure whether you're interested in fixing this, but the proper way
> > to fix that would be to call request_irq for each card, mark the irq's
> > sharable.  The irq handler then can use the void * argument to find the
> > right host and you can kill all this ugly host list walking.  That shold
> > get multiple host support working again in theory  (ok, except that the
> > driver has a totally broken single state machine..)
> 
> Sure - in irq-handler. But are these lists needed anywhere else, where a
> function is called in an "abstract" context without a dev-pointer? Probably,
> not.

A poper driver shouldn't do that, but we already know this one isn't..

> > >  	if (cmd->use_sg) {
> > >  		cmd->SCp.buffer = (struct scatterlist *) cmd->buffer;
> > >  		cmd->SCp.buffers_residual = cmd->use_sg - 1;
> > > -		cmd->SCp.ptr = (char *) cmd->SCp.buffer->address;
> > > +		cmd->SCp.ptr = (char *) page_address(cmd->SCp.buffer->page) +
> > cmd->SCp.buffer->offset;
> > 
> > This means you need a dma_mask < highmem to work.  I don't think we
> > want such crude hacks merged, could you please convert it to the proper
> > dma API?
> 
> Found in a "working" driver (which has to be fixed too, then). Will try to 
> find a proper fix (for the new driver).

Oh.  What driver did you find this construct in?


  reply	other threads:[~2003-10-31 11:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-25 21:42 AMD 53c974 SCSI driver in 2.6 Guennadi Liakhovetski
2003-10-26 19:49 ` Guennadi Liakhovetski
2003-10-30 22:12   ` [PATCH] " Guennadi Liakhovetski
2003-10-30 23:52     ` Kurt Garloff
2003-10-31  9:47       ` Christoph Hellwig
2003-10-31  9:59         ` Kurt Garloff
2003-10-31 10:06           ` Christoph Hellwig
2003-10-31  9:46     ` Christoph Hellwig
2003-10-31 11:25       ` Guennadi Liakhovetski
2003-10-31 11:46         ` Christoph Hellwig [this message]
2003-10-31 12:19           ` Guennadi Liakhovetski
2003-10-31 13:09             ` Russell King
2003-11-02 19:22           ` Guennadi Liakhovetski
  -- strict thread matches above, loose matches on Subject: below --
2003-12-11  9:01 Tomas Martisius
2003-12-11 11:12 ` Christoph Hellwig
2003-12-11 20:10   ` Guennadi Liakhovetski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031031114616.A16435@infradead.org \
    --to=hch@infradead.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=garloff@suse.de \
    --cc=gl@dsa-ac.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.andree@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox