From: Andrew Morton <akpm@linux-foundation.org>
To: "Yang, Bo" <Bo.Yang@lsi.com>
Cc: Bo.Yang@lsi.com, James.Bottomley@HansenPartnership.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Winston.Austria@lsi.com
Subject: Re: [PATCH 2/9] scsi: megaraid_sas - Add poll wait support to megaraid sas driver - I
Date: Wed, 18 Feb 2009 16:21:13 -0800 [thread overview]
Message-ID: <20090218162113.0333c6ed.akpm@linux-foundation.org> (raw)
In-Reply-To: <4B6A08C587958942AA3002690DD4F8C33A07FB3B@cosmail02.lsi.com>
On Tue, 17 Feb 2009 08:25:07 -0700
"Yang, Bo" <Bo.Yang@lsi.com> wrote:
> Add Poll_wait mechanism to Gen-2 MegaRAID SAS Linux driver. In the aen handler, driver needs to wakeup poll handler similar to the way it raises SIGIO. Driver needs to reregister for AEN with the FW when it receives AEN.
Please try to keep the text to less than 80 columns.
> Signed-off-by Bo Yang<bo.yang@lsi.com>
"Signed-off-by:"
> ---
> drivers/scsi/megaraid/megaraid_sas.c | 133 ++++++++++++++++++++++++++++++++++-
> drivers/scsi/megaraid/megaraid_sas.h | 15 +++
> 2 files changed, 147 insertions(+), 1 deletion(-)
Please use scripts/checkpatch.pl? This patch adds a tremendous number
of coding-style errors. checkpatch detects other problems too.
> diff -rupN linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c
> --- linux-2.6.28_orig/drivers/scsi/megaraid/megaraid_sas.c 2009-02-12 15:36:36.000000000 -0500
> +++ linux-2.6.28_new/drivers/scsi/megaraid/megaraid_sas.c 2009-02-12 15:39:26.000000000 -0500
> @@ -40,6 +40,7 @@
> #include <linux/compat.h>
> #include <linux/blkdev.h>
> #include <linux/mutex.h>
> +#include <linux/poll.h>
>
> #include <scsi/scsi.h>
> #include <scsi/scsi_cmnd.h>
> @@ -89,6 +90,11 @@ static struct megasas_mgmt_info megasas_
> static struct fasync_struct *megasas_async_queue;
> static DEFINE_MUTEX(megasas_async_queue_mutex);
>
> +static int megasas_poll_wait_aen;
> +static DECLARE_WAIT_QUEUE_HEAD (megasas_poll_wait);
Like the undesirable space here.
> +extern void
> +poll_wait(struct file *filp, wait_queue_head_t *q, poll_table *token);
And that.
What on earth are we doing declaring a core VFS function from within a
scsi driver's .c file?
There is a definition of poll_wait() in include/linux/poll.h.
> static u32 megasas_dbg_lvl;
>
> static void
> @@ -1277,6 +1283,8 @@ megasas_bios_param(struct scsi_device *s
> return 0;
> }
>
> +static void megasas_aen_polling(void *arg);
> +
> /**
> * megasas_service_aen - Processes an event notification
> * @instance: Adapter soft state
> @@ -1295,8 +1303,20 @@ megasas_service_aen(struct megasas_insta
> /*
> * Don't signal app if it is just an aborted previously registered aen
> */
> - if (!cmd->abort_aen)
> + if ((!cmd->abort_aen) && (instance->unload == 0)) {
> + struct megasas_aen_event *ev;
> + ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
> + if (!ev) {
> + printk(KERN_ERR "%s: out of memory\n", __FUNCTION__);
> + } else {
> + ev->instance = instance;
> + INIT_WORK(&ev->hotplug_work, megasas_aen_polling);
> + schedule_delayed_work(&ev->hotplug_work, 0);
I see a schedule_delayed_work(), but no cancel_delayed_work().
By what means does the driver ensure that there is no pending work
after device close, device suspend, module removal, etc?
> + }
> + megasas_poll_wait_aen = 1;
> + wake_up(&megasas_poll_wait);
> kill_fasync(&megasas_async_queue, SIGIO, POLL_IN);
> + }
> else
> cmd->abort_aen = 0;
>
> @@ -2621,6 +2641,7 @@ megasas_probe_one(struct pci_dev *pdev,
>
> megasas_dbg_lvl = 0;
> instance->flag = 0;
> + instance->unload = 0;
> instance->last_time = 0;
>
> /*
> @@ -2924,6 +2945,7 @@ static void __devexit megasas_detach_one
> struct megasas_instance *instance;
>
> instance = pci_get_drvdata(pdev);
> + instance->unload = 1;
> host = instance->host;
>
> if (poll_mode_io)
> @@ -3027,6 +3049,21 @@ static int megasas_mgmt_fasync(int fd, s
> }
>
> /**
> + * megasas_mgmt_poll - char node "poll" entry point
> + * */
> +static unsigned int megasas_mgmt_poll(struct file *file, poll_table *wait)
> +{
> + unsigned int mask = 0;
> + poll_wait(file, &megasas_poll_wait, wait);
> +
The blank line would typically go after end-of-locals and before
start-of-code.
> + if (megasas_poll_wait_aen) {
> + mask |= (POLLIN | POLLRDNORM);
> + megasas_poll_wait_aen = 0;
> + }
> + return mask;
> +}
> +
> +/**
> * megasas_mgmt_fw_ioctl - Issues management ioctls to FW
> * @instance: Adapter soft state
> * @argp: User's ioctl packet
> @@ -3348,6 +3385,7 @@ static const struct file_operations mega
> .open = megasas_mgmt_open,
> .fasync = megasas_mgmt_fasync,
> .unlocked_ioctl = megasas_mgmt_ioctl,
> + .poll = megasas_mgmt_poll,
> #ifdef CONFIG_COMPAT
> .compat_ioctl = megasas_mgmt_compat_ioctl,
> #endif
> @@ -3462,6 +3500,99 @@ out:
> return retval;
> }
>
> +
> +static void
> +megasas_aen_polling(struct work_struct *work)
> +{
> + struct megasas_aen_event *ev =
> + container_of(work, struct megasas_aen_event, hotplug_work);
Rather than playing 80-column party tricks, it's much more natural to do:
struct megasas_aen_event *ev;
...
ev = container_of(work, struct megasas_aen_event, hotplug_work);
> + struct megasas_instance *instance = ev->instance;
> + struct megasas_evt_log_info eli;
> + union megasas_evt_class_locale class_locale;
> + int doscan = 0;
> + u32 seq_num;
> + int error;
> +
> + if (!instance) {
> + printk(KERN_ERR "%s: invalid instance!\n", __FUNCTION__);
> + kfree(ev);
> + return;
> + }
> +
> + if (instance->evt_detail) {
> + printk(KERN_INFO "%s[%d]: event code 0x%04x\n", __FUNCTION__,
> + instance->host->host_no, instance->evt_detail->code);
> +
> + switch (instance->evt_detail->code) {
> +
> + case MR_EVT_LD_CREATED:
> + case MR_EVT_PD_INSERTED:
> + case MR_EVT_LD_DELETED:
> + case MR_EVT_LD_OFFLINE:
> + case MR_EVT_CFG_CLEARED:
> + case MR_EVT_PD_REMOVED:
> + case MR_EVT_FOREIGN_CFG_IMPORTED:
> + case MR_EVT_LD_STATE_CHANGE:
> + doscan = 1;
> + break;
> + default:
> + doscan = 0;
> + break;
> + }
> + } else {
> + printk(KERN_ERR "%s[%d]: invalid evt_detail!\n",
> + __FUNCTION__, instance->host->host_no);
> + kfree(ev);
> + return;
> + }
> +
> + if (doscan) {
> + printk(KERN_INFO "%s[%d]: scanning ...\n",
> + __FUNCTION__, instance->host->host_no);
> + scsi_scan_host(instance->host);
> + msleep(1000);
This leaves a keventd thread unavailable for use by the rest of the
kernel for an entire second. It's a shared resource, and this is quite
rude.
It would be better to schedule another work one second hence. And to
remember to cancel it on the close/shutdown/suspend/rmmod/etc path, of
course..
> + }
> +
> + kfree(ev);
> + /**
> + * Get the latest sequence number from FW
> + **/
The /** token is used to introduce kerneldoc comments. This is not a
kerneldoc comment and there is no point in avoiding standard coding
style here.
For single-line comments:
/* Get the latest sequence number from FW */
For multi-line comments:
/*
* Get the latest sequence number from FW
* blah blah
*/
> + memset(&eli, 0, sizeof(eli));
> +
> + if (megasas_get_seq_num(instance, &eli)) {
> + printk(KERN_ERR "%s[%d]: failed to get seq_num\n",
> + __FUNCTION__, instance->host->host_no);
> + return;
> + }
> +
> + seq_num = instance->evt_detail->seq_num + 1;
> +
> + /**
> + * Register AEN with FW for latest sequence number plus 1
> + **/
> +
> + class_locale.members.reserved = 0;
> + class_locale.members.locale = MR_EVT_LOCALE_ALL;
> + class_locale.members.class = MR_EVT_CLASS_DEBUG;
> +
> + down(&instance->aen_mutex);
> +
> + error = megasas_register_aen(instance, seq_num,
> + class_locale.word);
> +
> + up(&instance->aen_mutex);
wot?
aen_mutex has type `struct mutex'. down() and up() are used against
`struct semaphore'.
This code should have emitted compile warnings, and crashed at runtime.
next prev parent reply other threads:[~2009-02-19 0:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 17:09 [PATCH 1/6] scsi: megaraid_sas - add hibernation support bo yang
2007-11-16 21:31 ` Yang, Bo
2007-11-16 22:18 ` James Bottomley
[not found] ` <9738BCBE884FDB42801FAD8A7769C26501C9A4AF@NAMAIL1.ad.lsil.com>
2008-03-18 7:13 ` [PATCH 1/4] scsi: megaraid_sas - Rollback the sense info implementation bo yang
2008-03-17 7:36 ` [PATCH 2/4] scsi: megaraid_sas - Fix the frame count calculation bo yang
2008-03-17 8:13 ` [PATCH 3/4] scsi: megaraid_sas - Add the new controller Support to Driver bo yang
2008-08-01 16:48 ` [PATCH 2/4] scsi: megaraid_sas - Add the shutdown DCMD cmd to driver shutdown routine Yang, Bo
2008-08-01 21:17 ` [PATCH 3/4] scsi: megaraid_sas - Add the new controllers support Yang, Bo
2008-08-01 21:25 ` [PATCH 4/4] scsi: megaraid_sas - Version and Documentation Update Yang, Bo
2008-03-17 8:18 ` [PATCH 4/4] scsi: megaraid_sas - Update the Version and Changelog bo yang
2008-03-17 20:54 ` James Bottomley
2008-03-17 21:00 ` [PATCH 4/4] scsi: megaraid_sas - Update the Version andChangelog Yang, Bo
2009-02-17 14:44 ` [PATCH 1/9] scsi: megaraid_sas - Fix the tape drive support Yang, Bo
2009-02-17 15:25 ` [PATCH 2/9] scsi: megaraid_sas - Add poll wait support to megaraid sas driver - I Yang, Bo
2009-02-17 15:36 ` [PATCH 3/9] scsi: megaraid_sas - Add poll wait support to megaraid sas driver - II Yang, Bo
2009-02-17 15:51 ` [PATCH 4/9] scsi: megaraid_sas - Add new controller 0x73(new SAS2) support to the driver Yang, Bo
2009-02-17 16:37 ` [PATCH 5/9] scsi: megaraid_sas - Add memory support required by 0x73 controller Yang, Bo
2009-02-17 17:09 ` [PATCH 6/9] scsi: megaraid_sas - Report the unconfigured PD (system PD) to OS Yang, Bo
2009-02-17 17:21 ` [PATCH 7/9] scsi: megaraid_sas - Resign the Application cmds to 0x73 (new SAS2) controller Yang, Bo
2009-02-17 17:31 ` [PATCH 8/9] scsi: megaraid_sas - Add the IEEE SGL support to the driver Yang, Bo
2009-02-17 17:50 ` [PATCH 9/9] scsi: megaraid_sas - Update the Version and ChangeLog Yang, Bo
2009-02-19 0:38 ` [PATCH 8/9] scsi: megaraid_sas - Add the IEEE SGL support to the driver Andrew Morton
2009-02-19 0:30 ` [PATCH 5/9] scsi: megaraid_sas - Add memory support required by 0x73 controller Andrew Morton
2009-02-19 0:21 ` Andrew Morton [this message]
2009-02-19 13:55 ` [PATCH 2/9] scsi: megaraid_sas - Add poll wait support to megaraid sas driver - I Yang, Bo
2009-05-05 23:55 ` [PATCH 1/10] scsi: megaraid_sas - tape drive support fix Yang, Bo
2009-05-06 0:25 ` [PATCH 2/10] scsi: megaraid_sas - Add Poll Wait mechanism to MegaRAID SAS driver (PART-I) Yang, Bo
2009-05-06 0:41 ` [PATCH 3/10] scsi: megaraid_sas - Add Poll Wait mechanism to MegaRAID SAS driver (PART-II) Yang, Bo
2009-05-06 1:11 ` [PATCH 4/10] scsi: megaraid_sas - Add New SAS 2 (iMR) controller support to the driver Yang, Bo
2009-05-06 1:24 ` [PATCH 5/10] scsi: megaraid_sas - Fixed load/unload issue and Fire the system pd DCDB cmd to MegaRAID SAS FW to get the system PDs Yang, Bo
2009-05-06 1:35 ` [PATCH 6/10] scsi: megaraid_sas - Report the Unconfigured PD (system PD) to OS Yang, Bo
2009-05-06 1:43 ` [PATCH 7/10] scsi: megaraid_sas - Re-assign the Cmds to Application for the iMR controller Yang, Bo
2009-05-06 1:52 ` [PATCH 8/10] scsi: megaraid_sas - Driver adds the IEEE SGE format to support SAS 2 controller Yang, Bo
2009-05-06 2:08 ` [PATCH 9/10] scsi: megaraid_sas - Fixed the logic drives deleted and cmds pending in FW issue Yang, Bo
2009-05-06 2:12 ` [PATCH 10/10] scsi: megaraid_sas - Version and Documentation update Yang, Bo
2009-05-06 21:20 ` [PATCH 5/10] scsi: megaraid_sas - Fixed load/unload issue and Fire the system pd DCDB cmd to MegaRAID SAS FW to get the system PDs Andrew Morton
2009-05-07 15:05 ` Yang, Bo
2009-05-06 21:19 ` [PATCH 3/10] scsi: megaraid_sas - Add Poll Wait mechanism to MegaRAID SAS driver (PART-II) Andrew Morton
2009-05-06 21:17 ` [PATCH 2/10] scsi: megaraid_sas - Add Poll Wait mechanism to MegaRAID SAS driver (PART-I) Andrew Morton
2009-05-07 14:56 ` Yang, Bo
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=20090218162113.0333c6ed.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Bo.Yang@lsi.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Winston.Austria@lsi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.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