public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Boutcher <sleddog@us.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] ibmvscsi driver - next version
Date: Mon, 23 Feb 2004 14:45:42 +0000	[thread overview]
Message-ID: <20040223144542.A9624@infradead.org> (raw)
In-Reply-To: <opr3s2iefyl6e53g@us.ibm.com>; from sleddog@us.ibm.com on Sun, Feb 22, 2004 at 10:24:04PM -0600

On Sun, Feb 22, 2004 at 10:24:04PM -0600, Dave Boutcher wrote:
> This is the next version of the SCSI driver to support the adapter 
> implemented by the IBM Power5 firmware.  I have incorporated all comments 
>  from the first submission, which has resulted in a much cleaner, leaner, 
> meaner version.

Okay, this looks much better.  A few more comments:

+#include <linux/module.h>
+#include <scsi/scsi_device.h>
+#include "ibmvscsi.h"

	any reason you hid all headers in ibmvscsi.h?  normally we include
	them in the source files directly.

+MODULE_PARM(max_id, "i");
+MODULE_PARM_DESC(max_id, "Largest ID value for each channel");
+MODULE_PARM(max_channel, "i");
+MODULE_PARM_DESC(max_channel, "Largest channel value");

	please use module_param{_named,} to make the options also
	available at the boot-time command line

+static int initialize_event_pool(struct event_pool *pool, int size, struct ibmvscsi_host_data *hostdata)

	please wraper after 80chars according to Documentation/CodingStyle

+	if(!pool->events)

	another nitpick, above document says this should be

	if (!pool->events)

	dito in a few other places

+static int ibmvscsi_send_srp_event(struct srp_event_struct *evt_struct, struct ibmvscsi_host_data *hostdata)
+{
+	struct scsi_cmnd *cmnd;
+	unsigned long flags;
+	u64 *crq_as_u64 = (u64*)&evt_struct->crq;
+
+	/* If we have exhausted our request limit, just queue this request */
+	if (atomic_dec_if_positive(&hostdata->request_limit)< 0) {
+		printk("ibmvscsi: Warning, request_limit exceeded\n");
+		return SCSI_MLQUEUE_HOST_BUSY;

	Is there a specific reason host_busy / can_queue can don't the
	request limit checking for you?

+	} else {

	Why the else if we just returned?

+		/* Add this to the sent list.  We need to do this before we actually send 
+		 * in case it comes back REALLY fast
+		 */
+		spin_lock_irqsave(&hostdata->lock, flags);
+		list_add_tail(&evt_struct->list, &hostdata->sent);
+		spin_unlock_irqrestore(&hostdata->lock, flags);

	Do you really need the hostdata lock in addition to the scsi
	host_lock?

		
+			cmnd->result = DID_ERROR << 16;
+			evt_struct->cmnd_done(cmnd);
+			return SCSI_MLQUEUE_HOST_BUSY;

	This is wrong - either you set an error in cmnd->result and
	return 0 or your return non-zero from queuecommand, but not both.

+	/* Check if we are in a dead state before we go any farther */
+	if (atomic_read(&hostdata->request_limit) < 0) {
+		printk("ibmvscsi: rejecting SCSI command on failed adapter\n");
+		return FAILED;
+	}

	What about just setting can_queue to 0 when the adapter fails?
	Also the return value is wrong, valid return values are 0 or
	SCSI_MLQUEUE_{DEVICE,HOST}_BUSY.


+/* ------------------------------------------------------------
+ * Routines for driver initialization
+ */
+static void error_cleanup(struct ibmvscsi_host_data *hostdata) {
+	struct Scsi_Host *host = hostdata->host;
+	release_event_pool(&hostdata->pool, hostdata);
+	ibmvscsi_release_crq_queue(&hostdata->queue, hostdata);
+	memset(hostdata, 0xff, sizeof(*hostdata));

	You can't poison the hostdata as it's only freed on ->release
	which might be much later, e.g. if a sysfs file is opened.

+	scsi_host_put(host);
+}

	This routine needs rreformating, btw - and as you use it only
	from login_rsp it might better be placed in there after an error
	goto.

+	found_evt = NULL;
+	spin_lock_irqsave(&hostdata->lock, flags);
+	if(!list_empty(&hostdata->sent)) {
+		list_for_each_safe(pos, next, &hostdata->sent) {
+			tmp_evt = list_entry(pos, struct srp_event_struct, list);
+			
+			if (tmp_evt->cmnd == cmd) {
+				found_evt = tmp_evt;
+				break;
+			}
+		}
+	}
+	spin_unlock_irqrestore(&hostdata->lock, flags);
+	
+	/* If we can't find this event, just return false */
+	if (found_evt == NULL) {
+		printk(KERN_ERR "ibmvscsi: failed to abort command\n");
+		return FAILED;
+	}

	This can't ever happen.  You will only get called for commands
	that you have accepted in queuecommand and not called the completion
	routine for.

+static void purge_requests(struct ibmvscsi_host_data *hostdata) {
+	struct srp_event_struct *tmp_evt;
+	struct list_head	*pos, *next;
+	unsigned long flags;
+
+	spin_lock_irqsave(&hostdata->lock, flags);
+	if(!list_empty(&hostdata->sent)) {
+		list_for_each_safe(pos, next, &hostdata->sent) {
+			tmp_evt = list_entry(pos, struct srp_event_struct, list);

	The list_for_each* macros are safe against empty lists.
	What about using list_for_each_entry_safe, btw?

+	/* Now remove the event from the sent queue.  If it is not there, we have a REALLY
+	 * wierd race condition, probably involving an abort.  Don't call the "done" 
+	 * method in that case.
+	 */
+	if (list_empty(&evt_struct->list)) {
+		printk(KERN_ERR "ibmvscsi: unexpected SRP response received!\n");
+		return;
+	} else {
+		list_del(&evt_struct->list);
+	}

	list_del on empty lists is okay..

+int ibmvscsi_remove(struct ibmvscsi_host_data *hostdata)
+{
+	/* send an SRP_I_LOGOUT */
+	printk(KERN_INFO "ibmvscsi: remove called\n");

	this looks overly verbose, I don't remember any other LLDD do this.

	-> here you need a scsi_remove_host <-

+	
+	release_event_pool(&hostdata->pool, hostdata);
+	ibmvscsi_release_crq_queue(&hostdata->queue, hostdata);
+
+	scsi_host_put(hostdata->host);
+	return 0;

	I think it should just return void

+int __init ibmvscsi_module_init(void)
+{
+	return ibmvscsi_register_driver();
+}
+
+void __exit ibmvscsi_module_exit(void)
+{
+	ibmvscsi_unregister_driver();
+}	
+module_init(ibmvscsi_module_init);
+module_exit(ibmvscsi_module_exit);

	useless layering - just put the module_init/exit into the
	iseris/rpa subdrivers.

+/* global variables */
+extern struct device *iSeries_vio_dev;
+static struct ibmvscsi_host_data *single_host_data = NULL; 

	You don't need  to inialize static variables to zero.

+/* ------------------------------------------------------------
+ * Routines for managing the command/response queue
+ */

	Stale comment?

+/**
+ * This stub is needed by ibmvscsi
+ */
+void ibmvscsi_task(unsigned long data) 
+{
+}

	I think you should just set up the task in the rpa subdriver
	when it's not needed by the iseries one.

+#include <asm/vio.h>
+#include <asm/pci_dma.h>
+#include <asm/hvcall.h>
+#include "ibmvscsi.h"
+#include <linux/interrupt.h> 

	linux/*.h before asm/*.h before your own headers, please.

+/**
+ * ibmvscsi_task: - Process srps asynchronously
+ * @data:	ibmvscsi_host_data of host
+ */
+void ibmvscsi_task(unsigned long data) 

	Isn't this a workqueue handler?  Last time I checked they took
	void * and not unsigned long

+	struct ibmvscsi_host_data *hostdata = ibmvscsi_probe(&vdev->dev);
+	if (hostdata) {
+		vdev->driver_data = hostdata;

	Please alwasy use dev_set_drvdata/dev_get_drvdata.

+char rpa_driver_name[] = "ibmvscsi";                                                                            
+static struct vio_driver ibmvscsi_driver = {
+	.name		= rpa_driver_name,

	Why not put the name directly in here?


  reply	other threads:[~2004-02-23 14:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-23  4:24 [PATCH] ibmvscsi driver - next version Dave Boutcher
2004-02-23 14:45 ` Christoph Hellwig [this message]
2004-02-23 19:41   ` Dave Boutcher
2004-02-23 19:49     ` Christoph Hellwig
2004-02-23 20:52   ` Brian King
2004-02-23 21:08     ` Christoph Hellwig
2004-02-23 22:08       ` Mike Anderson

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=20040223144542.A9624@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sleddog@us.ibm.com \
    /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