Re: [PATCH v7 2/6] scsi: sr: support runtime pm
On 10/08/2012 06:21 PM, James Bottomley wrote: On Mon, 2012-10-08 at 17:27 +0800, Aaron Lu wrote: On Sun, Sep 30, 2012 at 03:43:27PM -0400, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Regardless, according to Aaron the ZP power-off stuff is currently implemented only in ACPI, tied more closely to the ATA layer than the SCSI layer (though not part of either). It is not part of the SCSI spec in any form. The mechanism of SATA ODD zero power model is specified in Mount Fuji spec v8 section 15 describing what the ODD needs support, how to sense if the ODD is ready to be powered off and on power up what needs to be done, etc. And the actual power off and wakeup is implemented in ACPI and SATA. Now it's true that determining whether a device is in the right state for power to be removed involves sending a TEST UNIT READY command, which is of course a SCSI command. This seems to be incidental to the overall scheme, however. I need to add that, there are 2 schemes to sense if the ODD is ready to be powered off: 1 the one I used here, by checking if the door is closed and no media inside with test_unit_ready; 2 some ZP capable ODDs can report zero power ready(ZPReady) event to host when queried, eliminating the need of host checking the conditions. The way I read the standard is that ZP ODD is a hack to try and get to Thanks for your time. off and ZPready is the same hack but integrated into the standardised power management states (and hence available to normal power saving). The standard even implies ZP ODD is a less desirable hack by recommending the use of ZPready. There are ZPODDs not supporting ZPready and I want to support them so the sense scheme 1 is used. The ZPready method, being an extension of the usual SCSI power management model, is pretty much what we support today (especially as the whole thing is timer driven from values in the mode page and happens pretty much invisibly to us). Since the object is to make this as painless as possible, why don't we just implement ZPODD the way the spec recommends? i.e. emulate the timers at an incredibly low level and intercept and emulate the non-disk commands listed in table 321. I bet, in Linux, since we moved basically to GET_EVENT_STATUS_NOTIFICATION, that's the only one that actually needs an emulation. The state model seems to work if you snoop the polled media event, so you wait for no media, then set your internal timer, stop it if we get a media change and power off the device after interval expiry. Thereafter you emulate media event with no change keeping the device powered off. If a disc gets inserted or the eject button is pressed, you see that via the SATA PHY events (so wake the drive) and if the Upper Layer sends an unexpected command, you also power on the drive. That way all of this should be nicely containable within SATA/ACPI. Thanks for the suggestion, it is really something that I've never thought of :-) But I was hoping to use the runtime pm framework to support ZPODD. With your suggestion, I don't know how to do this. Maybe I can set the scsi device representing the ODD to runtime suspended once I decided to power it off and resume it when I power it up. But there is a problem, that I'm setting a scsi device's runtime status in ATA layer, this doesn't feel right. And someday, someone may want to add runtime pm support for sr and the runtime status of the scsi device will be messed. The reason I want to use runtime PM is, when the scsi device is runtime suspended, its ancestor devices will have a chance to enter runtime suspend state, e.g. the sata controller. Thanks, Aaron -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Decoding short sense buffers
Hi all, I've noticed that virtually everybody assumes that the length of the sense buffer is SCSI_SENSE_BUFFERSIZE. And consequently every caller uses SCSI_SENSE_BUFFERSIZE when calling any of the sense processing functions like scsi_normalize_sense() etc. However, those processing functions to go into great detail handling _shorter_ buffersizes, which of course will never happen. On the other hand, most LLDDs are capable of detecting the actually transmitted sense buffer sizes; there even is a field in struct request which would allow us to transmit the number of bytes in the sense buffer. But this field is happily neglected, too. So, questions here: - Do we actually care for a sense buffer underflow? We won't be able to detect it currently anyway; plus we haven't received any error reports for it. And the allocated sense buffer is _always_ SCSI_SENSE_BUFFERSIZE ... - What is the intention of rq-sense_len? From what I gather it _should_ hold the size of the received sense buffer data. But that doesn't happen currently. For short sense buffers that doesn't matter, but for sense buffer _overruns_ it would be quite good to know. Which causes quite some confusion on how to probe for valid sense data: - DRIVER_SENSE ? - rq-sense_len? - scsi_normalize_sense? Thanks for clarification. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS : update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers
Updating the MAINTAINERS file for the entry LSILOGIC MPT FUSION DRIVERS Signed-off-by: Sreekanth Reddy sreekanth.re...@lsi.com --- diff --git a/MAINTAINERS b/MAINTAINERS index 14bc707..de4a3a8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4282,13 +4282,16 @@ S: Maintained F: fs/logfs/ LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) -M: Eric Moore eric.mo...@lsi.com +M: Nagalakshmi Nandigama nagalakshmi.nandig...@lsi.com +M: Sreekanth Reddy sreekanth.re...@lsi.com M: supp...@lsi.com L: dl-mptfusionli...@lsi.com L: linux-scsi@vger.kernel.org W: http://www.lsilogic.com/support S: Supported F: drivers/message/fusion/ +F: drivers/scsi/mpt2sas/ +F: drivers/scsi/mpt3sas/ LSILOGIC/SYMBIOS/NCR 53C8XX and 53C1010 PCI-SCSI drivers M: Matthew Wilcox matt...@wil.cx -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] arcmsr: Re-name the HBA Type
On Wed, 2012-10-03 at 20:39 +0800, NickCheng wrote:
From: Nick Cheng nick.ch...@areca.com.tw
Replace the nameing, hba, hbb and hbc, with hbaA, hbaB abd hbaC respectively
Signed-off-by: Nick Cheng nick.ch...@areca.com.tw
---
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla//drivers/scsi/arcmsr/arcmsr.h
linux-development//drivers/scsi/arcmsr/arcmsr.h
--- linux-vanilla//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
18:29:18.030657090 +0800
+++ linux-development//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
18:43:58.542648536 +0800
This patch is linebroken and can't be applied. Whatever mail tool
you're using must have broken the lines. Please see
Documentation/email-clients.txt
About how to fix this and resubmit.
Thanks,
James
@@ -51,7 +51,7 @@ struct device_attribute;
#else
#define ARCMSR_MAX_FREECCB_NUM 320
#endif
-#define ARCMSR_DRIVER_VERSION Driver Version 1.20.00.15
2010/08/05
+#define ARCMSR_DRIVER_VERSION Driver Version 1.20.00.15
2012/09/30
#define ARCMSR_SCSI_INITIATOR_ID
255
#define ARCMSR_MAX_XFER_SECTORS
512
#define ARCMSR_MAX_XFER_SECTORS_B
4096
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c
linux-development//drivers/scsi/arcmsr/arcmsr_hba.c
--- linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
18:29:18.030657090 +0800
+++ linux-development//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
18:43:58.542648536 +0800
@@ -61,6 +61,7 @@
#include linux/aer.h
#include asm/dma.h
#include asm/io.h
+#include asm/system.h
#include asm/uaccess.h
#include scsi/scsi_host.h
#include scsi/scsi.h
@@ -95,16 +96,16 @@ static void arcmsr_iop_init(struct Adapt
static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb);
static u32 arcmsr_disable_outbound_ints(struct AdapterControlBlock *acb);
static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb);
static void arcmsr_request_device_map(unsigned long pacb);
-static void arcmsr_request_hba_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbb_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbc_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_request_device_map(struct AdapterControlBlock
*acb);
+static void arcmsr_hbaB_request_device_map(struct AdapterControlBlock
*acb);
+static void arcmsr_hbaC_request_device_map(struct AdapterControlBlock
*acb);
static void arcmsr_message_isr_bh_fn(struct work_struct *work);
static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb);
static void arcmsr_start_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_hbc_message_isr(struct AdapterControlBlock *pACB);
+static void arcmsr_hbaC_message_isr(struct AdapterControlBlock *pACB);
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
@@ -308,7 +309,7 @@ static void arcmsr_define_adapter_type(s
}
}
-static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock
*acb)
+static uint8_t arcmsr_hbaA_wait_msgint_ready(struct AdapterControlBlock
*acb)
{
struct MessageUnit_A __iomem *reg = acb-pmuA;
int i;
@@ -326,7 +327,7 @@ static uint8_t arcmsr_hba_wait_msgint_re
return false;
}
-static uint8_t arcmsr_hbb_wait_msgint_ready(struct AdapterControlBlock
*acb)
+static uint8_t arcmsr_hbaB_wait_msgint_ready(struct AdapterControlBlock
*acb)
{
struct MessageUnit_B *reg = acb-pmuB;
int i;
@@ -346,7 +347,7 @@ static uint8_t arcmsr_hbb_wait_msgint_re
return false;
}
-static uint8_t arcmsr_hbc_wait_msgint_ready(struct AdapterControlBlock
*pACB)
+static uint8_t arcmsr_hbaC_wait_msgint_ready(struct AdapterControlBlock
*pACB)
{
struct MessageUnit_C *phbcmu = (struct MessageUnit_C *)pACB-pmuC;
int i;
@@ -364,13 +365,13 @@ static uint8_t arcmsr_hbc_wait_msgint_re
return false;
}
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb)
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb)
{
struct MessageUnit_A __iomem *reg = acb-pmuA;
int retry_count = 30;
writel(ARCMSR_INBOUND_MESG0_FLUSH_CACHE, reg-inbound_msgaddr0);
do {
- if (arcmsr_hba_wait_msgint_ready(acb))
+ if (arcmsr_hbaA_wait_msgint_ready(acb))
break;
else {
retry_count--;
@@ -380,13 +381,13 @@ static void arcmsr_flush_hba_cache(struc
[PATCH 1/5] arcmsr: Re-name the HBA Type
From: Nick Cheng nick.ch...@areca.com.tw
Replace the nameing, hba, hbb and hbc, with hbaA, hbaB abd hbaC respectively
Signed-off-by: Nick Cheng nick.ch...@areca.com.tw
---
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla//drivers/scsi/arcmsr/arcmsr.h
linux-development//drivers/scsi/arcmsr/arcmsr.h
--- linux-vanilla//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
18:29:18.030657090 +0800
+++ linux-development//drivers/scsi/arcmsr/arcmsr.h 2012-10-03
18:43:58.542648536 +0800
@@ -51,7 +51,7 @@ struct device_attribute;
#else
#define ARCMSR_MAX_FREECCB_NUM 320
#endif
-#define ARCMSR_DRIVER_VERSION Driver Version 1.20.00.15
2010/08/05
+#define ARCMSR_DRIVER_VERSION Driver Version 1.20.00.15
2012/09/30
#define ARCMSR_SCSI_INITIATOR_ID
255
#define ARCMSR_MAX_XFER_SECTORS
512
#define ARCMSR_MAX_XFER_SECTORS_B
4096
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c
linux-development//drivers/scsi/arcmsr/arcmsr_hba.c
--- linux-vanilla//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
18:29:18.030657090 +0800
+++ linux-development//drivers/scsi/arcmsr/arcmsr_hba.c 2012-10-03
18:43:58.542648536 +0800
@@ -61,6 +61,7 @@
#include linux/aer.h
#include asm/dma.h
#include asm/io.h
+#include asm/system.h
#include asm/uaccess.h
#include scsi/scsi_host.h
#include scsi/scsi.h
@@ -95,16 +96,16 @@ static void arcmsr_iop_init(struct Adapt
static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb);
static u32 arcmsr_disable_outbound_ints(struct AdapterControlBlock *acb);
static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb);
static void arcmsr_request_device_map(unsigned long pacb);
-static void arcmsr_request_hba_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbb_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbc_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_request_device_map(struct AdapterControlBlock
*acb);
+static void arcmsr_hbaB_request_device_map(struct AdapterControlBlock
*acb);
+static void arcmsr_hbaC_request_device_map(struct AdapterControlBlock
*acb);
static void arcmsr_message_isr_bh_fn(struct work_struct *work);
static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb);
static void arcmsr_start_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_hbc_message_isr(struct AdapterControlBlock *pACB);
+static void arcmsr_hbaC_message_isr(struct AdapterControlBlock *pACB);
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
@@ -308,7 +309,7 @@ static void arcmsr_define_adapter_type(s
}
}
-static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock
*acb)
+static uint8_t arcmsr_hbaA_wait_msgint_ready(struct AdapterControlBlock
*acb)
{
struct MessageUnit_A __iomem *reg = acb-pmuA;
int i;
@@ -326,7 +327,7 @@ static uint8_t arcmsr_hba_wait_msgint_re
return false;
}
-static uint8_t arcmsr_hbb_wait_msgint_ready(struct AdapterControlBlock
*acb)
+static uint8_t arcmsr_hbaB_wait_msgint_ready(struct AdapterControlBlock
*acb)
{
struct MessageUnit_B *reg = acb-pmuB;
int i;
@@ -346,7 +347,7 @@ static uint8_t arcmsr_hbb_wait_msgint_re
return false;
}
-static uint8_t arcmsr_hbc_wait_msgint_ready(struct AdapterControlBlock
*pACB)
+static uint8_t arcmsr_hbaC_wait_msgint_ready(struct AdapterControlBlock
*pACB)
{
struct MessageUnit_C *phbcmu = (struct MessageUnit_C *)pACB-pmuC;
int i;
@@ -364,13 +365,13 @@ static uint8_t arcmsr_hbc_wait_msgint_re
return false;
}
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb)
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb)
{
struct MessageUnit_A __iomem *reg = acb-pmuA;
int retry_count = 30;
writel(ARCMSR_INBOUND_MESG0_FLUSH_CACHE, reg-inbound_msgaddr0);
do {
- if (arcmsr_hba_wait_msgint_ready(acb))
+ if (arcmsr_hbaA_wait_msgint_ready(acb))
break;
else {
retry_count--;
@@ -380,13 +381,13 @@ static void arcmsr_flush_hba_cache(struc
} while (retry_count != 0);
}
-static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb)
+static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb)
{
struct MessageUnit_B *reg = acb-pmuB;
int retry_count = 30;
writel(ARCMSR_MESSAGE_FLUSH_CACHE, reg-drv2iop_doorbell);
do {
- if
Re: [PATCH 1/5] arcmsr: Re-name the HBA Type
On Tue, 2012-10-09 at 21:23 +0800, NickCheng wrote: From: Nick Cheng nick.ch...@areca.com.tw Replace the nameing, hba, hbb and hbc, with hbaA, hbaB abd hbaC respectively Signed-off-by: Nick Cheng nick.ch...@areca.com.tw This is still malformed in exactly the same way diff -uprN -X linux-vanilla/Documentation/dontdiff linux-vanilla//drivers/scsi/arcmsr/arcmsr.h linux-development//drivers/scsi/arcmsr/arcmsr.h --- linux-vanilla//drivers/scsi/arcmsr/arcmsr.h 2012-10-03 There's a spurious carriage return here which kills the patch applicability 18:29:18.030657090 +0800 James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Tuesday, October 09, 2012 7:38 AM To: KY Srinivasan Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux- s...@vger.kernel.org; sta...@vger.kernel.org Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path On Mon, 2012-10-08 at 15:51 +, KY Srinivasan wrote: -Original Message- From: K. Y. Srinivasan [mailto:k...@microsoft.com] Sent: Tuesday, October 02, 2012 2:04 PM To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org Cc: KY Srinivasan; sta...@vger.kernel.org Subject: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path Properly account for I/O in transit before returning from the RESET call. In the absense of this patch, we could have a situation where the host may respond to a command that was issued prior to the issuance of the RESET command at some arbitrary time after responding to the RESET command. Currently, the host does not do anything with the RESET command. Signed-off-by: K. Y. Srinivasan k...@microsoft.com Cc: sta...@vger.kernel.org --- drivers/scsi/storvsc_drv.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 528d52b..0144078 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1221,7 +1221,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd) /* * At this point, all outstanding requests in the adapter * should have been flushed out and return to us + * There is a potential race here where the host may be in + * the process of responding when we return from here. + * Just wait for all in-transit packets to be accounted for + * before we return from here. */ + storvsc_wait_to_drain(stor_device); return SUCCESS; } -- 1.7.4.1 James, This patch is critical for running Linux based workloads on our Cloud infrastructure - Azure. Please let me know if there are any issues. So just for next time: it's a bit hard to work out this is a critical issue from the change log. If I had to guess, I'd say the response to a command killed by reset causes some type of use after free and a potential oops (all of which would have been very nice in the change log)? You guessed right! My apologies, I will add such details in the change log in the future. Regards, K. Y James
[PATCH/GIT PULL] UAPI: (Scripted) Disintegrate include/scsi
This completes part of the Userspace API (UAPI) disintegration for which the preparatory patches were pulled recently. After these patches, userspace headers will be segregated into: include/uapi/linux/.../foo.h for the userspace interface stuff, and: include/linux/.../foo.h for the strictly kernel internal stuff. This patch can be pulled from: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-scsi-20121009 Signed-off-by: David Howells dhowe...@redhat.com Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Thomas Gleixner t...@linutronix.de Acked-by: Michael Kerrisk mtk.manpa...@gmail.com Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com Acked-by: Dave Jones da...@redhat.com --- diff --git a/include/scsi/Kbuild b/include/scsi/Kbuild index f2b9491..562ff9d 100644 --- a/include/scsi/Kbuild +++ b/include/scsi/Kbuild @@ -1,4 +1 @@ -header-y += scsi_netlink.h -header-y += scsi_netlink_fc.h -header-y += scsi_bsg_fc.h header-y += fc/ diff --git a/include/uapi/scsi/Kbuild b/include/uapi/scsi/Kbuild index 29a87dd..75746d5 100644 --- a/include/uapi/scsi/Kbuild +++ b/include/uapi/scsi/Kbuild @@ -1,2 +1,5 @@ # UAPI Header export list header-y += fc/ +header-y += scsi_bsg_fc.h +header-y += scsi_netlink.h +header-y += scsi_netlink_fc.h diff --git a/include/scsi/scsi_bsg_fc.h b/include/uapi/scsi/scsi_bsg_fc.h similarity index 100% rename from include/scsi/scsi_bsg_fc.h rename to include/uapi/scsi/scsi_bsg_fc.h diff --git a/include/scsi/scsi_netlink.h b/include/uapi/scsi/scsi_netlink.h similarity index 100% rename from include/scsi/scsi_netlink.h rename to include/uapi/scsi/scsi_netlink.h diff --git a/include/scsi/scsi_netlink_fc.h b/include/uapi/scsi/scsi_netlink_fc.h similarity index 100% rename from include/scsi/scsi_netlink_fc.h rename to include/uapi/scsi/scsi_netlink_fc.h -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/GIT PULL] UAPI: (Scripted) Disintegrate include/scsi/fc
This completes part of the Userspace API (UAPI) disintegration for which the preparatory patches were pulled recently. After these patches, userspace headers will be segregated into: include/uapi/linux/.../foo.h for the userspace interface stuff, and: include/linux/.../foo.h for the strictly kernel internal stuff. This patch can be pulled from: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-fc-20121009 Signed-off-by: David Howells dhowe...@redhat.com Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Thomas Gleixner t...@linutronix.de Acked-by: Michael Kerrisk mtk.manpa...@gmail.com Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com Acked-by: Dave Jones da...@redhat.com --- diff --git a/include/scsi/fc/Kbuild b/include/scsi/fc/Kbuild index 5660381..e69de29 100644 --- a/include/scsi/fc/Kbuild +++ b/include/scsi/fc/Kbuild @@ -1,4 +0,0 @@ -header-y += fc_els.h -header-y += fc_fs.h -header-y += fc_gs.h -header-y += fc_ns.h diff --git a/include/uapi/scsi/fc/Kbuild b/include/uapi/scsi/fc/Kbuild index aafaa5a..5ead9fa 100644 --- a/include/uapi/scsi/fc/Kbuild +++ b/include/uapi/scsi/fc/Kbuild @@ -1 +1,5 @@ # UAPI Header export list +header-y += fc_els.h +header-y += fc_fs.h +header-y += fc_gs.h +header-y += fc_ns.h diff --git a/include/scsi/fc/fc_els.h b/include/uapi/scsi/fc/fc_els.h similarity index 100% rename from include/scsi/fc/fc_els.h rename to include/uapi/scsi/fc/fc_els.h diff --git a/include/scsi/fc/fc_fs.h b/include/uapi/scsi/fc/fc_fs.h similarity index 100% rename from include/scsi/fc/fc_fs.h rename to include/uapi/scsi/fc/fc_fs.h diff --git a/include/scsi/fc/fc_gs.h b/include/uapi/scsi/fc/fc_gs.h similarity index 100% rename from include/scsi/fc/fc_gs.h rename to include/uapi/scsi/fc/fc_gs.h diff --git a/include/scsi/fc/fc_ns.h b/include/uapi/scsi/fc/fc_ns.h similarity index 100% rename from include/scsi/fc/fc_ns.h rename to include/uapi/scsi/fc/fc_ns.h -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/6] scsi: sr: support runtime pm
On Tue, 2012-10-09 at 15:20 +0800, Aaron Lu wrote: On 10/08/2012 06:21 PM, James Bottomley wrote: On Mon, 2012-10-08 at 17:27 +0800, Aaron Lu wrote: On Sun, Sep 30, 2012 at 03:43:27PM -0400, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Regardless, according to Aaron the ZP power-off stuff is currently implemented only in ACPI, tied more closely to the ATA layer than the SCSI layer (though not part of either). It is not part of the SCSI spec in any form. The mechanism of SATA ODD zero power model is specified in Mount Fuji spec v8 section 15 describing what the ODD needs support, how to sense if the ODD is ready to be powered off and on power up what needs to be done, etc. And the actual power off and wakeup is implemented in ACPI and SATA. Now it's true that determining whether a device is in the right state for power to be removed involves sending a TEST UNIT READY command, which is of course a SCSI command. This seems to be incidental to the overall scheme, however. I need to add that, there are 2 schemes to sense if the ODD is ready to be powered off: 1 the one I used here, by checking if the door is closed and no media inside with test_unit_ready; 2 some ZP capable ODDs can report zero power ready(ZPReady) event to host when queried, eliminating the need of host checking the conditions. The way I read the standard is that ZP ODD is a hack to try and get to Thanks for your time. off and ZPready is the same hack but integrated into the standardised power management states (and hence available to normal power saving). The standard even implies ZP ODD is a less desirable hack by recommending the use of ZPready. There are ZPODDs not supporting ZPready and I want to support them so the sense scheme 1 is used. Right, but what I'm saying is that ZPODD looks like a hack until ZPready is fairly universally implemented. ZPready makes far more sense since it's integrated into the usual SCSI power management, so ZPODD should have a limited shelf life. The ZPready method, being an extension of the usual SCSI power management model, is pretty much what we support today (especially as the whole thing is timer driven from values in the mode page and happens pretty much invisibly to us). Since the object is to make this as painless as possible, why don't we just implement ZPODD the way the spec recommends? i.e. emulate the timers at an incredibly low level and intercept and emulate the non-disk commands listed in table 321. I bet, in Linux, since we moved basically to GET_EVENT_STATUS_NOTIFICATION, that's the only one that actually needs an emulation. The state model seems to work if you snoop the polled media event, so you wait for no media, then set your internal timer, stop it if we get a media change and power off the device after interval expiry. Thereafter you emulate media event with no change keeping the device powered off. If a disc gets inserted or the eject button is pressed, you see that via the SATA PHY events (so wake the drive) and if the Upper Layer sends an unexpected command, you also power on the drive. That way all of this should be nicely containable within SATA/ACPI. Thanks for the suggestion, it is really something that I've never thought of :-) But I was hoping to use the runtime pm framework to support ZPODD. Well, the runtime pm framework doesn't support the current SCSI power management states within the drive, that's why it makes sense to treat what is essentially a hack to them in the same manner. With your suggestion, I don't know how to do this. Maybe I can set the scsi device representing the ODD to runtime suspended once I decided to power it off and resume it when I power it up. But there is a problem, that I'm setting a scsi device's runtime status in ATA layer, this doesn't feel right. And someday, someone may want to add runtime pm support for sr and the runtime status of the scsi device will be messed. No, if we ever actually supported the standard power management states, you'd simply be intercepting the SCSI commands that forced the state transitions (START_STOP_UNIT) and act when yours was forced. The reason I want to use runtime PM is, when the scsi device is runtime suspended, its ancestor devices will have a chance to enter runtime suspend state, e.g. the sata controller. But this, I think, is why it looks odd. You're implementing a lower state than standard SCSI power
Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha-hardware_lock
Hi Jiri, Andrew, Arun Co,
On Mon, 2012-10-08 at 09:23 +0200, Jiri Kosina wrote:
Lockdep reports:
=== [ cut here ] ===
=
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
-
qla2xxx_1_dpc/368 just changed the state of lock:
((ha-vport_slock)-rlock){+.}, at: [a009b377]
qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
((ha-hardware_lock)-rlock){-.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock((ha-vport_slock)-rlock);
local_irq_disable();
lock((ha-hardware_lock)-rlock);
lock((ha-vport_slock)-rlock);
Interrupt
lock((ha-hardware_lock)-rlock);
=== [ cut here ] ===
Fix the potential deadlock by disabling IRQs while holding ha-vport_slock.
Reported-and-tested-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
I'm fine with this patch and have applied to target-pending/queue for
the moment.
It will be moved into /master + included in the next PULL request once
Linus merges the outstanding /for-next series into -rc0 code.
Also please have a look below for a few more related items I noticed
while reviewing this patch..
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 799a58b..48fca47 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
uint8_t domain;
charconnect_type[22];
struct qla_hw_data *ha = vha-hw;
+ unsigned long flags;
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
vha-d_id.b.area = area;
vha-d_id.b.al_pa = al_pa;
- spin_lock(ha-vport_slock);
+ spin_lock_irqsave(ha-vport_slock, flags);
qlt_update_vp_map(vha, SET_AL_PA);
- spin_unlock(ha-vport_slock);
+ spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
So while looking at other -vport_slock + qlt_update_vp_map() usage, two
more items caught my eye:
In qla_mid.c:qla24xx_disable_vp() code:
ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
atomic_set(vha-loop_state, LOOP_DOWN);
atomic_set(vha-loop_down_timer, LOOP_DOWN_TIME);
/* Remove port id from vp target map */
qlt_update_vp_map(vha, RESET_AL_PA);
qla2x00_mark_vp_devices_dead(vha);
atomic_set(vha-vp_state, VP_FAILED);
AFAICT all callers of qlt_update_vp_map() into qla_target.c code should
be holding -vport_slock. I'll send out a separate patch for this
shortly.
And in qla_init.c:qla2x00_init_rings() code:
for (que = 0; que ha-max_rsp_queues; que++) {
rsp = ha-rsp_q_map[que];
if (!rsp)
continue;
/* Initialize response queue entries */
qla2x00_init_response_q_entries(rsp);
}
spin_lock(ha-vport_slock);
spin_unlock(ha-vport_slock);
ha-tgt.atio_ring_ptr = ha-tgt.atio_ring;
ha-tgt.atio_ring_index = 0;
/* Initialize ATIO queue entries */
qlt_init_atio_q_entries(vha);
The usage of -vport_slock seems to be now either unnecessary, or a
result of some bad merge outside of qla2xxx target mode.
Qlogic folks, can this (leftover..?) usage of -vport_slock now be
safety removed..?
--nab
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qla2xxx: Add missing -vport_slock while calling qlt_update_vp_map
From: Nicholas Bellinger n...@linux-iscsi.org
All other callers of qlt_update_vp_map() already hold -vport_slock
while updating the vp target map, so go ahead and add the missing
-vport_slock within qla24xx_disable_vp() code.
Cc: Saurav Kashyap saurav.kash...@qlogic.com
Cc: Chad Dupuis chad.dup...@qlogic.com
Cc: Arun Easi arun.e...@qlogic.com
Cc: Andrew Vasquez andrew.vasq...@qlogic.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/scsi/qla2xxx/qla_mid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_mid.c b/drivers/scsi/qla2xxx/qla_mid.c
index 3e8b324..c7eb3bb 100644
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -149,6 +149,7 @@ qla2x00_mark_vp_devices_dead(scsi_qla_host_t *vha)
int
qla24xx_disable_vp(scsi_qla_host_t *vha)
{
+ unsigned long flags;
int ret;
ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
@@ -156,7 +157,9 @@ qla24xx_disable_vp(scsi_qla_host_t *vha)
atomic_set(vha-loop_down_timer, LOOP_DOWN_TIME);
/* Remove port id from vp target map */
+ spin_lock_irqsave(vha-hw-vport_slock, flags);
qlt_update_vp_map(vha, RESET_AL_PA);
+ spin_unlock_irqrestore(vha-hw-vport_slock, flags);
qla2x00_mark_vp_devices_dead(vha);
atomic_set(vha-vp_state, VP_FAILED);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha-hardware_lock
Hi Nick,
On Tue, 9 Oct 2012, 11:47am -0700, Nicholas A. Bellinger wrote:
Hi Jiri, Andrew, Arun Co,
--8-- snipped --
Also please have a look below for a few more related items I noticed
while reviewing this patch..
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 799a58b..48fca47 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
uint8_t domain;
charconnect_type[22];
struct qla_hw_data *ha = vha-hw;
+unsigned long flags;
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
vha-d_id.b.area = area;
vha-d_id.b.al_pa = al_pa;
-spin_lock(ha-vport_slock);
+spin_lock_irqsave(ha-vport_slock, flags);
qlt_update_vp_map(vha, SET_AL_PA);
-spin_unlock(ha-vport_slock);
+spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
So while looking at other -vport_slock + qlt_update_vp_map() usage, two
more items caught my eye:
In qla_mid.c:qla24xx_disable_vp() code:
ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
atomic_set(vha-loop_state, LOOP_DOWN);
atomic_set(vha-loop_down_timer, LOOP_DOWN_TIME);
/* Remove port id from vp target map */
qlt_update_vp_map(vha, RESET_AL_PA);
qla2x00_mark_vp_devices_dead(vha);
atomic_set(vha-vp_state, VP_FAILED);
AFAICT all callers of qlt_update_vp_map() into qla_target.c code should
be holding -vport_slock. I'll send out a separate patch for this
shortly.
Makes sense.
And in qla_init.c:qla2x00_init_rings() code:
for (que = 0; que ha-max_rsp_queues; que++) {
rsp = ha-rsp_q_map[que];
if (!rsp)
continue;
/* Initialize response queue entries */
qla2x00_init_response_q_entries(rsp);
}
spin_lock(ha-vport_slock);
spin_unlock(ha-vport_slock);
ha-tgt.atio_ring_ptr = ha-tgt.atio_ring;
ha-tgt.atio_ring_index = 0;
/* Initialize ATIO queue entries */
qlt_init_atio_q_entries(vha);
The usage of -vport_slock seems to be now either unnecessary, or a
result of some bad merge outside of qla2xxx target mode.
Qlogic folks, can this (leftover..?) usage of -vport_slock now be
safety removed..?
Yes, this is a left over of code removal and can be safely removed. We
already have a patch queued internally for this.
--Arun
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: standards revisions
On Mon, 2012-10-08 at 08:45 +0100, James Bottomley wrote: On Sun, 2012-10-07 at 11:11 -0700, Nicholas A. Bellinger wrote: On Sun, 2012-10-07 at 09:16 +0100, James Bottomley wrote: On Sat, 2012-10-06 at 23:11 -0700, Nicholas A. Bellinger wrote: On Sat, 2012-10-06 at 21:49 -0400, Christoph Hellwig wrote: Currenly all non-pscsi bakcneds report their standards version as SPC 2 via -get_device_rev. No, the proper on-the-wire bits to signal SPC-3 compliance are already being returned by virtual backend drivers within standard INQUIRY payload data. Notice the comment: root@tifa:/usr/src/target-pending.git# grep SCSI_SPC_2 drivers/target/*.c drivers/target/target_core_file.c: return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ drivers/target/target_core_iblock.c:return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ drivers/target/target_core_rd.c:return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ That's causing confusion, I think! In addition to putting it into the inquirty data in spc_emulate_inquiry_std we also use it in two places to check on the version of the persistent reservation and alua support. What is the benefit of supporting the old-style SCSI 2 reservations and ALUA support when they can't be used at all with the virtual backends, and can only be used in the corner case emulated ALUA/PR support for pscsi? It's the include/scsi/scsi.h SCSI_3 + SCSI_SPC_* version definition names that are incorrect: #define SCSI_UNKNOWN0 #define SCSI_1 1 #define SCSI_1_CCS 2 #define SCSI_2 3 #define SCSI_3 4/* SPC */ #define SCSI_SPC_2 5 #define SCSI_SPC_3 6 from spc4r30 section 6.4.2 Standard INQUIRY data, Table 142 -- Version: 00h The device server does not claim conformance to any standard. 01h to 02h Obsolete 03h The device server complies to ANSI INCITS 301-1997 (a withdrawn standard). 04h The device server complies to ANSI INCITS 351-2001 (SPC-2). 05h The device server complies to ANSI INCITS 408-2005 (SPC-3). 06h The device server complies to this standard. How about the following patch to fix the long-standing incorrect name usage of these three scsi.h defines..? Because it's not incorrect. Your confusion is that the SCSI_ constants should match the inquiry data ... they shouldn't. No, my current confusion is stemming from why it's OK for SCSI_SPC_[2,3] constant names+values to not match what is actually defined in SPC-4 drafts for what target INQUIRY emulation bits end up going 'over the wire'. OK, I don't understand what you didn't get about the explanation below. But the gist is it's not a constant representing inquiry[2]7; it's an ordered set of enumerations representing gross capabilities abstracted into sdev-scsi_level. Yes, there is no confusion on how scsi-core is working here.. SCSI_3 does exist, by the way, it was defined in the first version of SPC and there are some devices which conform to it. Regardless, SCSI_SPC_[2,3] - SCSI_SPC[3,4] constants for target-core + scsi-core should still be re-named to avoid the extra confusion this introduces for folks reading code. I'm not convinced there is confusion; this use of enumerated levelling goes back to 2.2 and no-one else has had a problem with it. You're the only one whose had an issue and it does seem to be because you didn't bother reading the comment above their definitions in the header file which does explain what's going on. The point is that it would be nice to have constants representing on-the-wire values in scsi.h that both scsi-core and target-core can use. What about just defining the proper 'on-the-wire' that target-core needs instead..? diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index 66216c1..13ee02b 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -541,6 +541,13 @@ static inline int scsi_is_wlun(unsigned int lun) #define SCSI_SPC_3 6 /* + * ANSI INCITS Standard INQUIRY resp[2] version bits + */ +#define SCSI_ANSIVER_SPC2 0x04/* ANSI INCITS 351-2001 (SPC-2) */ +#define SCSI_ANSIVER_SPC3 0x05/* ANSI INCITS 408-2005 (SPC-3) */ +#define SCSI_ANSIVER_SPC4 0x06/* SPC-4 standard draft */ + +/* * INQ PERIPHERAL QUALIFIERS */ #define SCSI_INQ_PQ_CON 0x00 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] SCSI: ARM: make fas216_dumpinfo function conditional
The fas216_dumpinfo function is only used by __fas216_checkmagic,
which is conditionally compiled, so we should put both functions
inside of the same #ifdef.
Without this patch, building rpc_defconfig results in:
drivers/scsi/arm/fas216.c:182:13: warning: 'fas216_dumpinfo' defined but not
used [-Wunused-function]
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Russell King li...@arm.linux.org.uk
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-scsi@vger.kernel.org
---
drivers/scsi/arm/fas216.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index 6206a66..737554c 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -179,6 +179,7 @@ static void print_SCp(struct scsi_pointer *SCp, const char
*prefix, const char *
SCp-buffers_residual, suffix);
}
+#ifdef CHECK_STRUCTURE
static void fas216_dumpinfo(FAS216_Info *info)
{
static int used = 0;
@@ -223,7 +224,6 @@ static void fas216_dumpinfo(FAS216_Info *info)
info-internal_done, info-magic_end);
}
-#ifdef CHECK_STRUCTURE
static void __fas216_checkmagic(FAS216_Info *info, const char *func)
{
int corruption = 0;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] ARM: mostly harmless gcc warnings
Most patches from the first time this was posted have been adopted by a subsystem maintainer or were show to be obsolete. Here are the remaining ones again. I'm planning to submit those patches that are still necessary by the time we have an -rc1 through the arm-soc tree, but my preference is still to have them go through the subsystem maintainers. Olof: should we add it to for-next? Arnd Arnd Bergmann (8): SCSI: ARM: ncr5380/oak uses no interrupts SCSI: ARM: make fas216_dumpinfo function conditional mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit clk: don't mark clkdev_add_table as init pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops video: mark nuc900fb_map_video_memory as __devinit spi/s3c64xx: use correct dma_transfer_direction type drivers/clk/clkdev.c|2 +- drivers/pcmcia/pxa2xx_sharpsl.c |2 +- drivers/scsi/arm/fas216.c |2 +- drivers/scsi/arm/oak.c |1 + drivers/spi/spi-s3c64xx.c |2 +- drivers/usb/host/ehci-orion.c |2 +- drivers/video/nuc900fb.c|2 +- mm/slob.c |6 +++--- 8 files changed, 10 insertions(+), 9 deletions(-) -- 1.7.10 Cc: James E.J. Bottomley jbottom...@parallels.com Cc: Ben Dooks ben-li...@fluff.org Cc: Dominik Brodowski li...@dominikbrodowski.net Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Jochen Friedrich joc...@scram.de Cc: Kukjin Kim kgene@samsung.com Cc: Mike Turquette mturque...@linaro.org Cc: Pavel Machek pa...@suse.cz Cc: Pekka Enberg penb...@kernel.org Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Wan ZongShun mcuos@gmail.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-fb...@vger.kernel.org Cc: linux-pcm...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: spi-devel-gene...@lists.sourceforge.net Cc: sta...@vger.kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] SCSI: ARM: ncr5380/oak uses no interrupts
The ncr5380 driver is included by multiple board specific drivers, which may or may not use the interrupt handler. The oak variant doesn't, and should set the DONT_USE_INTR macro. Without this patch, building rpc_defconfig results in: drivers/scsi/arm/../NCR5380.c:1160:20: warning: 'oakscsi_intr' defined but not used [-Wunused-function] Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: James E.J. Bottomley jbottom...@parallels.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-scsi@vger.kernel.org --- drivers/scsi/arm/oak.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/arm/oak.c b/drivers/scsi/arm/oak.c index d25f944..fc6a5aa 100644 --- a/drivers/scsi/arm/oak.c +++ b/drivers/scsi/arm/oak.c @@ -21,6 +21,7 @@ /*#define PSEUDO_DMA*/ #define OAKSCSI_PUBLIC_RELEASE 1 +#define DONT_USE_INTR #define priv(host) ((struct NCR5380_hostdata *)(host)-hostdata) #define NCR5380_local_declare()void __iomem *_base -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 0/5] Add new fcoe_sysfs based control interfaces to libfcoe, bnx2fc and fcoe
v4: @Neil: Policy is now: 'mode' attribute: input: Fabric VN2VN (case insensitive) output: Fabric VN2VN 'enabled' attribute: input: 1 0 output: 1 0 @Mark: Initial patch now optimizes enum-to-string memory usage and string retreival -- v3: This series applies to the v3.6 kernel. @Bart: Fixed bus_create_file - bus_attrs Removed sscanf with non-NULL buffer, only checking for '1' or '0' now Removed unnecessary whitespace change @Bhanu: Incorporated check in _bnx2fc_create (thanks for the code) Additional changes: Added check for 'enabled' in reset in fcoe.c Made mode strncmp case insensitive so user can # echo vn2vn /sys/.../ctlr_0/mode # or # echo VN2VN /sys/.../ctlr_0/mode # or even # echo FaBRiC /sys/.../ctlr_0/mode -- v2: The following series adds /sys/bus/fcoe based control interfaces to libfcoe. A fcoe_sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. The patches deprecate the old create, vn2vn_create, destroy, enable and disable interfaces that exist in /sys/module/libfcoe/parameters/. Another goal of this series is to change the initialization sequence for a FCoE device. The result of this series is that interfaces created using libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following starting steps- 1) Create/alloc the FCoE Controller - Allocate kernel memory and create per-instance sysfs devices - The FCoE Controller is created disabled, no discovery or login until it is enabled. # echo eth3.172-fcoe /sys/bus/fcoe/ctlr_create 2) Configure the FCoE Controller - Change mode, set ddp_min (future), set dcb_required (future), etc... # echo 2 /sys/bus/fcoe/ctlr_0/mode #sets mode to VN2VN 3) Enable the FCoE Controller - Begins discovery and login in 'Fabric' mode. or - Begins FIP FCID claim process, discovery and login in 'VN2VN' mode 4) Destroy the FCoE Controller - Logout and free all memory # echo eth3.172-fcoe /sys/bus/fcoe/ctlr_destroy This series converts both fcoe.ko and bnx2fc.ko to use the new fcoe_sysfs based interfaces. The legacy interfaces can remain in kernel for a kernel cycle or two before being removed. I'm looking for feedback on the use of /sys/bus/fcoe/ctlr_create and /sys/bus/fcoe/ctlr_destroy and that those interfaces take an ifname. I modeled it after the bonding interface, but I'm not sure if that's acceptible. Incorpoated v1 feedback: @Chris: I spent a lot of time looking into FCF selection. I implemented a POC series where I made the 'enabled' attribute of a fcoe_fcf_device (i.e. /sys/bus/fcoe/devices/fcf_X) writable. The fcoe_ctlr_device (i.e. /sys/bus/fcoe/devices/ctlr_X) has a 'selection_strategy' attribute that would allow the user to toggle between AUTO (current kernel selection algorithm) and USER (user writes to FCF's 'selection' attribute). I also wrote a little libudev based application that listened for fcoe_fcf_device sysfs add/remove events. My plan was to have fcoemon monitor the discovery of FCFs and then have it write to the 'selected' attribute of the FCF the user had chosen. Working on this series convinced me that any FCF selection needs further consideration. First of all, it's fairly complicated to update the fcoe_ctlr.c functional FIP code to handle FCF/fabric selection. Some questions that arise: What triggers FLOGI/LOGO? We would now have link, enabled/disabled, selection strategy and FCF selection to consider. Can a new FCF be selected when one is already selected and an FLOGI has occurred? Can a FCF be de-selected when the FLOGI has been sent? Maybe we can only change things when disabled, that probably makes the most sense.. When does discovery happen? When the ctlr is created (no opportunity for mode/selection strategy to be set)? When the mode is changed (same problem)? What about when the cltr is enabled (but that's when we were going to FLOGI)? This isn't a complete list of considerations, just what came to mind when writing this. Anyway, the policies started to get complicated, or maybe my lack of policies made the POC implementation more complicated. Either way it made me think about use cases and how valuable FCF/fabric selection is. After further consideration I think that most of the access decisions, when connecting to a FC fabric, should be done by the fabric services. I'm not sure the endstations should be whitelisting or blacklisting FCFs or even making decisions about which ones to use when they're already prioritized amongst themselves (on the same fabric). I think it might be nice for debugging, but I don't have a need at the moment. I think user selection may be more valuable with VN2VN, which may interest you more anyway, as you said that you were running a VN2VN setup. Since there aren't fabric services to
[RFC PATCH v4 1/5] libfcoe: Save some memory and optimize name lookups
Instead of creating a structure with an enum and a pointer
to a string, simply allocate an array of strings and use
the enum values for the indicies.
This means that we do not need to iterate through the list
of entries when looking up a string name by its enum key.
This will also help with a latter patch that will add
more fcoe_sysfs attributes that will also use the
fcoe_enum_name_search macro. One attribute will also do
a reverse lookup which requires less code when the
enum-to-string mappings are organized as this patch makes
them to be.
Signed-off-by: Robert Love robert.w.l...@intel.com
---
drivers/scsi/fcoe/fcoe_sysfs.c | 44 +++-
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 5e75168..5a74a47 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -210,25 +210,23 @@ static ssize_t show_fcoe_fcf_device_##field(struct device
*dev, \
#define fcoe_enum_name_search(title, table_type, table)
\
static const char *get_fcoe_##title##_name(enum table_type table_key) \
{ \
- int i; \
- char *name = NULL; \
- \
- for (i = 0; i ARRAY_SIZE(table); i++) { \
- if (table[i].value == table_key) { \
- name = table[i].name; \
- break; \
- } \
- } \
- return name;\
+ if (table_key = ARRAY_SIZE(table)) \
+ return NULL;\
+ return table[table_key];\
}
-static struct {
- enum fcf_state value;
- char *name;
-} fcf_state_names[] = {
- { FCOE_FCF_STATE_UNKNOWN, Unknown },
- { FCOE_FCF_STATE_DISCONNECTED, Disconnected },
- { FCOE_FCF_STATE_CONNECTED,Connected },
+static char *fip_conn_type_names[] = {
+ [ FIP_CONN_TYPE_UNKNOWN ] = Unknown,
+[ FIP_CONN_TYPE_FABRIC ] = Fabric,
+ [ FIP_CONN_TYPE_VN2VN ] = VN2VN,
+};
+fcoe_enum_name_search(ctlr_mode, fip_conn_type, fip_conn_type_names)
+#define FCOE_CTLR_MODE_MAX_NAMELEN 50
+
+static char *fcf_state_names[] = {
+ [ FCOE_FCF_STATE_UNKNOWN ] = Unknown,
+ [ FCOE_FCF_STATE_DISCONNECTED ] = Disconnected,
+ [ FCOE_FCF_STATE_CONNECTED ]= Connected,
};
fcoe_enum_name_search(fcf_state, fcf_state, fcf_state_names)
#define FCOE_FCF_STATE_MAX_NAMELEN 50
@@ -246,17 +244,7 @@ static ssize_t show_fcf_state(struct device *dev,
}
static FCOE_DEVICE_ATTR(fcf, state, S_IRUGO, show_fcf_state, NULL);
-static struct {
- enum fip_conn_type value;
- char *name;
-} fip_conn_type_names[] = {
- { FIP_CONN_TYPE_UNKNOWN, Unknown },
- { FIP_CONN_TYPE_FABRIC, Fabric },
- { FIP_CONN_TYPE_VN2VN, VN2VN },
-};
-fcoe_enum_name_search(ctlr_mode, fip_conn_type, fip_conn_type_names)
-#define FCOE_CTLR_MODE_MAX_NAMELEN 50
-
+#define FCOE_MAX_MODENAME_LEN 20
static ssize_t show_ctlr_mode(struct device *dev,
struct device_attribute *attr,
char *buf)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 2/5] libfcoe: Add fcoe_sysfs debug logging level
Add a macro to print fcoe_sysfs debug statements.
Signed-off-by: Robert Love robert.w.l...@intel.com
---
drivers/scsi/fcoe/fcoe_sysfs.c |7 +++
drivers/scsi/fcoe/libfcoe.h| 11 ---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 5a74a47..638e8a2 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -24,6 +24,13 @@
#include scsi/fcoe_sysfs.h
+/*
+ * OK to include local libfcoe.h for debug_logging, but cannot include
+ * scsi/libfcoe.h otherwise non-netdev based fcoe solutions would have
+ * have to include more than fcoe_sysfs.h.
+ */
+#include libfcoe.h
+
static atomic_t ctlr_num;
static atomic_t fcf_num;
diff --git a/drivers/scsi/fcoe/libfcoe.h b/drivers/scsi/fcoe/libfcoe.h
index 6af5fc3..63d8fae 100644
--- a/drivers/scsi/fcoe/libfcoe.h
+++ b/drivers/scsi/fcoe/libfcoe.h
@@ -2,9 +2,10 @@
#define _FCOE_LIBFCOE_H_
extern unsigned int libfcoe_debug_logging;
-#define LIBFCOE_LOGGING0x01 /* General logging, not categorized */
-#define LIBFCOE_FIP_LOGGING 0x02 /* FIP logging */
-#define LIBFCOE_TRANSPORT_LOGGING 0x04 /* FCoE transport logging */
+#define LIBFCOE_LOGGING 0x01 /* General logging, not
categorized */
+#define LIBFCOE_FIP_LOGGING 0x02 /* FIP logging */
+#define LIBFCOE_TRANSPORT_LOGGING 0x04 /* FCoE transport logging */
+#define LIBFCOE_SYSFS_LOGGING 0x08 /* fcoe_sysfs logging */
#define LIBFCOE_CHECK_LOGGING(LEVEL, CMD) \
do { \
@@ -28,4 +29,8 @@ do { \
printk(KERN_INFO %s: fmt, \
__func__, ##args);)
+#define LIBFCOE_SYSFS_DBG(cdev, fmt, args...) \
+ LIBFCOE_CHECK_LOGGING(LIBFCOE_SYSFS_LOGGING,\
+ pr_info(ctlr_%d: fmt, cdev-id, ##args);)
+
#endif /* _FCOE_LIBFCOE_H_ */
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4 3/5] libfcoe, fcoe, bnx2fc: Add new fcoe control interface
This patch does a few things.
1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
These interfaces take an ifname and will either
create an FCoE Controller or destroy an FCoE
Controller depending on which file is written to.
The new FCoE Controller will start in a DISABLED
state and will not do discovery or login until it
is ENABLED. This pause will allow us to configure
the FCoE Controller before enabling it.
2) Makes the 'mode' attribute of a fcoe_ctlr_device
writale. This allows the user to configure the mode
in which the FCoE Controller will start in when it
is ENABLED.
Possible modes are 'Fabric', or 'VN2VN'.
The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
Drivers must implement the set_fcoe_ctlr_mode routine
to support this feature.
libfcoe offers an exported routine to set a FCoE
Controller's mode. The mode can only be changed
when the FCoE Controller is DISABLED.
This patch also removes the get_fcoe_ctlr_mode pointer
in the fcoe_sysfs function template, the code in
fcoe_ctlr.c to get the mode and the assignment of
the fcoe_sysfs function pointer to the fcoe_ctlr.c
implementation (in fcoe and bnx2fc). fcoe_sysfs can
return that value for the mode without consulting the
LLD.
3) Make a 'enabled' attribute of a fcoe_ctlr_device. On a
read, fcoe_sysfs will return the attribute's value. On
a write, fcoe_sysfs will call the LLD (if there is a
callback) to notifiy that the enalbed state has changed.
This patch maintains the old FCoE control interfaces as
module parameters, but it adds comments pointing out that
the old interfaces are deprecated.
Signed-off-by: Robert Love robert.w.l...@intel.com
---
Documentation/ABI/testing/sysfs-bus-fcoe | 42 +
drivers/scsi/bnx2fc/bnx2fc_fcoe.c|1
drivers/scsi/fcoe/fcoe.c |1
drivers/scsi/fcoe/fcoe_sysfs.c | 137 --
drivers/scsi/fcoe/fcoe_transport.c | 104 +++
include/scsi/fcoe_sysfs.h| 11 ++
include/scsi/libfcoe.h | 16 +++-
7 files changed, 299 insertions(+), 13 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe
b/Documentation/ABI/testing/sysfs-bus-fcoe
index 469d09c..a57bf37 100644
--- a/Documentation/ABI/testing/sysfs-bus-fcoe
+++ b/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -1,14 +1,54 @@
+What: /sys/bus/fcoe/
+Date: August 2012
+KernelVersion: TBD
+Contact: Robert Love robert.w.l...@intel.com, de...@open-fcoe.org
+Description: The FCoE bus. Attributes in this directory are control
interfaces.
+Attributes:
+
+ ctlr_create: 'FCoE Controller' instance creation interface. Writing an
+ifname to this file will allocate and populate sysfs
with a
+fcoe_ctlr_device (ctlr_X). The user can then configure any
+per-port settings and finally write to the
fcoe_ctlr_device's
+'start' attribute to begin the kernel's discovery and login
+process.
+
+ ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
+ fcoe_ctlr_device's sysfs name to this file will log the
+ fcoe_ctlr_device out of the fabric or otherwise connected
+ FCoE devices. It will also free all kernel memory
allocated
+ for this fcoe_ctlr_device and any structures associated
+ with it, this includes the scsi_host.
+
What: /sys/bus/fcoe/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love robert.w.l...@intel.com, de...@open-fcoe.org
-Description: 'FCoE Controller' instances on the fcoe bus
+Description: 'FCoE Controller' instances on the fcoe bus.
+
+ The FCoE Controller now has a three stage creation process.
+ 1) Write interface name to ctlr_create 2) Configure the FCoE
+ Controller (ctlr_X) 3) Enable the FCoE Controller to begin
+ discovery and login. The FCoE Controller is destroyed by
+ writing it's name, i.e. ctlr_X to the ctlr_delete file.
+
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
+ mode: Display or change the FCoE Controller's mode. Possible
+ modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
+ is started in 'Fabric' mode then FIP FCF discovery is
+ initiated and ultimately a fabric login is attempted.
+ If a FCoE Controller is started in 'VN2VN' mode then
+ FIP VN2VN discovery and login is performed. A FCoE
+ Controller only
[RFC PATCH v4 5/5] bnx2fc: Use the fcoe_sysfs control interface
This patch adds support for the new fcoe_sysfs
control interface to bnx2fc.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.
The fcoe_ctlr's link state is now driven by both the
netdev link state as well as the fcoe_ctlr_device's
enabled attribute. The link must be up and the
fcoe_ctlr_device must be enabled before the FCoE
Controller starts discovery or login.
Signed-off-by: Robert Love robert.w.l...@intel.com
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 168 +++--
1 file changed, 139 insertions(+), 29 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 97d9a58..9e15998 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -62,6 +62,10 @@ static int bnx2fc_destroy(struct net_device *net_device);
static int bnx2fc_enable(struct net_device *netdev);
static int bnx2fc_disable(struct net_device *netdev);
+/* fcoe_syfs control interface handlers */
+static int bnx2fc_ctlr_alloc(struct net_device *netdev);
+static int bnx2fc_ctlr_enabled(struct fcoe_ctlr_device *cdev);
+
static void bnx2fc_recv_frame(struct sk_buff *skb);
static void bnx2fc_start_disc(struct bnx2fc_interface *interface);
@@ -864,6 +868,7 @@ static void bnx2fc_indicate_netevent(void *context,
unsigned long event,
u16 vlan_id)
{
struct bnx2fc_hba *hba = (struct bnx2fc_hba *)context;
+ struct fcoe_ctlr_device *cdev;
struct fc_lport *lport;
struct fc_lport *vport;
struct bnx2fc_interface *interface, *tmp;
@@ -925,28 +930,45 @@ static void bnx2fc_indicate_netevent(void *context,
unsigned long event,
bnx2fc_link_speed_update(lport);
+ cdev = fcoe_ctlr_to_ctlr_dev(ctlr);
+
if (link_possible !bnx2fc_link_ok(lport)) {
- /* Reset max recv frame size to default */
- fc_set_mfs(lport, BNX2FC_MFS);
- /*
-* ctlr link up will only be handled during
-* enable to avoid sending discovery solicitation
-* on a stale vlan
-*/
- if (interface-enabled)
- fcoe_ctlr_link_up(ctlr);
+ switch (cdev-enabled) {
+ case FCOE_CTLR_DISABLED:
+ pr_info(Link up while interface is
disabled.\n);
+ break;
+ case FCOE_CTLR_ENABLED:
+ case FCOE_CTLR_UNUSED:
+ /* Reset max recv frame size to default */
+ fc_set_mfs(lport, BNX2FC_MFS);
+ /*
+* ctlr link up will only be handled during
+* enable to avoid sending discovery
+* solicitation on a stale vlan
+*/
+ if (interface-enabled)
+ fcoe_ctlr_link_up(ctlr);
+ };
} else if (fcoe_ctlr_link_down(ctlr)) {
- mutex_lock(lport-lp_mutex);
- list_for_each_entry(vport, lport-vports, list)
- fc_host_port_type(vport-host) =
- FC_PORTTYPE_UNKNOWN;
- mutex_unlock(lport-lp_mutex);
- fc_host_port_type(lport-host) = FC_PORTTYPE_UNKNOWN;
- per_cpu_ptr(lport-stats,
- get_cpu())-LinkFailureCount++;
- put_cpu();
- fcoe_clean_pending_queue(lport);
- wait_for_upload = 1;
+ switch (cdev-enabled) {
+ case FCOE_CTLR_DISABLED:
+ pr_info(Link down while interface is
disabled.\n);
+ break;
+ case FCOE_CTLR_ENABLED:
+ case FCOE_CTLR_UNUSED:
+ mutex_lock(lport-lp_mutex);
+ list_for_each_entry(vport, lport-vports, list)
+ fc_host_port_type(vport-host) =
+ FC_PORTTYPE_UNKNOWN;
+ mutex_unlock(lport-lp_mutex);
+ fc_host_port_type(lport-host) =
+ FC_PORTTYPE_UNKNOWN;
+ per_cpu_ptr(lport-stats,
+ get_cpu())-LinkFailureCount++;
+
Re: [PATCH v7 2/6] scsi: sr: support runtime pm
On Tuesday 09 of October 2012 15:20:39 Aaron Lu wrote: On 10/08/2012 06:21 PM, James Bottomley wrote: On Mon, 2012-10-08 at 17:27 +0800, Aaron Lu wrote: On Sun, Sep 30, 2012 at 03:43:27PM -0400, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Regardless, according to Aaron the ZP power-off stuff is currently implemented only in ACPI, tied more closely to the ATA layer than the SCSI layer (though not part of either). It is not part of the SCSI spec in any form. The mechanism of SATA ODD zero power model is specified in Mount Fuji spec v8 section 15 describing what the ODD needs support, how to sense if the ODD is ready to be powered off and on power up what needs to be done, etc. And the actual power off and wakeup is implemented in ACPI and SATA. Now it's true that determining whether a device is in the right state for power to be removed involves sending a TEST UNIT READY command, which is of course a SCSI command. This seems to be incidental to the overall scheme, however. I need to add that, there are 2 schemes to sense if the ODD is ready to be powered off: 1 the one I used here, by checking if the door is closed and no media inside with test_unit_ready; 2 some ZP capable ODDs can report zero power ready(ZPReady) event to host when queried, eliminating the need of host checking the conditions. The way I read the standard is that ZP ODD is a hack to try and get to Thanks for your time. off and ZPready is the same hack but integrated into the standardised power management states (and hence available to normal power saving). The standard even implies ZP ODD is a less desirable hack by recommending the use of ZPready. There are ZPODDs not supporting ZPready and I want to support them so the sense scheme 1 is used. The ZPready method, being an extension of the usual SCSI power management model, is pretty much what we support today (especially as the whole thing is timer driven from values in the mode page and happens pretty much invisibly to us). Since the object is to make this as painless as possible, why don't we just implement ZPODD the way the spec recommends? i.e. emulate the timers at an incredibly low level and intercept and emulate the non-disk commands listed in table 321. I bet, in Linux, since we moved basically to GET_EVENT_STATUS_NOTIFICATION, that's the only one that actually needs an emulation. The state model seems to work if you snoop the polled media event, so you wait for no media, then set your internal timer, stop it if we get a media change and power off the device after interval expiry. Thereafter you emulate media event with no change keeping the device powered off. If a disc gets inserted or the eject button is pressed, you see that via the SATA PHY events (so wake the drive) and if the Upper Layer sends an unexpected command, you also power on the drive. That way all of this should be nicely containable within SATA/ACPI. Thanks for the suggestion, it is really something that I've never thought of :-) Well, that's what I wanted to say previously, but James expressed it much better than I could. ;-) But I was hoping to use the runtime pm framework to support ZPODD. With your suggestion, I don't know how to do this. Maybe I can set the scsi device representing the ODD to runtime suspended once I decided to power it off and resume it when I power it up. But there is a problem, that I'm setting a scsi device's runtime status in ATA layer, this doesn't feel right. And someday, someone may want to add runtime pm support for sr and the runtime status of the scsi device will be messed. The reason I want to use runtime PM is, when the scsi device is runtime suspended, its ancestor devices will have a chance to enter runtime suspend state, e.g. the sata controller. You can add runtime PM support for sr that won't do anything hardware-specific and in addition to that you can do pm_runtime_get_sync() on the parent directly from the ATA layer when you know it is needed and pm_runtime_put() when you know it is safe for it to go to a low-power state. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[SCSI] hpsa: dial down lockup detection during firmware flash
Should this fix for hpsa be included in stable updates? It looks like it would be needed in 3.2.y and 3.4.y, as lockup detection was introduced in 3.2 and the fix went into 3.5. commit e85c59746957fd6e3595d02cf614370056b5816e Author: Stephen M. Cameron scame...@beardog.cce.hp.com Date: Tue May 1 11:43:42 2012 -0500 [SCSI] hpsa: dial down lockup detection during firmware flash Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp signature.asc Description: This is a digitally signed message part
Re: [PATCH] qla2xxx: Add missing -vport_slock while calling qlt_update_vp_map
Acked-by: Saurav Kashyap saurav.kash...@qlogic.com
From: Nicholas Bellinger n...@linux-iscsi.org
All other callers of qlt_update_vp_map() already hold -vport_slock
while updating the vp target map, so go ahead and add the missing
-vport_slock within qla24xx_disable_vp() code.
Cc: Saurav Kashyap saurav.kash...@qlogic.com
Cc: Chad Dupuis chad.dup...@qlogic.com
Cc: Arun Easi arun.e...@qlogic.com
Cc: Andrew Vasquez andrew.vasq...@qlogic.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/scsi/qla2xxx/qla_mid.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_mid.c
b/drivers/scsi/qla2xxx/qla_mid.c
index 3e8b324..c7eb3bb 100644
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -149,6 +149,7 @@ qla2x00_mark_vp_devices_dead(scsi_qla_host_t *vha)
int
qla24xx_disable_vp(scsi_qla_host_t *vha)
{
+ unsigned long flags;
int ret;
ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
@@ -156,7 +157,9 @@ qla24xx_disable_vp(scsi_qla_host_t *vha)
atomic_set(vha-loop_down_timer, LOOP_DOWN_TIME);
/* Remove port id from vp target map */
+ spin_lock_irqsave(vha-hw-vport_slock, flags);
qlt_update_vp_map(vha, RESET_AL_PA);
+ spin_unlock_irqrestore(vha-hw-vport_slock, flags);
qla2x00_mark_vp_devices_dead(vha);
atomic_set(vha-vp_state, VP_FAILED);
--
1.7.2.5
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
