public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-kernel@vger.kernel.org, Kristian H??gsberg <krh@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux1394-devel <linux1394-devel@lists.sourceforge.net>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 5/6] firewire: SBP-2 highlevel driver
Date: Wed, 2 May 2007 20:44:08 +0100	[thread overview]
Message-ID: <20070502194408.GD1248@infradead.org> (raw)
In-Reply-To: <tkrat.c82a1d775d989371@s5r6.in-berlin.de>

> +	sg = (struct scatterlist *)orb->cmd->request_buffer;
> +	count = dma_map_sg(device->card->device, sg, orb->cmd->use_sg,
> +			   orb->cmd->sc_data_direction);

you need to handle the error case (count == 0)

> +	/* Convert the scatterlist to an sbp2 page table.  If any
> +	 * scatterlist entries are too big for sbp2 we split the as we go. */

Please set the max_sectors value in your host template so that the
block layer doesn't build sg entries too big for you.

> +	orb->page_table_bus =
> +		dma_map_single(device->card->device, orb->page_table,
> +			       size, DMA_TO_DEVICE);

This needs handling of mapping errors (dma_mapping_error())

> +	orb = kzalloc(sizeof *orb, GFP_ATOMIC);

Normal kernel style is sizeof(*orb)

> +	if (cmd->use_sg) {
> +		sbp2_command_orb_map_scatterlist(orb);
> +	} else if (cmd->request_bufflen > SBP2_MAX_SG_ELEMENT_LENGTH) {
> +		/* FIXME: Need to split this into a sg list... but
> +		 * could we get the scsi or blk layer to do that by
> +		 * reporting our max supported block size? */
> +		fw_error("command > 64k\n");
> +		goto fail_bufflen;
> +	} else if (cmd->request_bufflen > 0) {
> +		sbp2_command_orb_map_buffer(orb);
> +	}

The use_sg == 0, request_bufflen != 0 case can't happen anymore.

> + fail_mapping:
> +	kfree(orb);
> + fail_alloc:
> +	cmd->result = DID_ERROR << 16;
> +	done(cmd);

Failure due to ressource shortage should not complete the command
but return SCSI_MLQUEUE_HOST_BUSY/SCSI_MLQUEUE_DEVICE_BUSY.

> +	return 0;
> +}

> +static struct scsi_host_template scsi_driver_template = {
> +	.module			= THIS_MODULE,
> +	.name			= "SBP-2 IEEE-1394",
> +	.proc_name		= (char *)sbp2_driver_name,

Please don't use casrs here.  Either fix up the definition so it
accepts const strings or pass a non-const one.

> +static int add_scsi_devices(struct fw_unit *unit)
> +{
> +	struct sbp2_device *sd = unit->device.driver_data;
> +	int retval, lun;
> +
> +	if (sd->scsi_host != NULL)
> +		return 0;
> +
> +	sd->scsi_host = scsi_host_alloc(&scsi_driver_template,
> +					sizeof(unsigned long));
> +	if (sd->scsi_host == NULL) {
> +		fw_error("failed to register scsi host\n");
> +		return -1;
> +	}
> +
> +	sd->scsi_host->hostdata[0] = (unsigned long)unit;

Please take a look ar ther other scsi drivers how this is supposed
to be used.

> +	retval = scsi_add_host(sd->scsi_host, &unit->device);
> +	if (retval < 0) {
> +		fw_error("failed to add scsi host\n");
> +		scsi_host_put(sd->scsi_host);
> +		sd->scsi_host = NULL;
> +		return retval;
> +	}
> +
> +	/* FIXME: Loop over luns here. */
> +	lun = 0;
> +	retval = scsi_add_device(sd->scsi_host, 0, 0, lun);
> +	if (retval < 0) {
> +		fw_error("failed to add scsi device\n");
> +		scsi_remove_host(sd->scsi_host);
> +		scsi_host_put(sd->scsi_host);
> +		sd->scsi_host = NULL;
> +		return retval;
> +	}
> +
> +	return 0;
> +}

Do we really need another scanning algorithm?  Can't you use
scsi_scan_target instead and let the core scsi code handle the
scanning?

> +
> +static void remove_scsi_devices(struct fw_unit *unit)
> +{
> +	struct sbp2_device *sd = unit->device.driver_data;
> +
> +	if (sd->scsi_host != NULL) {
> +		scsi_remove_host(sd->scsi_host);
> +		scsi_host_put(sd->scsi_host);
> +	}
> +	sd->scsi_host = NULL;
> +}

This function seems rather oddly named.  And the checking and
setting of scsi_host looks like you have some lifetime rule
problems.


  parent reply	other threads:[~2007-05-02 19:44 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01 20:27 [git pull] New firewire stack Kristian Høgsberg
2007-05-01 21:34 ` Stefan Richter
2007-05-02  9:00 ` Christoph Hellwig
2007-05-02 12:13   ` Stefan Richter
2007-05-02 12:15     ` [PATCH 1/6] firewire: handling of cards, buses, nodes Stefan Richter
2007-05-02 12:16       ` [PATCH 2/6] firewire: isochronous and asynchronous I/O Stefan Richter
2007-05-02 12:17         ` [PATCH 3/6] firewire: char device interface Stefan Richter
2007-05-02 12:18           ` [PATCH 4/6] firewire: OHCI-1394 lowlevel driver Stefan Richter
2007-05-02 12:18             ` [PATCH 5/6] firewire: SBP-2 highlevel driver Stefan Richter
2007-05-02 12:19               ` [PATCH 6/6] firewire: add it all to kbuild Stefan Richter
2007-05-02 18:05                 ` Stefan Richter
2007-05-02 19:44                 ` Christoph Hellwig
2007-05-02 23:01                   ` Stefan Richter
2007-05-03  4:15                     ` Sam Ravnborg
2007-05-03  8:10                     ` Christoph Hellwig
2007-05-08  0:14                       ` Kristian Høgsberg
2007-05-02 19:44               ` Christoph Hellwig [this message]
2007-05-02 21:53                 ` [PATCH 5/6] firewire: SBP-2 highlevel driver Stefan Richter
2007-05-02 22:10                   ` Stefan Richter
2007-05-04  9:53                   ` Christoph Hellwig
2007-05-04 11:20                     ` Stefan Richter
2007-05-09 21:05                 ` Kristian Høgsberg
2007-05-09 21:48                   ` Stefan Richter
2007-05-09 21:57                   ` Stefan Richter
2007-05-09 22:13                     ` Kristian Høgsberg
2007-05-09 22:56                       ` Stefan Richter
2007-05-04 11:11             ` [PATCH 4/6] firewire: OHCI-1394 lowlevel driver Christoph Hellwig
2007-05-09 23:40               ` Kristian Høgsberg
2007-05-02 15:35           ` [PATCH 3/6] firewire: char device interface John Stoffel
2007-05-02 16:06             ` Stefan Richter
2007-05-02 21:11             ` Kristian Høgsberg
2007-05-04  9:48               ` Christoph Hellwig
2007-05-08  0:19                 ` Kristian Høgsberg
2007-05-02 19:30           ` Christoph Hellwig
2007-05-08  0:08             ` Kristian Høgsberg
2007-05-02 19:29         ` [PATCH 2/6] firewire: isochronous and asynchronous I/O Christoph Hellwig
2007-05-03  0:08           ` Kristian Høgsberg
2007-05-03  8:54             ` Stefan Richter
2007-05-02 15:55       ` [PATCH 1/6] firewire: handling of cards, buses, nodes Pekka Enberg
2007-05-02 19:16         ` Stefan Richter
2007-05-02 20:35           ` Pekka Enberg
2007-05-07 22:02             ` Kristian Høgsberg
2007-05-02 21:16         ` Kristian Høgsberg
2007-05-02 19:22       ` Christoph Hellwig
2007-05-07 23:42         ` Kristian Høgsberg
2007-05-02 20:00     ` [git pull] New firewire stack Kristian Høgsberg
2007-05-02 12:21 ` Olaf Hering
2007-05-02 12:48   ` Stefan Richter
2007-05-02 13:56     ` Gene Heskett
2007-05-02 18:51       ` Stefan Richter
2007-05-02 15:27     ` Adrian Bunk
2007-05-02 20:03       ` Kristian Høgsberg
2007-05-02 19:53   ` Kristian Høgsberg
2007-05-02 20:03     ` Olaf Hering
2007-05-10 17:26 ` [git pull] New firewire stack (updated) Stefan Richter
2007-05-10 17:38   ` Christoph Hellwig
2007-05-10 17:51     ` Adrian Bunk
2007-05-10 17:56     ` Stefan Richter
2007-05-10 18:05     ` Stefan Richter

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=20070502194408.GD1248@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=krh@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=torvalds@linux-foundation.org \
    /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