Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

2012-09-10 Thread Aaron Lu
On 09/07/2012 02:50 AM, Alan Stern wrote: On Thu, 6 Sep 2012, Oliver Neukum wrote: But in the long run that wouldn't be a good solution. What I'd really like is a way to do the status polling without having it reset the idle timer. Oliver, what do you think? Would that be a good

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

2012-09-10 Thread Oliver Neukum
On Monday 10 September 2012 17:16:22 Aaron Lu wrote: +static int sr_resume(struct device *dev) +{ + struct scsi_cd *cd; + struct scsi_sense_hdr sshdr; + + cd = dev_get_drvdata(dev); + + if (!cd-device-powered_off) + return 0; + + /* get the disk ready */

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Pasi Kärkkäinen
On Sun, Aug 19, 2012 at 09:47:17AM -0400, Rich wrote: I've got open discussions with both Supermicro and LSI at the moment, and have shipped one of them a backplane and HBA to demonstrate this since they couldn't replicate it easily in-house. Hello, Any replies from Supermicro/LSI ? --

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Emmanuel Florac
Le Mon, 10 Sep 2012 16:47:11 +0300 Pasi Kärkkäinen pa...@iki.fi écrivait: Any replies from Supermicro/LSI ? Only loosely related, but Supermicro replaced recently my 846E26 (dual expander backplane) with 846E16 (single expander). Apparently they gave up getting the E26 to work properly or

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Pasi Kärkkäinen
On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote: Le Mon, 10 Sep 2012 16:47:11 +0300 Pasi Kärkkäinen pa...@iki.fi écrivait: Any replies from Supermicro/LSI ? Only loosely related, but Supermicro replaced recently my 846E26 (dual expander backplane) with 846E16 (single

[GIT PULL] SCSI fixes for 3.6-rc5

2012-09-10 Thread James Bottomley
Just a note to everyone: I had actually prepared this fix set before I left for KS + Plumbers, so it's been incubating much longer than it should have. I'll be picking up my three week backlog this week, so more fixes will then be forthcoming This set consist of three minor and one fairly major

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Pasi Kärkkäinen
On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote: On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote: Le Mon, 10 Sep 2012 16:47:11 +0300 Pasi Kärkkäinen pa...@iki.fi écrivait: Any replies from

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Rich
On Mon, Sep 10, 2012 at 12:13 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote: On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Mon, Sep 10, 2012 at 06:01:42PM +0200, Emmanuel Florac wrote: Le Mon, 10 Sep 2012 16:47:11

Re: Odd behavior of a SAS-2 backplane with SGPIO commands

2012-09-10 Thread Pasi Kärkkäinen
On Mon, Sep 10, 2012 at 12:14:35PM -0400, Rich wrote: On Mon, Sep 10, 2012 at 12:13 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Mon, Sep 10, 2012 at 12:07:45PM -0400, Rich wrote: On Mon, Sep 10, 2012 at 12:04 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Mon, Sep 10, 2012 at 06:01:42PM +0200,

Re: [PATCH] [SCSI] lpfc 8.3.32: use list_move_tail instead of list_del/list_add_tail

2012-09-10 Thread James Smart
Acked-by: James Smart james.sm...@emulex.com Thanks -- james s On 9/5/2012 2:49 AM, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Using list_move_tail() instead of list_del() + list_add_tail(). spatch with a semantic match is used to found this problem.

RE: [PATCH] [SCSI] libfcoe: use list_move instead of list_del/list_add

2012-09-10 Thread Zou, Yi
From: Wei Yongjun yongjun_...@trendmicro.com.cn Using list_move() instead of list_del() + list_add(). spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/scsi/fcoe/fcoe_ctlr.c |

Re: [PATCH] scsi_netlink: Remove dead and buggy code

2012-09-10 Thread David Miller
From: ebied...@xmission.com (Eric W. Biederman) Date: Fri, 07 Sep 2012 15:39:21 -0700 The scsi netlink code confuses the netlink port id with a process id, going so far as to read NETLINK_CREDS(skb)-pid instead of the correct NETLINK_CB(skb).pid. Fortunately it does not matter because

[PATCH] st: remove st_mutex

2012-09-10 Thread Lee Duncan
This patch is based on the misc branch of the SCSI tree and the 5-patch series for st sent by Jeff Mahoney 8/18/2012 and Ack-ed by Kai on 8/20. From: Jeff Mahoney je...@suse.com The st_mutex was created when the BKL was removed, and prevents simultaneous st_open calls. It is better to protect

Re: [PATCH] scsi_netlink: Remove dead and buggy code

2012-09-10 Thread James Bottomley
On Mon, 2012-09-10 at 15:07 -0400, David Miller wrote: From: ebied...@xmission.com (Eric W. Biederman) Date: Fri, 07 Sep 2012 15:39:21 -0700 The scsi netlink code confuses the netlink port id with a process id, going so far as to read NETLINK_CREDS(skb)-pid instead of the correct

Re: [PATCH] st: remove st_mutex

2012-09-10 Thread Lee Duncan
Please disregard this patch -- I have the meta-data wrong. I'll resubmit. On 09/10/2012 02:59 PM, Lee Duncan wrote: This patch is based on the misc branch of the SCSI tree and the 5-patch series for st sent by Jeff Mahoney 8/18/2012 and Ack-ed by Kai on 8/20. From: Jeff Mahoney

[PATCHv2] st: remove st_mutex

2012-09-10 Thread Lee Duncan
From: Hannes Reinecke h...@suse.com The st_mutex was created when the BKL was removed, and prevents simultaneous st_open calls. It is better to protect just the necessary data. Signed-off-by: Hannes Reinecke h...@suse.com Reviewed-by: Lee Duncan ldun...@suse.com This patch is based on the misc

[RFC PATCH 2/5] libfcoe: Create new libfcoe control interfaces

2012-09-10 Thread Robert Love
This patch is the first in a series that will remove libfcoe's create, destroy, enable and disable module parameters and replace them with interface files in the new /sys/bus/fcoe subsystem. Old layout: /sys/module/libfcoe/parameters/{create,destroy,enable,disable,vn2vn_create} New layout:

[RFC PATCH 1/5] libfcoe, fcoe: Allow user to set a ctlr's mode

2012-09-10 Thread Robert Love
This patch makes the 'mode' attribute of a fcoe_ctlr_device writale. This allows the user to store the mode with with the ctlr will be in. Possible modes would be 'Fabric', or 'VN2VN'. The default mode for a fcoe_ctlr{,_device} is 'Fabric'. Drivers must implement the set_fcoe_ctlr_mode routine

[RFC PATCH 4/5] bnx2fc: Use new fcoe_sysfs control interface

2012-09-10 Thread Robert Love
Convert bnx2fc to use the new fcoe_sysfs create, delete, enable, disable, start and mode. bnx2fc doesn't support VN2VN. bnx2fc will not initialize the set_fcoe_ctlr_mode routine and therefore its instances will always be in FABRIC mode. There was previously an explicit check for the ctlr's mode,

[RFC PATCH 0/5] Reorganize libfcoe control interfaces

2012-09-10 Thread Robert Love
The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create, vn2vn_create, destroy, enable and disable interfaces

[RFC PATCH 5/5] libfcoe, fcoe: Remove libfcoe module parameters

2012-09-10 Thread Robert Love
This patch removes the create, create_vn2vn, destroy, enable and disable module parameters. Previous patches have added these interfaces to the fcoe_sysfs layout and these misplaced interfaces are no longer necessary. Signed-off-by: Robert Love robert.w.l...@intel.com ---

[RFC PATCH 3/5] fcoe: Use new fcoe_sysfs control interface

2012-09-10 Thread Robert Love
Convert fcoe to use the new fcoe_sysfs create, delete, enable, disable, start and mode. Signed-off-by: Robert Love robert.w.l...@intel.com --- drivers/scsi/fcoe/fcoe.c | 229 +++--- 1 file changed, 115 insertions(+), 114 deletions(-) diff --git

Re: [RFC PATCH 1/5] libfcoe, fcoe: Allow user to set a ctlr's mode

2012-09-10 Thread Greg KH
On Mon, Sep 10, 2012 at 03:59:14PM -0700, Robert Love wrote: This patch makes the 'mode' attribute of a fcoe_ctlr_device writale. This allows the user to store the mode with with the ctlr will be in. Possible modes would be 'Fabric', or 'VN2VN'. The default mode for a fcoe_ctlr{,_device}

Re: [PATCH] Fix a use-after-free triggered by device removal

2012-09-10 Thread Tejun Heo
Hello, On Fri, Sep 07, 2012 at 08:57:10AM +0200, Bart Van Assche wrote: I'm not sure it would be a good idea to add a blk_queue_dead() check in any of the __blk_run_queue() variants since blk_drain_queue() can invoke __blk_run_queue() to drain the queue. Right, we can't cancel requests from

Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

2012-09-10 Thread Bhanu Prakash Gollapudi
On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create,

Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

2012-09-10 Thread Love, Robert W
On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote: On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles

Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

2012-09-10 Thread Bhanu Prakash Gollapudi
On 9/10/2012 6:41 PM, Love, Robert W wrote: On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote: On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs

Re: [RFC PATCH 1/5] libfcoe, fcoe: Allow user to set a ctlr's mode

2012-09-10 Thread Bart Van Assche
On 09/11/12 00:59, Robert Love wrote: +static enum fip_conn_type fcoe_parse_mode(const char *buf, + const struct fcoe_ctlr_mode_table *tbl) +{ + int modeint = -1, i, rv; + char *p, modestr[FCOE_MAX_MODENAME_LEN + 1] = { 0, }; + + for (p = (char