Re: [Bug 111441] New: iscsi fails to attach to targets

[Nicholas A. Bellinger]

On Tue, 2016-02-02 at 14:56 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> > On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> > > On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> > >> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> > >>> HI Mike,
> > >>>
> > >>> I tried your patch and it is has eliminated first traceback but I still 
> > >>> do not see my remote targets.
> > >>>
> > >>
> > >> That is sort of expected. Your target is not setup for ALUA properly. It
> > >> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
> > >> reporting there are none. Ccing the people that made the patch that
> > >> added the issue and own the code.
> > >>
> > >> Hey Christoph and Hannes,
> > >>
> > >> The dh/alua changes that added this:
> > >>
> > >> error = scsi_dh_add_device(sdev);
> > >> if (error) {
> > >> sdev_printk(KERN_INFO, sdev,
> > >> "failed to add device handler: %d\n",
> > >> error);
> > >> return error;
> > >> }
> > >>
> > >> to scsi_sysfs_add_sdev are adding a regression.
> > >>
> > >> 1. If that fails, then we forget to do device_del before doing the
> > >> return. My patch in this thread added that back, so we do not see the
> > >> sysfs oopses anymore. But.
> > >>
> > >> 2. It looks like in older kernels, we would allow misconfigured targets
> > >> like this one to still setup devices. Do we want that old behavior back?
> > >> Should we just ignore the return value from scsi_dh_add_device above?
> > >> Note that in this case, it is LIO so it can be easily fixed on the
> > >> target side by just setting it up properly. I do not think other targets
> > >> would hit this type of issue.
> > >>
> > > 
> > > Btw, what does misconfigured mean here wrt target ALUA..?
> > 
> > [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> > [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> > [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> > [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> > 
> 
> Strange, this hasn't changed in forever on the target side..
> 
> > He has LIO configured to report it supports implicit/explicit ALUA, but
> > the ports do not seem to be configured.
> > 
> > For the LIO config side, are his LUNs just not in a the default_lu_gp or
> > any other group?
> 
> So every non-PSCSI backend device becomes part of default_lu_gp +
> default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
> needing to do any additional configuration.
> 
> Here's what the output looks like:
> 
> root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
> VPD INQUIRY: Device Identification page
>   
>   Designation descriptor number 3, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Relative target port,  code_set: Binary
> associated with the target port
> designator header(hex): 61 94 00 04
> designator:
>  00 00 00 00 02 
>   Designation descriptor number 4, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Target port group,  code_set: Binary
> associated with the target port
> designator header(hex): 61 95 00 04
> designator:
>  00 00 00 00 00 
>   Designation descriptor number 5, descriptor length: 8
> designator_type: Logical unit group,  code_set: Binary
> associated with the addressed logical unit
> designator header(hex): 01 06 00 04
> designator:
>  00 00 00 00 00 
>  
> 
> So AFAICT, the relative target port, target port group, and logical unit
> group being returned from target on v4.5-rc1 code looks correct.
> 
> Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
> with the v3.10 based target..?
> 
> AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
> correct too.
> 
> Hannes, any ideas..?

Ping.

--
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

[Bug 111441] iscsi fails to attach to targets

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=111441

--- Comment #15 from nab  ---
On Tue, 2016-02-02 at 14:56 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> > On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> > > On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> > >> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> > >>> HI Mike,
> > >>>
> > >>> I tried your patch and it is has eliminated first traceback but I still 
> > >>> do not see my remote targets.
> > >>>
> > >>
> > >> That is sort of expected. Your target is not setup for ALUA properly. It
> > >> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
> > >> reporting there are none. Ccing the people that made the patch that
> > >> added the issue and own the code.
> > >>
> > >> Hey Christoph and Hannes,
> > >>
> > >> The dh/alua changes that added this:
> > >>
> > >> error = scsi_dh_add_device(sdev);
> > >> if (error) {
> > >> sdev_printk(KERN_INFO, sdev,
> > >> "failed to add device handler: %d\n",
> > >> error);
> > >> return error;
> > >> }
> > >>
> > >> to scsi_sysfs_add_sdev are adding a regression.
> > >>
> > >> 1. If that fails, then we forget to do device_del before doing the
> > >> return. My patch in this thread added that back, so we do not see the
> > >> sysfs oopses anymore. But.
> > >>
> > >> 2. It looks like in older kernels, we would allow misconfigured targets
> > >> like this one to still setup devices. Do we want that old behavior back?
> > >> Should we just ignore the return value from scsi_dh_add_device above?
> > >> Note that in this case, it is LIO so it can be easily fixed on the
> > >> target side by just setting it up properly. I do not think other targets
> > >> would hit this type of issue.
> > >>
> > > 
> > > Btw, what does misconfigured mean here wrt target ALUA..?
> > 
> > [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> > [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> > [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> > [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> > 
> 
> Strange, this hasn't changed in forever on the target side..
> 
> > He has LIO configured to report it supports implicit/explicit ALUA, but
> > the ports do not seem to be configured.
> > 
> > For the LIO config side, are his LUNs just not in a the default_lu_gp or
> > any other group?
> 
> So every non-PSCSI backend device becomes part of default_lu_gp +
> default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
> needing to do any additional configuration.
> 
> Here's what the output looks like:
> 
> root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
> VPD INQUIRY: Device Identification page
>   
>   Designation descriptor number 3, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Relative target port,  code_set: Binary
> associated with the target port
> designator header(hex): 61 94 00 04
> designator:
>  00 00 00 00 02 
>   Designation descriptor number 4, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Target port group,  code_set: Binary
> associated with the target port
> designator header(hex): 61 95 00 04
> designator:
>  00 00 00 00 00 
>   Designation descriptor number 5, descriptor length: 8
> designator_type: Logical unit group,  code_set: Binary
> associated with the addressed logical unit
> designator header(hex): 01 06 00 04
> designator:
>  00 00 00 00 00 
>  
> 
> So AFAICT, the relative target port, target port group, and logical unit
> group being returned from target on v4.5-rc1 code looks correct.
> 
> Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
> with the v3.10 based target..?
> 
> AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
> correct too.
> 
> Hannes, any ideas..?

Ping.

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
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

[Bug 111341] Firmware loader

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=111341

--- Comment #2 from walter59  ---
some new information :
driver used is not c600 intel
controller is intel c600 id 1d02 --- so it uses ahci driver.

The probleme is the changes in achi.c to mulipile irq for each drive .

this are the changes from 4.4 to 4.5   init phase fails and kernel goes to
endless loop.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Keith Busch]

On Mon, Feb 08, 2016 at 04:19:13PM +0100, Hannes Reinecke wrote:
> Ok, so what about having a 'wwid' attribute which provides combined
> information (like scsi has)?

That looks like the sensible thing to do. Thanks for pointer.

Going forward, I will solicite more feedback from scsi developers
so NVMe's external attributes better align with storage that already
solved our issues. I agree with Christoph that we never should have
relied on SCSI translations for NVMe, but we don't want to reinvent
generic solutions either.
--
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 3/3] add support for DWC UFS Host Controller

[Joao Pinto]

On 2/8/2016 4:15 PM, Mark Rutland wrote:
> On Mon, Feb 08, 2016 at 03:36:52PM +, Joao Pinto wrote:
>> Hi Mark,
>>
>> On 2/8/2016 3:30 PM, Mark Rutland wrote:
>>> On Mon, Feb 08, 2016 at 03:17:11PM +, Joao Pinto wrote:
 Hi Mark and Arnd,
 Are you saying that a user that puts "snps,ufshcd-1.1"
 in the DT compatibility string disables the UFS 2.0 in the core driver 
 despite
 the controller is 2.0? Please clarify.
>>>
>>> If you can consistently and safely detect that the HW is 2.0, using 2.0
>>> functionality is fine.
>>>
>>> Regardless, you should have a -1.1 compatible string for the 1.1 HW, and
>>> a -2.0 string for the 2.0 HW, so that DTs are explicit about what the
>>> hardware is. If 2.0 is intended to be a superset of 1.1, you can have a
>>> 1.1 fallback entry for the 2.0 hardware.
>>>
>>
>> Ok, I will include the version in the compatibility strings, but if someone
>> mentions "snps,ufshcd-1.1" only and the driver detects that the HW is 2.0
>> capable it will activate the 2.0 features independently of what mentioned in 
>> the
>> DT, correct?
> 
> As above, if that can be detected safely and reliably, then I don't see
> a problem with that.

Ok, thanks for the comments! I am working a bit in PCI next version patch and so
I predict to produce a new version for UFS next Wednesday.

Joao

> 
> Thanks,
> Mark.
> 

--
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

[mpt3sas driver V1 6/10] mpt3sas: Added smp_affinity_enable module parameter.

[Suganath prabu Subramani]

Module parameter to enable/disable configuring
affinity hint for msix vector.
SMP affinity feature can be enabled/disabled by setting
module parameter "smp_affinity_enable" to 1/0.
By default this feature is enabled. (smp_affinity_enable = 1 enabled).

Signed-off-by: Suganath prabu Subramani 
Signed-off-by: Chaitra P B 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 31838d9a..582ba4b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -83,6 +83,10 @@ static int msix_disable = -1;
 module_param(msix_disable, int, 0);
 MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts (default=0)");
 
+static int smp_affinity_enable = 1;
+module_param(smp_affinity_enable, int, S_IRUGO);
+MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale 
Default: enable(1)");
+
 static int max_msix_vectors = -1;
 module_param(max_msix_vectors, int, 0);
 MODULE_PARM_DESC(max_msix_vectors,
@@ -1812,8 +1816,10 @@ _base_free_irq(struct MPT3SAS_ADAPTER *ioc)
 
list_for_each_entry_safe(reply_q, next, >reply_queue_list, list) {
list_del(_q->list);
-   irq_set_affinity_hint(reply_q->vector, NULL);
-   free_cpumask_var(reply_q->affinity_hint);
+   if (smp_affinity_enable) {
+   irq_set_affinity_hint(reply_q->vector, NULL);
+   free_cpumask_var(reply_q->affinity_hint);
+   }
synchronize_irq(reply_q->vector);
free_irq(reply_q->vector, reply_q);
kfree(reply_q);
@@ -1844,9 +1850,13 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 index, 
u32 vector)
reply_q->msix_index = index;
reply_q->vector = vector;
 
-   if (!alloc_cpumask_var(_q->affinity_hint, GFP_KERNEL))
-   return -ENOMEM;
-   cpumask_clear(reply_q->affinity_hint);
+   if (smp_affinity_enable) {
+   if (!zalloc_cpumask_var(_q->affinity_hint, GFP_KERNEL)) {
+   kfree(reply_q);
+   return -ENOMEM;
+   }
+   cpumask_clear(reply_q->affinity_hint);
+   }
 
atomic_set(_q->busy, 0);
if (ioc->msix_enable)
@@ -1861,6 +1871,7 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 index, 
u32 vector)
pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
reply_q->name, vector);
kfree(reply_q);
+   free_cpumask_var(reply_q->affinity_hint);
return -EBUSY;
}
 
@@ -1909,16 +1920,17 @@ _base_assign_reply_queues(struct MPT3SAS_ADAPTER *ioc)
 
for (i = 0 ; i < group ; i++) {
ioc->cpu_msix_table[cpu] = index;
-   cpumask_or(reply_q->affinity_hint,
+   if (smp_affinity_enable)
+   cpumask_or(reply_q->affinity_hint,
   reply_q->affinity_hint, get_cpu_mask(cpu));
cpu = cpumask_next(cpu, cpu_online_mask);
}
-
-   if (irq_set_affinity_hint(reply_q->vector,
+   if (smp_affinity_enable)
+   if (irq_set_affinity_hint(reply_q->vector,
   reply_q->affinity_hint))
-   dinitprintk(ioc, pr_info(MPT3SAS_FMT
-   "error setting affinity hint for irq vector %d\n",
-   ioc->name, reply_q->vector));
+   dinitprintk(ioc, pr_info(MPT3SAS_FMT
+"Err setting affinity hint to irq vector %d\n",
+ioc->name, reply_q->vector));
index++;
}
 }
@@ -1976,6 +1988,9 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
} else if (max_msix_vectors == 0)
goto try_ioapic;
 
+   if (ioc->msix_vector_count < ioc->cpu_count)
+   smp_affinity_enable = 0;
+
entries = kcalloc(ioc->reply_queue_count, sizeof(struct msix_entry),
GFP_KERNEL);
if (!entries) {
-- 
1.8.3.1

--
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 3/3] add support for DWC UFS Host Controller

[Mark Rutland]

On Mon, Feb 08, 2016 at 03:36:52PM +, Joao Pinto wrote:
> Hi Mark,
> 
> On 2/8/2016 3:30 PM, Mark Rutland wrote:
> > On Mon, Feb 08, 2016 at 03:17:11PM +, Joao Pinto wrote:
> >> Hi Mark and Arnd,
> >> Are you saying that a user that puts "snps,ufshcd-1.1"
> >> in the DT compatibility string disables the UFS 2.0 in the core driver 
> >> despite
> >> the controller is 2.0? Please clarify.
> > 
> > If you can consistently and safely detect that the HW is 2.0, using 2.0
> > functionality is fine.
> > 
> > Regardless, you should have a -1.1 compatible string for the 1.1 HW, and
> > a -2.0 string for the 2.0 HW, so that DTs are explicit about what the
> > hardware is. If 2.0 is intended to be a superset of 1.1, you can have a
> > 1.1 fallback entry for the 2.0 hardware.
> > 
> 
> Ok, I will include the version in the compatibility strings, but if someone
> mentions "snps,ufshcd-1.1" only and the driver detects that the HW is 2.0
> capable it will activate the 2.0 features independently of what mentioned in 
> the
> DT, correct?

As above, if that can be detected safely and reliably, then I don't see
a problem with that.

Thanks,
Mark.
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Christoph Hellwig]

On Mon, Feb 08, 2016 at 12:01:16PM +0200, Sagi Grimberg wrote:
>
>> Do we have defined sysfs attributes for NVMe devices nowadays?
>
> /sys/block/nvme0n1/uuid

That's only supported for NVMe 1.1 and higher devices, and optional.
For older or stupid devices we need to support the algorithm based
on the serial attribute from nvme_fill_device_id_scsi_string() in
drivers/nvme/host/scsi.c.

Which btw is іncorrect as it doesn't identify namespaces properly,
and thus the associatation of 0 is an actively harmful lie.
--
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/2] megaraid_sas: Fix for IO failing post OCR in SRIOV environment

[Tomas Henzl]

On 5.2.2016 13:24, Sumit Saxena wrote:
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, January 29, 2016 9:47 PM
>> To: Sumit Saxena; jbottom...@parallels.com; h...@infradead.org;
>> martin.peter...@oracle.com
>> Cc: linux-scsi@vger.kernel.org; kashyap.de...@avagotech.com; Uday
> Lingala
>> Subject: Re: [PATCH 1/2] megaraid_sas: Fix for IO failing post OCR in
> SRIOV
>> environment
>>
>> On 28.1.2016 16:44, Sumit Saxena wrote:
>>> Driver assumes that VFs always have peers present whenever they have
> same
>> LD IDs. But this is not the case.
>>> This patch handles the above mentioned by explicitly checking for a
> peer
>> before making HA/non-HA path decision.
>>> Signed-off-by: Uday Lingala 
>>> Signed-off-by: Sumit Saxena 
>>>
>>> ---
>>>  drivers/scsi/megaraid/megaraid_sas.h| 13 ++---
>>>  drivers/scsi/megaraid/megaraid_sas_base.c   |  6 +++--
>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 42
>>> ++---
>>>  3 files changed, 39 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index b6fdb48..4484e63 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -393,6 +393,7 @@ enum MR_EVT_ARGS {
>>>
>>>
>>>  #define SGE_BUFFER_SIZE4096
>>> +#define MEGASAS_CLUSTER_ID_SIZE16
>>>  /*
>>>   * define constants for device list query options
>>>   */
>>> @@ -1227,7 +1228,8 @@ struct megasas_ctrl_info {
>>> */
>>> struct {
>>>  #if defined(__BIG_ENDIAN_BITFIELD)
>>> -   u32 reserved:26;
>>> +   u32 reserved:25;
>>> +   u32 passive:1;
>>> u32 premiumFeatureMismatch:1;
>>> u32 ctrlPropIncompatible:1;
>>> u32 fwVersionMismatch:1;
>>> @@ -1241,11 +1243,12 @@ struct megasas_ctrl_info {
>>> u32 fwVersionMismatch:1;
>>> u32 ctrlPropIncompatible:1;
>>> u32 premiumFeatureMismatch:1;
>>> -   u32 reserved:26;
>>> +   u32 passive:1;
>>> +   u32 reserved:25;
>>>  #endif
>>> } cluster;
>>>
>>> -   char clusterId[16]; /*7D4h */
>>> +   char clusterId[MEGASAS_CLUSTER_ID_SIZE]; /*0x7D4 */
>>> struct {
>>> u8  maxVFsSupported;/*0x7E4*/
>>> u8  numVFsEnabled;  /*0x7E5*/
>>> @@ -2126,7 +2129,9 @@ struct megasas_instance {
>>> char skip_heartbeat_timer_del;
>>> u8 requestorId;
>>> char PlasmaFW111;
>>> -   char mpio;
>>> +   char clusterId[MEGASAS_CLUSTER_ID_SIZE];
>>> +   u8 peerIsPresent;
>>> +   u8 passive;
>>> u16 throttlequeuedepth;
>>> u8 mask_interrupts;
>>> u16 max_chain_frame_sz;
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>>> index 54922e5..52f3419 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>>> @@ -1943,7 +1943,7 @@ void megaraid_sas_kill_hba(struct
>> megasas_instance *instance)
>>> writel(MFI_STOP_ADP, >reg_set->doorbell);
>>> /* Flush */
>>> readl(>reg_set->doorbell);
>>> -   if (instance->mpio && instance->requestorId)
>>> +   if (instance->requestorId && instance->peerIsPresent)
>>> memset(instance->ld_ids, 0xff,
>> MEGASAS_MAX_LD_IDS);
>>> } else {
>>> writel(MFI_STOP_ADP,
>>> @@ -5182,7 +5182,9 @@ static int megasas_init_fw(struct
>>> megasas_instance *instance)
>>>
>>> tmp_sectors = min_t(u32, max_sectors_1, max_sectors_2);
>>>
>>> -   instance->mpio = ctrl_info->adapterOperations2.mpio;
>>> +   instance->peerIsPresent = ctrl_info->cluster.peerIsPresent;
>>> +   instance->passive = ctrl_info->cluster.passive;
>>> +   memcpy(instance->clusterId, ctrl_info->clusterId,
>>> +sizeof(instance->clusterId));
>>> instance->UnevenSpanSupport =
>>> ctrl_info->adapterOperations2.supportUnevenSpans;
>>> if (instance->UnevenSpanSupport) {
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>>> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>>> index be9c3f1..d9d0029 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>>> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>>> @@ -3325,27 +3325,37 @@ out:
>>> return ret;
>>>  }
>>>
>>> +/*SRIOV get other instance in cluster if any*/ struct
>>> +megasas_instance *megasas_get_peer_instance(struct megasas_instance
>>> +*instance) {
>>> +   int i;
>>> +
>>> +   for (i = 0; i < MAX_MGMT_ADAPTERS; i++) {
>>> +   if (megasas_mgmt_info.instance[i] &&
>>> +   (megasas_mgmt_info.instance[i] != instance) &&
>>> +megasas_mgmt_info.instance[i]->requestorId &&
>>> +megasas_mgmt_info.instance[i]->peerIsPresent &&
>>> +
> 

Re: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Sagi Grimberg]

Do we have defined sysfs attributes for NVMe devices nowadays?


/sys/block/nvme0n1/uuid


If so I'd be willing to create/send some sysfs rules for them.


That'd be great!
--
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: [mpt3sas driver 06/10] mpt3sas: Added smp_affinity_enable module parameter.

[Tomas Henzl]

On 8.2.2016 07:01, Suganath Prabu Subramani wrote:
> Hi Tomas,
> Initially, we posted this patch with "zalloc_cpumassk_var" and Robert
> has suggested to use "alloc_cpumask_var". Please check the below link.
> "http://www.gossamer-threads.com/lists/linux/kernel/2068280?do=post_view_threaded#2068280;

That thread is about allocating more than KMALLOC_MAX_SIZE with a kmalloc,
it doesn't matter if it is a kzalloc or kmalloc.

If that is an issue in mpt3sas, in your code fails already here when 
!CONFIG_CPUMASK_OFFSTACK

reply_q =  kzalloc(sizeof(struct adapter_reply_queue), GFP_KERNEL);

Good news is that the the size allocated in your case is much smaller than what
the lpfc tried at that time, (it used a struct with struct cpumask  maskbits;
and multiplied it with nr_cpus) -> this is not your case.
You can use that zalloc_cpumask_var.

--tm

>
> We incorporated other review comments for freeing reply_q and
> cpumask_var in this patch and sending it soon.
>
> Thanks,
> Suganath prabu S
>
> On Thu, Feb 4, 2016 at 8:31 PM, Tomas Henzl  wrote:
>> On 28.1.2016 07:37, Suganath prabu Subaramani wrote:
>>> From: Suganath prabu Subramani 
>>>
>>> Module parameter to enable/disable configuring
>>> affinity hint for msix vector.
>>> SMP affinity feature can be enabled/disabled by setting
>>> module parameter "smp_affinity_enable" to 1/0.
>>> By default this feature is enabled. (smp_affinity_enable = 1 enabled).
>>>
>>> Signed-off-by: Suganath prabu Subramani 
>>> 
>>> Signed-off-by: Chaitra P B 
>>> ---
>>>  drivers/scsi/mpt3sas/mpt3sas_base.c | 34 +++---
>>>  1 file changed, 23 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
>>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> index 31838d9a..a1a3b39 100644
>>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> @@ -83,6 +83,10 @@ static int msix_disable = -1;
>>>  module_param(msix_disable, int, 0);
>>>  MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts 
>>> (default=0)");
>>>
>>> +static int smp_affinity_enable = 1;
>>> +module_param(smp_affinity_enable, int, S_IRUGO);
>>> +MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale 
>>> Default: enable(1)");
>>> +
>>>  static int max_msix_vectors = -1;
>>>  module_param(max_msix_vectors, int, 0);
>>>  MODULE_PARM_DESC(max_msix_vectors,
>>> @@ -1812,8 +1816,10 @@ _base_free_irq(struct MPT3SAS_ADAPTER *ioc)
>>>
>>>   list_for_each_entry_safe(reply_q, next, >reply_queue_list, list) 
>>> {
>>>   list_del(_q->list);
>>> - irq_set_affinity_hint(reply_q->vector, NULL);
>>> - free_cpumask_var(reply_q->affinity_hint);
>>> + if (smp_affinity_enable) {
>>> + irq_set_affinity_hint(reply_q->vector, NULL);
>>> + free_cpumask_var(reply_q->affinity_hint);
>>> + }
>>>   synchronize_irq(reply_q->vector);
>>>   free_irq(reply_q->vector, reply_q);
>>>   kfree(reply_q);
>>> @@ -1844,9 +1850,11 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 
>>> index, u32 vector)
>>>   reply_q->msix_index = index;
>>>   reply_q->vector = vector;
>>>
>>> - if (!alloc_cpumask_var(_q->affinity_hint, GFP_KERNEL))
>>> - return -ENOMEM;
>>> - cpumask_clear(reply_q->affinity_hint);
>>> + if (smp_affinity_enable) {
>>> + if (!alloc_cpumask_var(_q->affinity_hint, GFP_KERNEL))
>> a kfree(reply_q); should go here
>>
>>> + return -ENOMEM;
>>> + cpumask_clear(reply_q->affinity_hint);
>> maybe zalloc_cpumask_var ?
>>
>>> + }
>> if (r) {
>> pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
>> reply_q->name, vector);
>> kfree(reply_q);
>> and a  free_cpumask_var (..)  here ?
>> return -EBUSY;
>>
>>
>> cheers,
>> tomash
>>
> --
> 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

--
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 3/4] qla2xxx: Add DebugFS node for target sess list.

[Nicholas A. Bellinger]

On Mon, 2016-02-08 at 17:43 +, Himanshu Madhani wrote:
> >
> >So looking at this patch beyond the debugfs part, it does change where
> >->check_initiator_node_acl() gets call during qlt_create_sess().
> >
> >I assume this is related to new debugfs attribute, and these changes
> >(plus others in qlt_del_sess_work_fn) are not bug-fixes on their own,
> >correct..?
> >
> >Aside from that, I don't have an objection to merge as v4.6 for-next
> >code if QLogic finds it useful for debugging.
> 
> Yes. The changes in this patch are strictly for making information
> available via debugFS and not bug-fixes on their own.

Thanks for clarifying.

> This information has been requested by few customer who
> finds this information useful for debugging and in addition they use this
> information in their configuration scripts as well.

So I've got no particular objection to people adding debugfs
informational attributes for whatever to aid debugging of their drivers.

That said, the same information can too be exposed as a tcm_qla2xxx
struct se_node_acl->acl_group configfs attribute, and for demo-mode
sessions via a tcm_qla2xxx provided dynamic_sessions configfs attribute
handler.

I'd be happy to add expose this under tcm_qla2xxx configfs for v4.6 code
if you'd like, otherwise I'm OK with the patch in queue-next as-is if
you find it useful.

--
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-v4 0/5] Fix LUN_RESET active I/O + TMR handling

[Nicholas A. Bellinger]

Hi Himanshu,

On Mon, 2016-02-08 at 23:27 +, Himanshu Madhani wrote:
> 
> I am testing this series with with 4.5.0-rc2+ kernel and I am seeing issue
> where trying to trigger
> sg_reset with option of host/device/bus in loop at 120second interval
> causes call stack. At this point
> removing configuration hangs indefinitely. See attached dmesg output from
> my setup. 
> 

Thanks alot for testing this.

So It looks like we're still hitting a indefinite schedule() on
se_cmd->cmd_wait_comp once tcm_qla2xxx session disconnect/reconnect
occurs, after repeated explicit active I/O remote-port sg_resets.

Does this trigger on the first tcm_qla2xxx session reconnect after
explicit remote-port sg_reset..?  Are session reconnects actively being
triggered during the test..?

To verify the latter for iscsi-target, I've been using a small patch to
trigger session reset from TMR kthread context in order to simulate the
I_T disconnects.  Something like that would be useful for verifying with
tcm_qla2xxx too.

That said, I'll be reproducing with tcm_qla2xxx ports this week, and
will enable various debug in a WIP branch for testing.

Thank you,

--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 13/23] scsi_dh_alua: Use workqueue for RTPG

[Hannes Reinecke]

The current ALUA device_handler has two drawbacks:
- We're sending a 'SET TARGET PORT GROUP' command to every LUN,
  disregarding the fact that several LUNs might be in a port group
  and will be automatically switched whenever _any_ LUN within
  that port group receives the command.
- Whenever a LUN is in 'transitioning' mode we cannot block I/O
  to that LUN, instead the controller has to abort the command.
  This leads to increased traffic across the wire and heavy load
  on the controller during switchover.

With this patch the RTPG handling is moved to a per-portgroup
workqueue. This reduces the number of 'REPORT TARGET PORT GROUP'
and 'SET TARGET PORT GROUPS' sent to the controller as we're sending
them now per port group, and not per device as previously.
It also allows us to block I/O to any LUN / port group found to be
in 'transitioning' ALUA mode, as the workqueue item will be requeued
until the controller moves out of transitioning.

Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 294 +++--
 1 file changed, 241 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 4b115f2..901768f 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -59,10 +59,15 @@
 #define ALUA_RTPG_SIZE 128
 #define ALUA_FAILOVER_TIMEOUT  60
 #define ALUA_FAILOVER_RETRIES  5
+#define ALUA_RTPG_DELAY_MSECS  5
 
 /* device handler flags */
-#define ALUA_OPTIMIZE_STPG 1
-#define ALUA_RTPG_EXT_HDR_UNSUPP   2
+#define ALUA_OPTIMIZE_STPG 0x01
+#define ALUA_RTPG_EXT_HDR_UNSUPP   0x02
+/* State machine flags */
+#define ALUA_PG_RUN_RTPG   0x10
+#define ALUA_PG_RUN_STPG   0x20
+#define ALUA_PG_RUNNING0x40
 
 static uint optimize_stpg;
 module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
@@ -70,9 +75,11 @@ MODULE_PARM_DESC(optimize_stpg, "Allow use of a 
non-optimized path, rather than
 
 static LIST_HEAD(port_group_list);
 static DEFINE_SPINLOCK(port_group_lock);
+static struct workqueue_struct *kaluad_wq;
 
 struct alua_port_group {
struct kref kref;
+   struct rcu_head rcu;
struct list_headnode;
unsigned char   device_id_str[256];
int device_id_len;
@@ -82,12 +89,25 @@ struct alua_port_group {
int pref;
unsignedflags; /* used for optimizing STPG */
unsigned char   transition_tmo;
+   unsigned long   expiry;
+   unsigned long   interval;
+   struct delayed_work rtpg_work;
+   spinlock_t  lock;
+   struct list_headrtpg_list;
+   struct scsi_device  *rtpg_sdev;
 };
 
 struct alua_dh_data {
struct alua_port_group  *pg;
int group_id;
+   spinlock_t  pg_lock;
struct scsi_device  *sdev;
+   int init_error;
+   struct mutexinit_mutex;
+};
+
+struct alua_queue_data {
+   struct list_headentry;
activate_complete   callback_fn;
void*callback_data;
 };
@@ -95,18 +115,22 @@ struct alua_dh_data {
 #define ALUA_POLICY_SWITCH_CURRENT 0
 #define ALUA_POLICY_SWITCH_ALL 1
 
-static int alua_rtpg(struct scsi_device *, struct alua_port_group *);
-static char print_alua_state(int);
+static void alua_rtpg_work(struct work_struct *work);
+static void alua_rtpg_queue(struct alua_port_group *pg,
+   struct scsi_device *sdev,
+   struct alua_queue_data *qdata);
 
 static void release_port_group(struct kref *kref)
 {
struct alua_port_group *pg;
 
pg = container_of(kref, struct alua_port_group, kref);
+   if (pg->rtpg_sdev)
+   flush_delayed_work(>rtpg_work);
spin_lock(_group_lock);
list_del(>node);
spin_unlock(_group_lock);
-   kfree(pg);
+   kfree_rcu(pg, rcu);
 }
 
 /*
@@ -225,6 +249,10 @@ struct alua_port_group *alua_alloc_pg(struct scsi_device 
*sdev,
if (optimize_stpg)
pg->flags |= ALUA_OPTIMIZE_STPG;
kref_init(>kref);
+   INIT_DELAYED_WORK(>rtpg_work, alua_rtpg_work);
+   INIT_LIST_HEAD(>rtpg_list);
+   INIT_LIST_HEAD(>node);
+   spin_lock_init(>lock);
 
spin_lock(_group_lock);
tmp_pg = alua_find_get_pg(pg->device_id_str, pg->device_id_len,
@@ -304,6 +332,7 @@ static int alua_check_vpd(struct scsi_device *sdev, struct 
alua_dh_data *h,
  int tpgs)
 {
int rel_port = -1, group_id;
+   struct alua_port_group *pg, *old_pg = NULL;
 
group_id = scsi_vpd_tpg_id(sdev, _port);
if (group_id < 0) {
@@ -318,18 +347,30 @@ 

Re: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Keith Busch]

On Mon, Feb 08, 2016 at 11:13:50AM +0100, Christoph Hellwig wrote:
> On Mon, Feb 08, 2016 at 12:01:16PM +0200, Sagi Grimberg wrote:
> >
> >> Do we have defined sysfs attributes for NVMe devices nowadays?
> >
> > /sys/block/nvme0n1/uuid
> 
> That's only supported for NVMe 1.1 and higher devices, and optional.
> For older or stupid devices we need to support the algorithm based
> on the serial attribute from nvme_fill_device_id_scsi_string() in
> drivers/nvme/host/scsi.c.

It's even worse. NGUID was defined for 1.2 devices and higher. 1.1
devices should have EUI-64 at:
 
  /sys/block/nvmeXnY/eui

1.2 devices will have either uuid or eui (or both).

The majority of devices in circulation today are 1.0, and need to concat
these three entries to make a unique identifier:

  /sys/block/nvmeXnY/device/serial
  /sys/block/nvmeXnY/device/model
  /sys/block/nvmeXnY/nsid
--
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 3/3] add support for DWC UFS Host Controller

[Joao Pinto]

Hi Mark,

On 2/8/2016 3:30 PM, Mark Rutland wrote:
> On Mon, Feb 08, 2016 at 03:17:11PM +, Joao Pinto wrote:
>> Hi Mark and Arnd,
>>
>> I am planning the v2 of this patch set. I have a doubt in the version
>> compatibility strings... The core driver must support the UFS 2.0 controller 
>> and
>> this patch set includes a patch that adds 2.0 capabilities to it.
> 
> Ok. It wasn't clear to me that this series added support for features
> specific to 2.0.

Yes, the patch set contains a patch to add 2.0 to the UFS core driver.
The cover letter:
https://lkml.org/lkml/2016/2/3/331
The Patch:
https://lkml.org/lkml/2016/2/3/330

> 
>> The core driver can get from the controller's version and with that
>> use or not a specific 2.0 feature.
> 
> It can be detected from the hardware?

Yes, the hardware has a register that contains the version, and so if a driver
has workarounds then it can adapt.

> 
>> What would be the real added-value of having a compatibility string like
>> "snps,ufshcd-1.1" and "snps,ufshcd-2.0" if the driver can perform as 2.0 if 
>> it
>> detects a 2.0 controller?
> 
> Generally having specify strings ensure that it's possible to handle
> things in future (e.g. errata workarounds), or if we realise something
> isn't as clear-cut as we thought it was (i.e. 2.0 not being a strict
> superset of 1.1).
> 



> It's difficult to predict when you need that, so we err on the side of
> requiring it. At worst it means you have a small redundant few
> characters in a DT, but that's a much better proposition than having too
> little information.
> 
>> Are you saying that a user that puts "snps,ufshcd-1.1"
>> in the DT compatibility string disables the UFS 2.0 in the core driver 
>> despite
>> the controller is 2.0? Please clarify.
> 
> If you can consistently and safely detect that the HW is 2.0, using 2.0
> functionality is fine.
> 
> Regardless, you should have a -1.1 compatible string for the 1.1 HW, and
> a -2.0 string for the 2.0 HW, so that DTs are explicit about what the
> hardware is. If 2.0 is intended to be a superset of 1.1, you can have a
> 1.1 fallback entry for the 2.0 hardware.
> 

Ok, I will include the version in the compatibility strings, but if someone
mentions "snps,ufshcd-1.1" only and the driver detects that the HW is 2.0
capable it will activate the 2.0 features independently of what mentioned in the
DT, correct?

> Thanks,
> Mark.
> 

Thanks,
Joao
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[James Bottomley]

On Mon, 2016-02-08 at 08:32 +0100, Hannes Reinecke wrote:
> On 02/08/2016 12:07 AM, James Bottomley wrote:
> > On Sun, 2016-02-07 at 15:28 -0700, Jens Axboe wrote:
> > > On 02/07/2016 09:04 AM, James Bottomley wrote:
> > > > On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:
> > > > > Keith said it should be on by default, and I promised him to
> > > > > change
> > > > > it once we run into problems, which I guess this counts as.
> > > > > 
> > > > > But just curious:  what distro are you using?  Upstream
> > > > > systemd
> > > > > explicitly rejected using scsi_id for NVMe here:
> > > > > 
> > > > >   https://github.com/systemd/systemd/issues/1453
> > > > > 
> > > > > and all my test systems don't do this either.
> > > > 
> > > > This was SUSE (in my case, openSUSE Leap).  I just checked the
> > > > source
> > > > package; they patch the by-id rules back in for NVME:
> > > > 
> > > > # PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe
> > > > -devices.patch (bsc#944132)
> > > > Patch1101:  1101-rules-persistent-device-names-for-NVMe
> > > > -devices.patch
> > > > 
> > > > The bugzilla is giving access denied for bug id 944132, so it's
> > > > likely
> > > > some proprietary vendor problem.  The patch has no preamble, so
> > > > it's
> > > > hard to tell what they were thinking.
> > > 
> > > I run root-on-nvme on my laptop, and I haven't observed any
> > > problems.
> > 
> > Me too apparently.  It looks like this problem may be SUSE specific
> > unless another distro has enabled this.  I can see why they would:
> > you
> > do need persistent names for devices, even NVMe ones.
> > 
> > > Generally I hate for options to default y unless absolutely 
> > > necessary, it's a sure fire way to feature creep your kernel
> > > without 
> > > noticing. I don't think getting all hot about this issue is fair,
> > > if 
> > > the only known case is suse.
> > 
> > Well, OK, I'm annoyed because it was a systemd system which means
> > debugging boot failures are excruciatingly difficult so it took me
> > a
> > week and a half to find out what the problem was.  Perhaps I was a
> > bit
> > rash to label this as an easily foreseen problem.
> > 
> > I opened a bug against SUSE to tell them to turn it on:
> > 
> > https://bugzilla.opensuse.org/show_bug.cgi?id=965497
> > 
> > The second problem is that there's currently no way to transition
> > to
> > using the serial attribute the way the udev 60-persistent
> > -storage.rules
> > are written, so if distros have some by-id hack, it will have to be
> > maintained for a while.  I annotated the already closed bug on this
> > in
> > systemd with the rules that work for me.
> > 
> Why, but you can.
> That's precisely what I did with the transition to sg_inq; I've
> added a new set of rules (55-sg_inq.rules and 59-sg-symlinks.rules)
> which will override the values from 60-persistent-storage.rules.
> 
> Do we have defined sysfs attributes for NVMe devices nowadays?
> If so I'd be willing to create/send some sysfs rules for them.

This is the one I finally settled on (for 60-persistent-storage) for
SUSE.  It keeps everything working across old and new kernels.

# nvme
SUBSYSTEMS=="nvme", ATTRS{serial}=="?*", PROGRAM="/usr/bin/echo $attr{serial}", 
ENV{ID_SERIAL}="%c", ENV{ID_BUS}="nvme"

I already complained to Keith that the echo is required to strip the
leading whitespace which I don't think should be in the serial
attribute.

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

[PATCH 18/23] scsi_dh_alua: Send TEST UNIT READY to poll for transitioning

[Hannes Reinecke]

Sending a 'REPORT TARGET PORT GROUP' command is a costly operation,
as the array has to gather information about all ports.
So instead of using RTPG to poll for a status update when a port
is in transitioning we should be sending a TEST UNIT READY, and
wait for the sense code to report success.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Ewan Milne 
Reviewed-by: Christoph Hellwig 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index de8e79e..a1db82f 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -466,6 +466,30 @@ static int alua_check_sense(struct scsi_device *sdev,
 }
 
 /*
+ * alua_tur - Send a TEST UNIT READY
+ * @sdev: device to which the TEST UNIT READY command should be send
+ *
+ * Send a TEST UNIT READY to @sdev to figure out the device state
+ * Returns SCSI_DH_RETRY if the sense code is NOT READY/ALUA TRANSITIONING,
+ * SCSI_DH_OK if no error occurred, and SCSI_DH_IO otherwise.
+ */
+static int alua_tur(struct scsi_device *sdev)
+{
+   struct scsi_sense_hdr sense_hdr;
+   int retval;
+
+   retval = scsi_test_unit_ready(sdev, ALUA_FAILOVER_TIMEOUT * HZ,
+ ALUA_FAILOVER_RETRIES, _hdr);
+   if (sense_hdr.sense_key == NOT_READY &&
+   sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a)
+   return SCSI_DH_RETRY;
+   else if (retval)
+   return SCSI_DH_IO;
+   else
+   return SCSI_DH_OK;
+}
+
+/*
  * alua_rtpg - Evaluate REPORT TARGET GROUP STATES
  * @sdev: the device to be evaluated.
  *
@@ -735,8 +759,22 @@ static void alua_rtpg_work(struct work_struct *work)
alua_wq = kaluad_sync_wq;
pg->flags |= ALUA_PG_RUNNING;
if (pg->flags & ALUA_PG_RUN_RTPG) {
+   int state = pg->state;
+
pg->flags &= ~ALUA_PG_RUN_RTPG;
spin_unlock_irqrestore(>lock, flags);
+   if (state == TPGS_STATE_TRANSITIONING) {
+   if (alua_tur(sdev) == SCSI_DH_RETRY) {
+   spin_lock_irqsave(>lock, flags);
+   pg->flags &= ~ALUA_PG_RUNNING;
+   pg->flags |= ALUA_PG_RUN_RTPG;
+   spin_unlock_irqrestore(>lock, flags);
+   queue_delayed_work(alua_wq, >rtpg_work,
+  pg->interval * HZ);
+   return;
+   }
+   /* Send RTPG on failure or if TUR indicates SUCCESS */
+   }
err = alua_rtpg(sdev, pg);
spin_lock_irqsave(>lock, flags);
if (err == SCSI_DH_RETRY || pg->flags & ALUA_PG_RUN_RTPG) {
-- 
1.8.5.6

--
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 08/23] scsi_dh_alua: use unique device id

[Hannes Reinecke]

Use scsi_vpd_lun_id() to assign a unique device identification
to the alua port group structure.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 55 +++---
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 5c8d0d3..25d0a92 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -70,6 +70,8 @@ static DEFINE_SPINLOCK(port_group_lock);
 struct alua_port_group {
struct kref kref;
struct list_headnode;
+   unsigned char   device_id_str[256];
+   int device_id_len;
int group_id;
int tpgs;
int state;
@@ -162,6 +164,26 @@ static int submit_stpg(struct scsi_device *sdev, int 
group_id,
  ALUA_FAILOVER_RETRIES, NULL, req_flags);
 }
 
+struct alua_port_group *alua_find_get_pg(char *id_str, size_t id_size,
+int group_id)
+{
+   struct alua_port_group *pg;
+
+   list_for_each_entry(pg, _group_list, node) {
+   if (pg->group_id != group_id)
+   continue;
+   if (pg->device_id_len != id_size)
+   continue;
+   if (strncmp(pg->device_id_str, id_str, id_size))
+   continue;
+   if (!kref_get_unless_zero(>kref))
+   continue;
+   return pg;
+   }
+
+   return NULL;
+}
+
 /*
  * alua_alloc_pg - Allocate a new port_group structure
  * @sdev: scsi device
@@ -174,17 +196,39 @@ static int submit_stpg(struct scsi_device *sdev, int 
group_id,
 struct alua_port_group *alua_alloc_pg(struct scsi_device *sdev,
  int group_id, int tpgs)
 {
-   struct alua_port_group *pg;
+   struct alua_port_group *pg, *tmp_pg;
 
pg = kzalloc(sizeof(struct alua_port_group), GFP_KERNEL);
if (!pg)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
+   pg->device_id_len = scsi_vpd_lun_id(sdev, pg->device_id_str,
+   sizeof(pg->device_id_str));
+   if (pg->device_id_len <= 0) {
+   /*
+* Internal error: TPGS supported but no device
+* identifcation found. Disable ALUA support.
+*/
+   kfree(pg);
+   sdev_printk(KERN_INFO, sdev,
+   "%s: No device descriptors found\n",
+   ALUA_DH_NAME);
+   return ERR_PTR(-ENXIO);
+   }
pg->group_id = group_id;
pg->tpgs = tpgs;
pg->state = TPGS_STATE_OPTIMIZED;
kref_init(>kref);
+
spin_lock(_group_lock);
+   tmp_pg = alua_find_get_pg(pg->device_id_str, pg->device_id_len,
+ group_id);
+   if (tmp_pg) {
+   spin_unlock(_group_lock);
+   kfree(pg);
+   return tmp_pg;
+   }
+
list_add(>node, _group_list);
spin_unlock(_group_lock);
 
@@ -269,7 +313,7 @@ static int alua_check_vpd(struct scsi_device *sdev, struct 
alua_dh_data *h)
h->group_id = group_id;
 
sdev_printk(KERN_INFO, sdev,
-   "%s: port group %02x rel port %02x\n",
+   "%s: port group %x rel port %x\n",
ALUA_DH_NAME, h->group_id, h->rel_port);
 
return 0;
@@ -599,8 +643,9 @@ static int alua_initialize(struct scsi_device *sdev, struct 
alua_dh_data *h)
goto out;
 
h->pg = alua_alloc_pg(sdev, h->group_id, tpgs);
-   if (!h->pg) {
-   err = SCSI_DH_NOMEM;
+   if (IS_ERR(h->pg)) {
+   if (PTR_ERR(h->pg) == -ENOMEM)
+   err = SCSI_DH_NOMEM;
goto out;
}
kref_get(>pg->kref);
-- 
1.8.5.6

--
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 02/23] scsi_dh_alua: separate out alua_stpg()

[Hannes Reinecke]

Separate out SET TARGET PORT GROUP functionality into a separate
function alua_stpg().

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 95 +++---
 1 file changed, 61 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index df71e85..7c66e4a 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -579,6 +579,65 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
 }
 
 /*
+ * alua_stpg - Issue a SET TARGET GROUP STATES command
+ *
+ * Issue a SET TARGET GROUP STATES command and evaluate the
+ * response. Returns SCSI_DH_RETRY if the target port group
+ * state is found to be in 'transitioning'.
+ * If SCSI_DH_OK is returned the passed-in 'fn' function
+ * this function will take care of executing 'fn'.
+ * Otherwise 'fn' should be executed by the caller with the
+ * returned error code.
+ */
+static unsigned alua_stpg(struct scsi_device *sdev, struct alua_dh_data *h,
+ activate_complete fn, void *data)
+{
+   int err = SCSI_DH_OK;
+   int stpg = 0;
+
+   if (!(h->tpgs & TPGS_MODE_EXPLICIT))
+   /* Only implicit ALUA supported */
+   goto out;
+
+   switch (h->state) {
+   case TPGS_STATE_NONOPTIMIZED:
+   stpg = 1;
+   if ((h->flags & ALUA_OPTIMIZE_STPG) &&
+   !h->pref &&
+   (h->tpgs & TPGS_MODE_IMPLICIT))
+   stpg = 0;
+   break;
+   case TPGS_STATE_STANDBY:
+   case TPGS_STATE_UNAVAILABLE:
+   stpg = 1;
+   break;
+   case TPGS_STATE_OFFLINE:
+   err = SCSI_DH_IO;
+   break;
+   case TPGS_STATE_TRANSITIONING:
+   err = SCSI_DH_RETRY;
+   break;
+   default:
+   break;
+   }
+
+   if (stpg) {
+   h->callback_fn = fn;
+   h->callback_data = data;
+   err = submit_stpg(h);
+   if (err != SCSI_DH_OK)
+   h->callback_fn = h->callback_data = NULL;
+   else
+   fn = NULL;
+   }
+out:
+   if (fn)
+   fn(data, err);
+
+   return err;
+}
+
+/*
  * alua_initialize - Initialize ALUA state
  * @sdev: the device to be initialized
  *
@@ -655,7 +714,6 @@ static int alua_activate(struct scsi_device *sdev,
 {
struct alua_dh_data *h = sdev->handler_data;
int err = SCSI_DH_OK;
-   int stpg = 0;
 
err = alua_rtpg(sdev, h, 1);
if (err != SCSI_DH_OK)
@@ -664,41 +722,10 @@ static int alua_activate(struct scsi_device *sdev,
if (optimize_stpg)
h->flags |= ALUA_OPTIMIZE_STPG;
 
-   if (h->tpgs & TPGS_MODE_EXPLICIT) {
-   switch (h->state) {
-   case TPGS_STATE_NONOPTIMIZED:
-   stpg = 1;
-   if ((h->flags & ALUA_OPTIMIZE_STPG) &&
-   (!h->pref) &&
-   (h->tpgs & TPGS_MODE_IMPLICIT))
-   stpg = 0;
-   break;
-   case TPGS_STATE_STANDBY:
-   case TPGS_STATE_UNAVAILABLE:
-   stpg = 1;
-   break;
-   case TPGS_STATE_OFFLINE:
-   err = SCSI_DH_IO;
-   break;
-   case TPGS_STATE_TRANSITIONING:
-   err = SCSI_DH_RETRY;
-   break;
-   default:
-   break;
-   }
-   }
-
-   if (stpg) {
-   h->callback_fn = fn;
-   h->callback_data = data;
-   err = submit_stpg(h);
-   if (err == SCSI_DH_OK)
-   return 0;
-   h->callback_fn = h->callback_data = NULL;
-   }
+   err = alua_stpg(sdev, h, fn, data);
 
 out:
-   if (fn)
+   if (err != SCSI_DH_OK && fn)
fn(data, err);
return 0;
 }
-- 
1.8.5.6

--
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 12/23] scsi_dh_alua: remove 'rel_port' from alua_dh_data structure

[Hannes Reinecke]

The 'relative port' field is not used, and might get stale when
the port group changes. So remove the field altogether.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 64e07d7..4b115f2 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -87,7 +87,6 @@ struct alua_port_group {
 struct alua_dh_data {
struct alua_port_group  *pg;
int group_id;
-   int rel_port;
struct scsi_device  *sdev;
activate_complete   callback_fn;
void*callback_data;
@@ -325,12 +324,10 @@ static int alua_check_vpd(struct scsi_device *sdev, 
struct alua_dh_data *h,
return SCSI_DH_NOMEM;
return SCSI_DH_DEV_UNSUPP;
}
-   h->rel_port = rel_port;
-
sdev_printk(KERN_INFO, sdev,
"%s: device %s port group %x rel port %x\n",
ALUA_DH_NAME, h->pg->device_id_str,
-   h->group_id, h->rel_port);
+   h->group_id, rel_port);
 
return alua_rtpg(sdev, h->pg);
 }
@@ -764,7 +761,6 @@ static int alua_bus_attach(struct scsi_device *sdev)
if (!h)
return -ENOMEM;
h->pg = NULL;
-   h->rel_port = -1;
h->sdev = sdev;
 
err = alua_initialize(sdev, h);
-- 
1.8.5.6

--
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 11/23] scsi_dh_alua: move optimize_stpg evaluation

[Hannes Reinecke]

When the optimize_stpg module option is set we should just set it
once during port_group allocation. Doing so allows us to override
it later with device specific settings.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 9b47437..64e07d7 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -64,6 +64,10 @@
 #define ALUA_OPTIMIZE_STPG 1
 #define ALUA_RTPG_EXT_HDR_UNSUPP   2
 
+static uint optimize_stpg;
+module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(optimize_stpg, "Allow use of a non-optimized path, rather 
than sending a STPG, when implicit TPGS is supported (0=No,1=Yes). Default is 
0.");
+
 static LIST_HEAD(port_group_list);
 static DEFINE_SPINLOCK(port_group_lock);
 
@@ -219,6 +223,8 @@ struct alua_port_group *alua_alloc_pg(struct scsi_device 
*sdev,
pg->group_id = group_id;
pg->tpgs = tpgs;
pg->state = TPGS_STATE_OPTIMIZED;
+   if (optimize_stpg)
+   pg->flags |= ALUA_OPTIMIZE_STPG;
kref_init(>kref);
 
spin_lock(_group_lock);
@@ -680,10 +686,6 @@ static int alua_set_params(struct scsi_device *sdev, const 
char *params)
return result;
 }
 
-static uint optimize_stpg;
-module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(optimize_stpg, "Allow use of a non-optimized path, rather 
than sending a STPG, when implicit TPGS is supported (0=No,1=Yes). Default is 
0.");
-
 /*
  * alua_activate - activate a path
  * @sdev: device on the path to be activated
@@ -705,9 +707,6 @@ static int alua_activate(struct scsi_device *sdev,
 
kref_get(>pg->kref);
 
-   if (optimize_stpg)
-   h->pg->flags |= ALUA_OPTIMIZE_STPG;
-
err = alua_rtpg(sdev, h->pg);
if (err != SCSI_DH_OK) {
kref_put(>pg->kref, release_port_group);
-- 
1.8.5.6

--
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 06/23] scsi_dh_alua: allocate RTPG buffer separately

[Hannes Reinecke]

The RTPG buffer will only evaluated within alua_rtpg(),
so we can allocate it locally there and avoid having to
put it into the global structure.

Reviewed-by: Ewan Milne 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 57 --
 1 file changed, 23 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 699456c..666306d 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -56,7 +56,7 @@
 #define TPGS_MODE_IMPLICIT 0x1
 #define TPGS_MODE_EXPLICIT 0x2
 
-#define ALUA_INQUIRY_SIZE  36
+#define ALUA_RTPG_SIZE 128
 #define ALUA_FAILOVER_TIMEOUT  60
 #define ALUA_FAILOVER_RETRIES  5
 
@@ -71,9 +71,6 @@ struct alua_dh_data {
int state;
int pref;
unsignedflags; /* used for optimizing STPG */
-   unsigned char   inq[ALUA_INQUIRY_SIZE];
-   unsigned char   *buff;
-   int bufflen;
unsigned char   transition_tmo;
struct scsi_device  *sdev;
activate_complete   callback_fn;
@@ -85,21 +82,6 @@ struct alua_dh_data {
 
 static char print_alua_state(int);
 
-static int realloc_buffer(struct alua_dh_data *h, unsigned len)
-{
-   if (h->buff && h->buff != h->inq)
-   kfree(h->buff);
-
-   h->buff = kmalloc(len, GFP_NOIO);
-   if (!h->buff) {
-   h->buff = h->inq;
-   h->bufflen = ALUA_INQUIRY_SIZE;
-   return 1;
-   }
-   h->bufflen = len;
-   return 0;
-}
-
 /*
  * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
  * @sdev: sdev the command should be sent to
@@ -333,8 +315,8 @@ static int alua_check_sense(struct scsi_device *sdev,
 static int alua_rtpg(struct scsi_device *sdev, struct alua_dh_data *h, int 
wait_for_transition)
 {
struct scsi_sense_hdr sense_hdr;
-   int len, k, off, valid_states = 0;
-   unsigned char *ucp;
+   int len, k, off, valid_states = 0, bufflen = ALUA_RTPG_SIZE;
+   unsigned char *ucp, *buff;
unsigned err, retval;
unsigned long expiry, interval = 0;
unsigned int tpg_desc_tbl_off;
@@ -345,14 +327,19 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
else
expiry = round_jiffies_up(jiffies + h->transition_tmo * HZ);
 
+   buff = kzalloc(bufflen, GFP_KERNEL);
+   if (!buff)
+   return SCSI_DH_DEV_TEMP_BUSY;
+
  retry:
-   retval = submit_rtpg(sdev, h->buff, h->bufflen, _hdr, h->flags);
+   retval = submit_rtpg(sdev, buff, bufflen, _hdr, h->flags);
 
if (retval) {
if (!scsi_sense_valid(_hdr)) {
sdev_printk(KERN_INFO, sdev,
"%s: rtpg failed, result %d\n",
ALUA_DH_NAME, retval);
+   kfree(buff);
if (driver_byte(retval) == DRIVER_ERROR)
return SCSI_DH_DEV_TEMP_BUSY;
return SCSI_DH_IO;
@@ -390,14 +377,18 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
sdev_printk(KERN_ERR, sdev, "%s: rtpg failed\n",
ALUA_DH_NAME);
scsi_print_sense_hdr(sdev, ALUA_DH_NAME, _hdr);
+   kfree(buff);
return SCSI_DH_IO;
}
 
-   len = get_unaligned_be32(>buff[0]) + 4;
+   len = get_unaligned_be32([0]) + 4;
 
-   if (len > h->bufflen) {
+   if (len > bufflen) {
/* Resubmit with the correct length */
-   if (realloc_buffer(h, len)) {
+   kfree(buff);
+   bufflen = len;
+   buff = kmalloc(bufflen, GFP_KERNEL);
+   if (!buff) {
sdev_printk(KERN_WARNING, sdev,
"%s: kmalloc buffer failed\n",__func__);
/* Temporary failure, bypass */
@@ -407,24 +398,25 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
}
 
orig_transition_tmo = h->transition_tmo;
-   if ((h->buff[4] & RTPG_FMT_MASK) == RTPG_FMT_EXT_HDR && h->buff[5] != 0)
-   h->transition_tmo = h->buff[5];
+   if ((buff[4] & RTPG_FMT_MASK) == RTPG_FMT_EXT_HDR && buff[5] != 0)
+   h->transition_tmo = buff[5];
else
h->transition_tmo = ALUA_FAILOVER_TIMEOUT;
 
-   if (wait_for_transition && (orig_transition_tmo != h->transition_tmo)) {
+   if (wait_for_transition &&
+   (orig_transition_tmo != h->transition_tmo)) {

[PATCH 07/23] scsi_dh_alua: Use separate alua_port_group structure

[Hannes Reinecke]

The port group needs to be a separate structure as several
LUNs might belong to the same group.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Ewan Milne 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 181 -
 include/scsi/scsi_dh.h |   1 +
 2 files changed, 129 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 666306d..5c8d0d3 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -64,14 +64,24 @@
 #define ALUA_OPTIMIZE_STPG 1
 #define ALUA_RTPG_EXT_HDR_UNSUPP   2
 
-struct alua_dh_data {
+static LIST_HEAD(port_group_list);
+static DEFINE_SPINLOCK(port_group_lock);
+
+struct alua_port_group {
+   struct kref kref;
+   struct list_headnode;
int group_id;
-   int rel_port;
int tpgs;
int state;
int pref;
unsignedflags; /* used for optimizing STPG */
unsigned char   transition_tmo;
+};
+
+struct alua_dh_data {
+   struct alua_port_group  *pg;
+   int group_id;
+   int rel_port;
struct scsi_device  *sdev;
activate_complete   callback_fn;
void*callback_data;
@@ -82,6 +92,17 @@ struct alua_dh_data {
 
 static char print_alua_state(int);
 
+static void release_port_group(struct kref *kref)
+{
+   struct alua_port_group *pg;
+
+   pg = container_of(kref, struct alua_port_group, kref);
+   spin_lock(_group_lock);
+   list_del(>node);
+   spin_unlock(_group_lock);
+   kfree(pg);
+}
+
 /*
  * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
  * @sdev: sdev the command should be sent to
@@ -142,6 +163,35 @@ static int submit_stpg(struct scsi_device *sdev, int 
group_id,
 }
 
 /*
+ * alua_alloc_pg - Allocate a new port_group structure
+ * @sdev: scsi device
+ * @h: alua device_handler data
+ * @group_id: port group id
+ *
+ * Allocate a new port_group structure for a given
+ * device.
+ */
+struct alua_port_group *alua_alloc_pg(struct scsi_device *sdev,
+ int group_id, int tpgs)
+{
+   struct alua_port_group *pg;
+
+   pg = kzalloc(sizeof(struct alua_port_group), GFP_KERNEL);
+   if (!pg)
+   return NULL;
+
+   pg->group_id = group_id;
+   pg->tpgs = tpgs;
+   pg->state = TPGS_STATE_OPTIMIZED;
+   kref_init(>kref);
+   spin_lock(_group_lock);
+   list_add(>node, _group_list);
+   spin_unlock(_group_lock);
+
+   return pg;
+}
+
+/*
  * alua_check_tpgs - Evaluate TPGS setting
  * @sdev: device to be checked
  *
@@ -216,7 +266,6 @@ static int alua_check_vpd(struct scsi_device *sdev, struct 
alua_dh_data *h)
ALUA_DH_NAME);
return SCSI_DH_DEV_UNSUPP;
}
-   h->state = TPGS_STATE_OPTIMIZED;
h->group_id = group_id;
 
sdev_printk(KERN_INFO, sdev,
@@ -312,7 +361,7 @@ static int alua_check_sense(struct scsi_device *sdev,
  * Returns SCSI_DH_DEV_OFFLINED if the path is
  * found to be unusable.
  */
-static int alua_rtpg(struct scsi_device *sdev, struct alua_dh_data *h, int 
wait_for_transition)
+static int alua_rtpg(struct scsi_device *sdev, struct alua_port_group *pg, int 
wait_for_transition)
 {
struct scsi_sense_hdr sense_hdr;
int len, k, off, valid_states = 0, bufflen = ALUA_RTPG_SIZE;
@@ -322,17 +371,17 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
unsigned int tpg_desc_tbl_off;
unsigned char orig_transition_tmo;
 
-   if (!h->transition_tmo)
+   if (!pg->transition_tmo)
expiry = round_jiffies_up(jiffies + ALUA_FAILOVER_TIMEOUT * HZ);
else
-   expiry = round_jiffies_up(jiffies + h->transition_tmo * HZ);
+   expiry = round_jiffies_up(jiffies + pg->transition_tmo * HZ);
 
buff = kzalloc(bufflen, GFP_KERNEL);
if (!buff)
return SCSI_DH_DEV_TEMP_BUSY;
 
  retry:
-   retval = submit_rtpg(sdev, buff, bufflen, _hdr, h->flags);
+   retval = submit_rtpg(sdev, buff, bufflen, _hdr, pg->flags);
 
if (retval) {
if (!scsi_sense_valid(_hdr)) {
@@ -353,10 +402,10 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
 * The retry without rtpg_ext_hdr_req set
 * handles this.
 */
-   if (!(h->flags & ALUA_RTPG_EXT_HDR_UNSUPP) &&
+   if (!(pg->flags & ALUA_RTPG_EXT_HDR_UNSUPP) &&
sense_hdr.sense_key == ILLEGAL_REQUEST &&
sense_hdr.asc == 

[PATCH 03/23] scsi_dh_alua: Make stpg synchronous

[Hannes Reinecke]

The 'activate_complete' function needs to be executed after
stpg has finished, so we can as well execute stpg synchronously
and call the function directly.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 154 ++---
 1 file changed, 53 insertions(+), 101 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 7c66e4a..584e1cf 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -169,81 +169,28 @@ done:
 }
 
 /*
- * stpg_endio - Evaluate SET TARGET GROUP STATES
- * @sdev: the device to be evaluated
- * @state: the new target group state
- *
- * Evaluate a SET TARGET GROUP STATES command response.
- */
-static void stpg_endio(struct request *req, int error)
-{
-   struct alua_dh_data *h = req->end_io_data;
-   struct scsi_sense_hdr sense_hdr;
-   unsigned err = SCSI_DH_OK;
-
-   if (host_byte(req->errors) != DID_OK ||
-   msg_byte(req->errors) != COMMAND_COMPLETE) {
-   err = SCSI_DH_IO;
-   goto done;
-   }
-
-   if (scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE,
-_hdr)) {
-   if (sense_hdr.sense_key == NOT_READY &&
-   sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a) {
-   /* ALUA state transition already in progress */
-   err = SCSI_DH_OK;
-   goto done;
-   }
-   if (sense_hdr.sense_key == UNIT_ATTENTION) {
-   err = SCSI_DH_RETRY;
-   goto done;
-   }
-   sdev_printk(KERN_INFO, h->sdev, "%s: stpg failed\n",
-   ALUA_DH_NAME);
-   scsi_print_sense_hdr(h->sdev, ALUA_DH_NAME, _hdr);
-   err = SCSI_DH_IO;
-   } else if (error)
-   err = SCSI_DH_IO;
-
-   if (err == SCSI_DH_OK) {
-   h->state = TPGS_STATE_OPTIMIZED;
-   sdev_printk(KERN_INFO, h->sdev,
-   "%s: port group %02x switched to state %c\n",
-   ALUA_DH_NAME, h->group_id,
-   print_alua_state(h->state));
-   }
-done:
-   req->end_io_data = NULL;
-   __blk_put_request(req->q, req);
-   if (h->callback_fn) {
-   h->callback_fn(h->callback_data, err);
-   h->callback_fn = h->callback_data = NULL;
-   }
-   return;
-}
-
-/*
  * submit_stpg - Issue a SET TARGET GROUP STATES command
  *
  * Currently we're only setting the current target port group state
  * to 'active/optimized' and let the array firmware figure out
  * the states of the remaining groups.
  */
-static unsigned submit_stpg(struct alua_dh_data *h)
+static unsigned submit_stpg(struct scsi_device *sdev, int group_id,
+   unsigned char *sense)
 {
struct request *rq;
+   unsigned char stpg_data[8];
int stpg_len = 8;
-   struct scsi_device *sdev = h->sdev;
+   int err = 0;
 
/* Prepare the data buffer */
-   memset(h->buff, 0, stpg_len);
-   h->buff[4] = TPGS_STATE_OPTIMIZED & 0x0f;
-   put_unaligned_be16(h->group_id, >buff[6]);
+   memset(stpg_data, 0, stpg_len);
+   stpg_data[4] = TPGS_STATE_OPTIMIZED & 0x0f;
+   put_unaligned_be16(group_id, _data[6]);
 
-   rq = get_alua_req(sdev, h->buff, stpg_len, WRITE);
+   rq = get_alua_req(sdev, stpg_data, stpg_len, WRITE);
if (!rq)
-   return SCSI_DH_RES_TEMP_UNAVAIL;
+   return DRIVER_BUSY << 24;
 
/* Prepare the command. */
rq->cmd[0] = MAINTENANCE_OUT;
@@ -251,13 +198,17 @@ static unsigned submit_stpg(struct alua_dh_data *h)
put_unaligned_be32(stpg_len, >cmd[6]);
rq->cmd_len = COMMAND_SIZE(MAINTENANCE_OUT);
 
-   rq->sense = h->sense;
+   rq->sense = sense;
memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
rq->sense_len = 0;
-   rq->end_io_data = h;
 
-   blk_execute_rq_nowait(rq->q, NULL, rq, 1, stpg_endio);
-   return SCSI_DH_OK;
+   blk_execute_rq(rq->q, NULL, rq, 1);
+   if (rq->errors)
+   err = rq->errors;
+
+   blk_put_request(rq);
+
+   return err;
 }
 
 /*
@@ -582,59 +533,61 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
  * alua_stpg - Issue a SET TARGET GROUP STATES command
  *
  * Issue a SET TARGET GROUP STATES command and evaluate the
- * response. Returns SCSI_DH_RETRY if the target port group
- * state is found to be in 'transitioning'.
- * If SCSI_DH_OK is returned the passed-in 'fn' function
- * this function will take care of executing 'fn'.
- * Otherwise 'fn' should be executed by the caller with the
- * returned error code.
+ * response. Returns SCSI_DH_RETRY per default 

[PATCH 19/23] scsi_dh: add 'rescan' callback

[Hannes Reinecke]

If a device needs to be rescanned the device_handler might need
to be rechecked, too.
So add a 'rescan' callback to the device handler and call it
upon scsi_rescan_device().

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 8 
 drivers/scsi/scsi_lib.c| 1 +
 drivers/scsi/scsi_scan.c   | 8 +++-
 include/scsi/scsi_dh.h | 1 +
 4 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index a1db82f..56f8d21 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1038,6 +1038,13 @@ static int alua_prep_fn(struct scsi_device *sdev, struct 
request *req)
 
 }
 
+static void alua_rescan(struct scsi_device *sdev)
+{
+   struct alua_dh_data *h = sdev->handler_data;
+
+   alua_initialize(sdev, h);
+}
+
 /*
  * alua_bus_attach - Attach device handler
  * @sdev: device to be attached to
@@ -1098,6 +1105,7 @@ static struct scsi_device_handler alua_dh = {
.prep_fn = alua_prep_fn,
.check_sense = alua_check_sense,
.activate = alua_activate,
+   .rescan = alua_rescan,
.set_params = alua_set_params,
 };
 
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index fa6b2c4..d46193a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2699,6 +2699,7 @@ static void scsi_evt_emit(struct scsi_device *sdev, 
struct scsi_event *evt)
envp[idx++] = "SDEV_MEDIA_CHANGE=1";
break;
case SDEV_EVT_INQUIRY_CHANGE_REPORTED:
+   scsi_rescan_device(>sdev_gendev);
envp[idx++] = "SDEV_UA=INQUIRY_DATA_HAS_CHANGED";
break;
case SDEV_EVT_CAPACITY_CHANGE_REPORTED:
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 420239c..97074c9 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "scsi_priv.h"
@@ -1524,9 +1525,14 @@ EXPORT_SYMBOL(scsi_add_device);
 
 void scsi_rescan_device(struct device *dev)
 {
+   struct scsi_device *sdev = to_scsi_device(dev);
+
device_lock(dev);
 
-   scsi_attach_vpd(to_scsi_device(dev));
+   scsi_attach_vpd(sdev);
+
+   if (sdev->handler && sdev->handler->rescan)
+   sdev->handler->rescan(sdev);
 
if (dev->driver && try_module_get(dev->driver->owner)) {
struct scsi_driver *drv = to_scsi_driver(dev->driver);
diff --git a/include/scsi/scsi_dh.h b/include/scsi/scsi_dh.h
index 7e184c6..c7bba2b 100644
--- a/include/scsi/scsi_dh.h
+++ b/include/scsi/scsi_dh.h
@@ -71,6 +71,7 @@ struct scsi_device_handler {
int (*activate)(struct scsi_device *, activate_complete, void *);
int (*prep_fn)(struct scsi_device *, struct request *);
int (*set_params)(struct scsi_device *, const char *);
+   void (*rescan)(struct scsi_device *);
 };
 
 #ifdef CONFIG_SCSI_DH
-- 
1.8.5.6

--
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 20/23] scsi: Add 'access_state' attribute

[Hannes Reinecke]

Add an 'access_state' attribute to struct scsi_device to
display the asymmetric LUN access state.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/scsi_scan.c   |  1 +
 drivers/scsi/scsi_sysfs.c  | 49 ++
 include/scsi/scsi_device.h |  1 +
 include/scsi/scsi_proto.h  | 13 
 4 files changed, 64 insertions(+)

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 97074c9..5bf3945 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -231,6 +231,7 @@ static struct scsi_device *scsi_alloc_sdev(struct 
scsi_target *starget,
sdev->lun = lun;
sdev->channel = starget->channel;
sdev->sdev_state = SDEV_CREATED;
+   sdev->access_state = SCSI_ACCESS_STATE_UNKNOWN;
INIT_LIST_HEAD(>siblings);
INIT_LIST_HEAD(>same_target_siblings);
INIT_LIST_HEAD(>cmd_list);
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 4f18a85..8d154ed 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -81,6 +81,34 @@ const char *scsi_host_state_name(enum scsi_host_state state)
return name;
 }
 
+static const struct {
+   enum scsi_access_state  value;
+   char*name;
+} sdev_access_states[] = {
+   { SCSI_ACCESS_STATE_OPTIMAL, "active/optimized" },
+   { SCSI_ACCESS_STATE_ACTIVE, "active/non-optimized" },
+   { SCSI_ACCESS_STATE_STANDBY, "standby" },
+   { SCSI_ACCESS_STATE_UNAVAILABLE, "unavailable" },
+   { SCSI_ACCESS_STATE_LBA, "lba-dependent" },
+   { SCSI_ACCESS_STATE_OFFLINE, "offline" },
+   { SCSI_ACCESS_STATE_TRANSITIONING, "transitioning" },
+   { SCSI_ACCESS_STATE_UNKNOWN, "unknown" },
+};
+
+const char *scsi_access_state_name(enum scsi_access_state state)
+{
+   int i;
+   char *name = NULL;
+
+   for (i = 0; i < ARRAY_SIZE(sdev_access_states); i++) {
+   if (sdev_access_states[i].value == state) {
+   name = sdev_access_states[i].name;
+   break;
+   }
+   }
+   return name;
+}
+
 static int check_set(unsigned long long *val, char *src)
 {
char *last;
@@ -973,6 +1001,26 @@ sdev_store_dh_state(struct device *dev, struct 
device_attribute *attr,
 
 static DEVICE_ATTR(dh_state, S_IRUGO | S_IWUSR, sdev_show_dh_state,
   sdev_store_dh_state);
+
+static ssize_t
+sdev_show_access_state(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct scsi_device *sdev = to_scsi_device(dev);
+   enum scsi_access_state access_state;
+   bool pref = false;
+
+   if (sdev->access_state & SCSI_ACCESS_STATE_PREFERRED)
+   pref = true;
+
+   access_state = (sdev->access_state & SCSI_ACCESS_STATE_MASK);
+
+   return snprintf(buf, 32, "%s%s\n",
+   scsi_access_state_name(access_state),
+   pref ? " preferred" : "");
+}
+static DEVICE_ATTR(access_state, S_IRUGO, sdev_show_access_state, NULL);
 #endif
 
 static ssize_t
@@ -1047,6 +1095,7 @@ static struct attribute *scsi_sdev_attrs[] = {
_attr_wwid.attr,
 #ifdef CONFIG_SCSI_DH
_attr_dh_state.attr,
+   _attr_access_state.attr,
 #endif
_attr_queue_ramp_up_period.attr,
REF_EVT(media_change),
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 4af2b24..af16a0d 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -201,6 +201,7 @@ struct scsi_device {
struct scsi_device_handler *handler;
void*handler_data;
 
+   enum scsi_access_state  access_state;
enum scsi_device_state sdev_state;
unsigned long   sdev_data[0];
 } __attribute__((aligned(sizeof(unsigned long;
diff --git a/include/scsi/scsi_proto.h b/include/scsi/scsi_proto.h
index a9fbf1b..80e85e7 100644
--- a/include/scsi/scsi_proto.h
+++ b/include/scsi/scsi_proto.h
@@ -277,5 +277,18 @@ struct scsi_lun {
__u8 scsi_lun[8];
 };
 
+/* SPC asymmetric access states */
+enum scsi_access_state {
+   SCSI_ACCESS_STATE_OPTIMAL = 0,
+   SCSI_ACCESS_STATE_ACTIVE,
+   SCSI_ACCESS_STATE_STANDBY,
+   SCSI_ACCESS_STATE_UNAVAILABLE,
+   SCSI_ACCESS_STATE_LBA,
+   SCSI_ACCESS_STATE_OFFLINE = 0xe,
+   SCSI_ACCESS_STATE_TRANSITIONING = 0xf,
+   SCSI_ACCESS_STATE_UNKNOWN = 0x70,
+};
+#define SCSI_ACCESS_STATE_MASK 0x0f
+#define SCSI_ACCESS_STATE_PREFERRED 0x80
 
 #endif /* _SCSI_PROTO_H_ */
-- 
1.8.5.6

--
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 05/23] scsi_dh_alua: switch to scsi_execute_req_flags()

[Hannes Reinecke]

All commands are issued synchronously, so no need to open-code
scsi_execute_req_flags() anymore. And we can get rid of the
static sense code structure element. scsi_execute_req_flags()
will be setting REQ_QUIET and REQ_PREEMPT, but that is
perfectly fine as we're evaluating and logging any errors
ourselves and we really need to send the command even if
the device is quiesced.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Ewan Milne 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 125 +
 1 file changed, 36 insertions(+), 89 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 78cccad..699456c 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -75,7 +75,6 @@ struct alua_dh_data {
unsigned char   *buff;
int bufflen;
unsigned char   transition_tmo;
-   unsigned char   sense[SCSI_SENSE_BUFFERSIZE];
struct scsi_device  *sdev;
activate_complete   callback_fn;
void*callback_data;
@@ -101,71 +100,30 @@ static int realloc_buffer(struct alua_dh_data *h, 
unsigned len)
return 0;
 }
 
-static struct request *get_alua_req(struct scsi_device *sdev,
-   void *buffer, unsigned buflen, int rw)
-{
-   struct request *rq;
-   struct request_queue *q = sdev->request_queue;
-
-   rq = blk_get_request(q, rw, GFP_NOIO);
-
-   if (IS_ERR(rq)) {
-   sdev_printk(KERN_INFO, sdev,
-   "%s: blk_get_request failed\n", __func__);
-   return NULL;
-   }
-   blk_rq_set_block_pc(rq);
-
-   if (buflen && blk_rq_map_kern(q, rq, buffer, buflen, GFP_NOIO)) {
-   blk_put_request(rq);
-   sdev_printk(KERN_INFO, sdev,
-   "%s: blk_rq_map_kern failed\n", __func__);
-   return NULL;
-   }
-
-   rq->cmd_flags |= REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT |
-REQ_FAILFAST_DRIVER;
-   rq->retries = ALUA_FAILOVER_RETRIES;
-   rq->timeout = ALUA_FAILOVER_TIMEOUT * HZ;
-
-   return rq;
-}
-
 /*
  * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
  * @sdev: sdev the command should be sent to
  */
-static unsigned submit_rtpg(struct scsi_device *sdev, unsigned char *buff,
-   int bufflen, unsigned char *sense, int flags)
+static int submit_rtpg(struct scsi_device *sdev, unsigned char *buff,
+  int bufflen, struct scsi_sense_hdr *sshdr, int flags)
 {
-   struct request *rq;
-   int err = 0;
-
-   rq = get_alua_req(sdev, buff, bufflen, READ);
-   if (!rq) {
-   err = DRIVER_BUSY << 24;
-   goto done;
-   }
+   u8 cdb[COMMAND_SIZE(MAINTENANCE_IN)];
+   int req_flags = REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT |
+   REQ_FAILFAST_DRIVER;
 
/* Prepare the command. */
-   rq->cmd[0] = MAINTENANCE_IN;
+   memset(cdb, 0x0, COMMAND_SIZE(MAINTENANCE_IN));
+   cdb[0] = MAINTENANCE_IN;
if (!(flags & ALUA_RTPG_EXT_HDR_UNSUPP))
-   rq->cmd[1] = MI_REPORT_TARGET_PGS | MI_EXT_HDR_PARAM_FMT;
+   cdb[1] = MI_REPORT_TARGET_PGS | MI_EXT_HDR_PARAM_FMT;
else
-   rq->cmd[1] = MI_REPORT_TARGET_PGS;
-   put_unaligned_be32(bufflen, >cmd[6]);
-   rq->cmd_len = COMMAND_SIZE(MAINTENANCE_IN);
-
-   rq->sense = sense;
-   memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
-   rq->sense_len = 0;
-
-   blk_execute_rq(rq->q, NULL, rq, 1);
-   if (rq->errors)
-   err = rq->errors;
-   blk_put_request(rq);
-done:
-   return err;
+   cdb[1] = MI_REPORT_TARGET_PGS;
+   put_unaligned_be32(bufflen, [6]);
+
+   return scsi_execute_req_flags(sdev, cdb, DMA_FROM_DEVICE,
+ buff, bufflen, sshdr,
+ ALUA_FAILOVER_TIMEOUT * HZ,
+ ALUA_FAILOVER_RETRIES, NULL, req_flags);
 }
 
 /*
@@ -175,40 +133,30 @@ done:
  * to 'active/optimized' and let the array firmware figure out
  * the states of the remaining groups.
  */
-static unsigned submit_stpg(struct scsi_device *sdev, int group_id,
-   unsigned char *sense)
+static int submit_stpg(struct scsi_device *sdev, int group_id,
+  struct scsi_sense_hdr *sshdr)
 {
-   struct request *rq;
+   u8 cdb[COMMAND_SIZE(MAINTENANCE_OUT)];
unsigned char stpg_data[8];
int stpg_len = 8;
-   int err = 0;
+   int req_flags = REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT |
+   REQ_FAILFAST_DRIVER;
 
/* Prepare the data buffer */
memset(stpg_data, 0, stpg_len);

[PATCH 23/23] scsi_dh_alua: Update version to 2.0

[Hannes Reinecke]

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 7bcc075..05addb9 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -30,7 +30,7 @@
 #include 
 
 #define ALUA_DH_NAME "alua"
-#define ALUA_DH_VER "1.3"
+#define ALUA_DH_VER "2.0"
 
 #define TPGS_SUPPORT_NONE  0x00
 #define TPGS_SUPPORT_OPTIMIZED 0x01
-- 
1.8.5.6

--
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 16/23] scsi_dh_alua: Recheck state on unit attention

[Hannes Reinecke]

When we receive a unit attention code of 'ALUA state changed'
we should recheck the state, as it might be due to an implicit
ALUA state transition. This allows us to return NEEDS_RETRY
instead of ADD_TO_MLQUEUE, allowing to terminate the retries
after a certain time.
At the same time a workqueue item might already be queued, which
should be started immediately to avoid any delays.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 76 +-
 1 file changed, 64 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index f6bb1c0..8a896af 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -120,7 +120,8 @@ struct alua_queue_data {
 static void alua_rtpg_work(struct work_struct *work);
 static void alua_rtpg_queue(struct alua_port_group *pg,
struct scsi_device *sdev,
-   struct alua_queue_data *qdata);
+   struct alua_queue_data *qdata, bool force);
+static void alua_check(struct scsi_device *sdev, bool force);
 
 static void release_port_group(struct kref *kref)
 {
@@ -368,7 +369,7 @@ static int alua_check_vpd(struct scsi_device *sdev, struct 
alua_dh_data *h,
}
if (sdev->synchronous_alua)
pg->flags |= ALUA_SYNC_STPG;
-   alua_rtpg_queue(h->pg, sdev, NULL);
+   alua_rtpg_queue(h->pg, sdev, NULL, true);
spin_unlock(>pg_lock);
 
if (old_pg)
@@ -404,18 +405,24 @@ static int alua_check_sense(struct scsi_device *sdev,
 {
switch (sense_hdr->sense_key) {
case NOT_READY:
-   if (sense_hdr->asc == 0x04 && sense_hdr->ascq == 0x0a)
+   if (sense_hdr->asc == 0x04 && sense_hdr->ascq == 0x0a) {
/*
 * LUN Not Accessible - ALUA state transition
 */
-   return ADD_TO_MLQUEUE;
+   alua_check(sdev, false);
+   return NEEDS_RETRY;
+   }
break;
case UNIT_ATTENTION:
-   if (sense_hdr->asc == 0x29 && sense_hdr->ascq == 0x00)
+   if (sense_hdr->asc == 0x29 && sense_hdr->ascq == 0x00) {
/*
-* Power On, Reset, or Bus Device Reset, just retry.
+* Power On, Reset, or Bus Device Reset.
+* Might have obscured a state transition,
+* so schedule a recheck.
 */
+   alua_check(sdev, true);
return ADD_TO_MLQUEUE;
+   }
if (sense_hdr->asc == 0x29 && sense_hdr->ascq == 0x04)
/*
 * Device internal reset
@@ -426,16 +433,20 @@ static int alua_check_sense(struct scsi_device *sdev,
 * Mode Parameters Changed
 */
return ADD_TO_MLQUEUE;
-   if (sense_hdr->asc == 0x2a && sense_hdr->ascq == 0x06)
+   if (sense_hdr->asc == 0x2a && sense_hdr->ascq == 0x06) {
/*
 * ALUA state changed
 */
+   alua_check(sdev, true);
return ADD_TO_MLQUEUE;
-   if (sense_hdr->asc == 0x2a && sense_hdr->ascq == 0x07)
+   }
+   if (sense_hdr->asc == 0x2a && sense_hdr->ascq == 0x07) {
/*
 * Implicit ALUA state transition failed
 */
+   alua_check(sdev, true);
return ADD_TO_MLQUEUE;
+   }
if (sense_hdr->asc == 0x3f && sense_hdr->ascq == 0x03)
/*
 * Inquiry data has changed
@@ -710,7 +721,7 @@ static void alua_rtpg_work(struct work_struct *work)
spin_unlock_irqrestore(>lock, flags);
err = alua_rtpg(sdev, pg);
spin_lock_irqsave(>lock, flags);
-   if (err == SCSI_DH_RETRY) {
+   if (err == SCSI_DH_RETRY || pg->flags & ALUA_PG_RUN_RTPG) {
pg->flags &= ~ALUA_PG_RUNNING;
pg->flags |= ALUA_PG_RUN_RTPG;
spin_unlock_irqrestore(>lock, flags);
@@ -726,7 +737,7 @@ static void alua_rtpg_work(struct work_struct *work)
spin_unlock_irqrestore(>lock, flags);
err = alua_stpg(sdev, pg);
spin_lock_irqsave(>lock, flags);
-   if (err == SCSI_DH_RETRY) {
+   if (err == SCSI_DH_RETRY || pg->flags & ALUA_PG_RUN_RTPG) {
pg->flags |= ALUA_PG_RUN_RTPG;

Re: [PATCH 3/3] add support for DWC UFS Host Controller

[Joao Pinto]

Hi Mark and Arnd,

I am planning the v2 of this patch set. I have a doubt in the version
compatibility strings... The core driver must support the UFS 2.0 controller and
this patch set includes a patch that adds 2.0 capabilities to it. The core
driver can get from the controller's version and with that use or not a specific
2.0 feature.

What would be the real added-value of having a compatibility string like
"snps,ufshcd-1.1" and "snps,ufshcd-2.0" if the driver can perform as 2.0 if it
detects a 2.0 controller? Are you saying that a user that puts "snps,ufshcd-1.1"
in the DT compatibility string disables the UFS 2.0 in the core driver despite
the controller is 2.0? Please clarify.

Thanks,
Joao

On 2/4/2016 4:27 PM, Mark Rutland wrote:
> On Wed, Feb 03, 2016 at 03:54:48PM +, Joao Pinto wrote:
>> Hi,
>>
>> On 2/3/2016 3:39 PM, Arnd Bergmann wrote:
>>> On Wednesday 03 February 2016 15:01:34 Joao Pinto wrote:

 Hi Arnd,

 On 2/3/2016 12:54 PM, Arnd Bergmann wrote:
> On Wednesday 03 February 2016 11:28:26 Joao Pinto wrote:
>>
>> Signed-off-by: Joao Pinto 
>
> This needs a changelog comment, like every patch.
>
>> @@ -0,0 +1,16 @@
>> +* Universal Flash Storage (UFS) DesignWare Host Controller
>> +
>> +DWC_UFSHC nodes are defined to describe on-chip UFS host controllers.
>> +Each UFS controller instance should have its own node.
>> +
>> +Required properties:
>> +- compatible: compatible list, contains "snps,ufshcd"
>
> Are there multiple versions of this controller? Usually for designware
> parts the version is known, so we should document which versions exist

 This controller recent releases was 2.0, but we released last year 1.1. The
 driver works with both. The driver must work with all DWC UFS versions.
>>>
>>> Ok, then make the driver match on the "snps,ufshcd-1.1" compatible
>>> string, but document both strings in the binding document, and make
>>> it mandatory to specify the 1.1 version as a compatible fallback.
>>>
>>> If we ever need to handle a quirk for the 2.0 version then, it can
>>> easily be done.
>>
>> We need the driver to support UFS 2.0 because it is our latest release and is
>> the done that Synopsys is focused now. We could call it "snps, ufshcd-2.0" 
>> then.
>> What do you think?
> 
> Arnd's point was that the driver can handle only "snps,ufshcd-1.1" for
> now, and in your DT you can have:
> 
>   compatible = "snps,ufshcd-2.0", "snps,ufshcd-1.1";
> 
> That allows driver to handle 2.0 and 1.1 without knowing anything about
> 2.0 for now. If in future the two need to be handled differently we can
> update the driver to explicitly match "snps,ufshcd-2.0".
> 
> Regardless, both compatible string should go in the documentation, and
> it should be explicitly mentioned that "snps,ufshcd-1.1" should be used
> as a fallback entry.
> 
> Mark.
> 

--
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 17/23] scsi_dh_alua: update all port states

[Hannes Reinecke]

When we read in the target port group state we should be
updating all affected port groups, otherwise we risk
running out of sync.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 36 ++
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 8a896af..de8e79e 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -476,11 +476,13 @@ static int alua_check_sense(struct scsi_device *sdev,
 static int alua_rtpg(struct scsi_device *sdev, struct alua_port_group *pg)
 {
struct scsi_sense_hdr sense_hdr;
+   struct alua_port_group *tmp_pg;
int len, k, off, valid_states = 0, bufflen = ALUA_RTPG_SIZE;
-   unsigned char *ucp, *buff;
+   unsigned char *desc, *buff;
unsigned err, retval;
unsigned int tpg_desc_tbl_off;
unsigned char orig_transition_tmo;
+   unsigned long flags;
 
if (!pg->expiry) {
unsigned long transition_tmo = ALUA_FAILOVER_TIMEOUT * HZ;
@@ -582,18 +584,33 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_port_group *pg)
else
tpg_desc_tbl_off = 4;
 
-   for (k = tpg_desc_tbl_off, ucp = buff + tpg_desc_tbl_off;
+   for (k = tpg_desc_tbl_off, desc = buff + tpg_desc_tbl_off;
 k < len;
-k += off, ucp += off) {
-
-   if (pg->group_id == get_unaligned_be16([2])) {
-   pg->state = ucp[0] & 0x0f;
-   pg->pref = ucp[0] >> 7;
-   valid_states = ucp[1];
+k += off, desc += off) {
+   u16 group_id = get_unaligned_be16([2]);
+
+   spin_lock_irqsave(_group_lock, flags);
+   tmp_pg = alua_find_get_pg(pg->device_id_str, pg->device_id_len,
+ group_id);
+   spin_unlock_irqrestore(_group_lock, flags);
+   if (tmp_pg) {
+   if (spin_trylock_irqsave(_pg->lock, flags)) {
+   if ((tmp_pg == pg) ||
+   !(tmp_pg->flags & ALUA_PG_RUNNING)) {
+   tmp_pg->state = desc[0] & 0x0f;
+   tmp_pg->pref = desc[0] >> 7;
+   }
+   if (tmp_pg == pg)
+   valid_states = desc[1];
+   spin_unlock_irqrestore(_pg->lock, flags);
+   }
+   kref_put(_pg->kref, release_port_group);
}
-   off = 8 + (ucp[7] * 4);
+   spin_unlock_irqrestore(_group_lock, flags);
+   off = 8 + (desc[7] * 4);
}
 
+   spin_lock_irqsave(>lock, flags);
sdev_printk(KERN_INFO, sdev,
"%s: port group %02x state %c %s supports %c%c%c%c%c%c%c\n",
ALUA_DH_NAME, pg->group_id, print_alua_state(pg->state),
@@ -630,6 +647,7 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_port_group *pg)
pg->expiry = 0;
break;
}
+   spin_unlock_irqrestore(>lock, flags);
kfree(buff);
return err;
 }
-- 
1.8.5.6

--
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 21/23] scsi_dh_alua: use common definitions for ALUA state

[Hannes Reinecke]

scsi_proto.h now contains definitions for the ALUA state,
so we don't have to carry them in the device handler.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 58 +-
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 56f8d21..51126b78 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -31,14 +31,6 @@
 #define ALUA_DH_NAME "alua"
 #define ALUA_DH_VER "1.3"
 
-#define TPGS_STATE_OPTIMIZED   0x0
-#define TPGS_STATE_NONOPTIMIZED0x1
-#define TPGS_STATE_STANDBY 0x2
-#define TPGS_STATE_UNAVAILABLE 0x3
-#define TPGS_STATE_LBA_DEPENDENT   0x4
-#define TPGS_STATE_OFFLINE 0xe
-#define TPGS_STATE_TRANSITIONING   0xf
-
 #define TPGS_SUPPORT_NONE  0x00
 #define TPGS_SUPPORT_OPTIMIZED 0x01
 #define TPGS_SUPPORT_NONOPTIMIZED  0x02
@@ -180,7 +172,7 @@ static int submit_stpg(struct scsi_device *sdev, int 
group_id,
 
/* Prepare the data buffer */
memset(stpg_data, 0, stpg_len);
-   stpg_data[4] = TPGS_STATE_OPTIMIZED & 0x0f;
+   stpg_data[4] = SCSI_ACCESS_STATE_OPTIMAL & 0x0f;
put_unaligned_be16(group_id, _data[6]);
 
/* Prepare the command. */
@@ -248,7 +240,7 @@ struct alua_port_group *alua_alloc_pg(struct scsi_device 
*sdev,
}
pg->group_id = group_id;
pg->tpgs = tpgs;
-   pg->state = TPGS_STATE_OPTIMIZED;
+   pg->state = SCSI_ACCESS_STATE_OPTIMAL;
if (optimize_stpg)
pg->flags |= ALUA_OPTIMIZE_STPG;
kref_init(>kref);
@@ -378,22 +370,22 @@ static int alua_check_vpd(struct scsi_device *sdev, 
struct alua_dh_data *h,
return SCSI_DH_OK;
 }
 
-static char print_alua_state(int state)
+static char print_alua_state(enum scsi_access_state state)
 {
switch (state) {
-   case TPGS_STATE_OPTIMIZED:
+   case SCSI_ACCESS_STATE_OPTIMAL:
return 'A';
-   case TPGS_STATE_NONOPTIMIZED:
+   case SCSI_ACCESS_STATE_ACTIVE:
return 'N';
-   case TPGS_STATE_STANDBY:
+   case SCSI_ACCESS_STATE_STANDBY:
return 'S';
-   case TPGS_STATE_UNAVAILABLE:
+   case SCSI_ACCESS_STATE_UNAVAILABLE:
return 'U';
-   case TPGS_STATE_LBA_DEPENDENT:
+   case SCSI_ACCESS_STATE_LBA:
return 'L';
-   case TPGS_STATE_OFFLINE:
+   case SCSI_ACCESS_STATE_OFFLINE:
return 'O';
-   case TPGS_STATE_TRANSITIONING:
+   case SCSI_ACCESS_STATE_TRANSITIONING:
return 'T';
default:
return 'X';
@@ -648,7 +640,7 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_port_group *pg)
valid_states_SUPPORT_OPTIMIZED?'A':'a');
 
switch (pg->state) {
-   case TPGS_STATE_TRANSITIONING:
+   case SCSI_ACCESS_STATE_TRANSITIONING:
if (time_before(jiffies, pg->expiry)) {
/* State transition, retry */
pg->interval = 2;
@@ -656,11 +648,11 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_port_group *pg)
} else {
/* Transitioning time exceeded, set port to standby */
err = SCSI_DH_IO;
-   pg->state = TPGS_STATE_STANDBY;
+   pg->state = SCSI_ACCESS_STATE_STANDBY;
pg->expiry = 0;
}
break;
-   case TPGS_STATE_OFFLINE:
+   case SCSI_ACCESS_STATE_OFFLINE:
/* Path unusable */
err = SCSI_DH_DEV_OFFLINED;
pg->expiry = 0;
@@ -694,21 +686,21 @@ static unsigned alua_stpg(struct scsi_device *sdev, 
struct alua_port_group *pg)
return SCSI_DH_RETRY;
}
switch (pg->state) {
-   case TPGS_STATE_OPTIMIZED:
+   case SCSI_ACCESS_STATE_OPTIMAL:
return SCSI_DH_OK;
-   case TPGS_STATE_NONOPTIMIZED:
+   case SCSI_ACCESS_STATE_ACTIVE:
if ((pg->flags & ALUA_OPTIMIZE_STPG) &&
!pg->pref &&
(pg->tpgs & TPGS_MODE_IMPLICIT))
return SCSI_DH_OK;
break;
-   case TPGS_STATE_STANDBY:
-   case TPGS_STATE_UNAVAILABLE:
+   case SCSI_ACCESS_STATE_STANDBY:
+   case SCSI_ACCESS_STATE_UNAVAILABLE:
break;
-   case TPGS_STATE_OFFLINE:
+   case SCSI_ACCESS_STATE_OFFLINE:
return SCSI_DH_IO;
break;
-   case TPGS_STATE_TRANSITIONING:
+   case SCSI_ACCESS_STATE_TRANSITIONING:
break;
default:
sdev_printk(KERN_INFO, sdev,
@@ -763,7 +755,7 @@ static void 

[PATCH 01/23] scsi_dh_alua: Pass buffer as function argument

[Hannes Reinecke]

Pass in the buffer as a function argument for submit_rtpg().

Reviewed-by: Martin K. Petersen 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 5a328bf..df71e85 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -135,12 +135,13 @@ static struct request *get_alua_req(struct scsi_device 
*sdev,
  * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
  * @sdev: sdev the command should be sent to
  */
-static unsigned submit_rtpg(struct scsi_device *sdev, struct alua_dh_data *h)
+static unsigned submit_rtpg(struct scsi_device *sdev, unsigned char *buff,
+   int bufflen, unsigned char *sense, int flags)
 {
struct request *rq;
int err = 0;
 
-   rq = get_alua_req(sdev, h->buff, h->bufflen, READ);
+   rq = get_alua_req(sdev, buff, bufflen, READ);
if (!rq) {
err = DRIVER_BUSY << 24;
goto done;
@@ -148,14 +149,14 @@ static unsigned submit_rtpg(struct scsi_device *sdev, 
struct alua_dh_data *h)
 
/* Prepare the command. */
rq->cmd[0] = MAINTENANCE_IN;
-   if (!(h->flags & ALUA_RTPG_EXT_HDR_UNSUPP))
+   if (!(flags & ALUA_RTPG_EXT_HDR_UNSUPP))
rq->cmd[1] = MI_REPORT_TARGET_PGS | MI_EXT_HDR_PARAM_FMT;
else
rq->cmd[1] = MI_REPORT_TARGET_PGS;
-   put_unaligned_be32(h->bufflen, >cmd[6]);
+   put_unaligned_be32(bufflen, >cmd[6]);
rq->cmd_len = COMMAND_SIZE(MAINTENANCE_IN);
 
-   rq->sense = h->sense;
+   rq->sense = sense;
memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
rq->sense_len = 0;
 
@@ -446,7 +447,7 @@ static int alua_rtpg(struct scsi_device *sdev, struct 
alua_dh_data *h, int wait_
expiry = round_jiffies_up(jiffies + h->transition_tmo * HZ);
 
  retry:
-   retval = submit_rtpg(sdev, h);
+   retval = submit_rtpg(sdev, h->buff, h->bufflen, h->sense, h->flags);
if (retval) {
if (!scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE,
  _hdr)) {
-- 
1.8.5.6

--
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 09/23] scsi_dh_alua: simplify alua_initialize()

[Hannes Reinecke]

Rework alua_check_vpd() to use scsi_vpd_get_tpg()
and move the port group selection into the function, too.
With that we can simplify alua_initialize() to just
call alua_check_tpgs() and alua_check_vpd();

Reviewed-by: Christoph Hellwig 
Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/device_handler/scsi_dh_alua.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 25d0a92..3b4f431 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -92,6 +92,7 @@ struct alua_dh_data {
 #define ALUA_POLICY_SWITCH_CURRENT 0
 #define ALUA_POLICY_SWITCH_ALL 1
 
+static int alua_rtpg(struct scsi_device *, struct alua_port_group *, int);
 static char print_alua_state(int);
 
 static void release_port_group(struct kref *kref)
@@ -294,7 +295,8 @@ static int alua_check_tpgs(struct scsi_device *sdev)
  * Extract the relative target port and the target port group
  * descriptor from the list of identificators.
  */
-static int alua_check_vpd(struct scsi_device *sdev, struct alua_dh_data *h)
+static int alua_check_vpd(struct scsi_device *sdev, struct alua_dh_data *h,
+ int tpgs)
 {
int rel_port = -1, group_id;
 
@@ -310,13 +312,21 @@ static int alua_check_vpd(struct scsi_device *sdev, 
struct alua_dh_data *h)
ALUA_DH_NAME);
return SCSI_DH_DEV_UNSUPP;
}
-   h->group_id = group_id;
+
+   h->pg = alua_alloc_pg(sdev, group_id, tpgs);
+   if (IS_ERR(h->pg)) {
+   if (PTR_ERR(h->pg) == -ENOMEM)
+   return SCSI_DH_NOMEM;
+   return SCSI_DH_DEV_UNSUPP;
+   }
+   h->rel_port = rel_port;
 
sdev_printk(KERN_INFO, sdev,
-   "%s: port group %x rel port %x\n",
-   ALUA_DH_NAME, h->group_id, h->rel_port);
+   "%s: device %s port group %x rel port %x\n",
+   ALUA_DH_NAME, h->pg->device_id_str,
+   h->group_id, h->rel_port);
 
-   return 0;
+   return alua_rtpg(sdev, h->pg, 0);
 }
 
 static char print_alua_state(int state)
@@ -635,23 +645,9 @@ static int alua_initialize(struct scsi_device *sdev, 
struct alua_dh_data *h)
int err = SCSI_DH_DEV_UNSUPP, tpgs;
 
tpgs = alua_check_tpgs(sdev);
-   if (tpgs == TPGS_MODE_NONE)
-   goto out;
-
-   err = alua_check_vpd(sdev, h);
-   if (err != SCSI_DH_OK)
-   goto out;
+   if (tpgs != TPGS_MODE_NONE)
+   err = alua_check_vpd(sdev, h, tpgs);
 
-   h->pg = alua_alloc_pg(sdev, h->group_id, tpgs);
-   if (IS_ERR(h->pg)) {
-   if (PTR_ERR(h->pg) == -ENOMEM)
-   err = SCSI_DH_NOMEM;
-   goto out;
-   }
-   kref_get(>pg->kref);
-   err = alua_rtpg(sdev, h->pg, 0);
-   kref_put(>pg->kref, release_port_group);
-out:
return err;
 }
 /*
-- 
1.8.5.6

--
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 00/23] ALUA device handler update, part II

[Hannes Reinecke]

as promised here is now the second part of my ALUA device handler update.
This contains a major rework of the ALUA device handler as execution is
moved onto a workqueue. This has the advantage that we avoid having to
do multiple calls to the same LUN (as happens frequently when failing
over a LUN with several paths) and finally retries are handled correctly.
As some arrays are only capable of handling one STPG at a time I've added
a blacklist flag which then uses a singlethreaded workqueue, thereby
effectively synchronize STPG handling.
Thanks to Bart for this suggestion.

As usual, comments and reviews are welcome.

Changes to v4:
- use kfree_rcu() as suggested by hch
- Use 'IS_ERR' instead of 'PTR_ERR' when checking for validity
  of a pointer
- Simplify pg assignment as suggested by hch
- Use separate WARN_ON statements a suggested by hch
- Fixes to avoid I/O stall on failover

Changes to v3:
- Use scsi_device flag for blacklisting as suggested by hch
- Add Arrays for synchronous ALUA handling
- Move synchronize_rcu() into release_port_group()
- Add remaining reviewed tags

Changes to v2:
- Use a SCSI blacklist flag instead of a hardware handler parameter
  for switching to synchronous ALUA handling
- Move scsi_get_device_flags{,_keyed} to scsi_devinfo.h
- Move flush_delayed_work() into release_port_group()
- Rename alua_lookup_pg() into alua_find_get_pg()
- Add __rcu annotations to keep sparse happy

Changes to v1:
- Include reviews from hch
- Switch to hardware handler parameter instead of module option

Hannes Reinecke (23):
  scsi_dh_alua: Pass buffer as function argument
  scsi_dh_alua: separate out alua_stpg()
  scsi_dh_alua: Make stpg synchronous
  scsi_dh_alua: call alua_rtpg() if stpg fails
  scsi_dh_alua: switch to scsi_execute_req_flags()
  scsi_dh_alua: allocate RTPG buffer separately
  scsi_dh_alua: Use separate alua_port_group structure
  scsi_dh_alua: use unique device id
  scsi_dh_alua: simplify alua_initialize()
  revert commit a8e5a2d593cb ("[SCSI] scsi_dh_alua: ALUA handler attach
should succeed while TPG is transitioning")
  scsi_dh_alua: move optimize_stpg evaluation
  scsi_dh_alua: remove 'rel_port' from alua_dh_data structure
  scsi_dh_alua: Use workqueue for RTPG
  scsi_dh_alua: Allow workqueue to run synchronously
  scsi_dh_alua: Add new blacklist flag 'BLIST_SYNC_ALUA'
  scsi_dh_alua: Recheck state on unit attention
  scsi_dh_alua: update all port states
  scsi_dh_alua: Send TEST UNIT READY to poll for transitioning
  scsi_dh: add 'rescan' callback
  scsi: Add 'access_state' attribute
  scsi_dh_alua: use common definitions for ALUA state
  scsi_dh_alua: update 'access_state' field
  scsi_dh_alua: Update version to 2.0

 drivers/scsi/device_handler/scsi_dh_alua.c | 988 -
 drivers/scsi/scsi_devinfo.c|   2 +
 drivers/scsi/scsi_lib.c|   1 +
 drivers/scsi/scsi_scan.c   |  12 +-
 drivers/scsi/scsi_sysfs.c  |  49 ++
 include/scsi/scsi_device.h |   2 +
 include/scsi/scsi_devinfo.h|   1 +
 include/scsi/scsi_dh.h |   2 +
 include/scsi/scsi_proto.h  |  13 +
 9 files changed, 763 insertions(+), 307 deletions(-)

-- 
1.8.5.6

--
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 3/3] add support for DWC UFS Host Controller

[Mark Rutland]

On Mon, Feb 08, 2016 at 03:17:11PM +, Joao Pinto wrote:
> Hi Mark and Arnd,
> 
> I am planning the v2 of this patch set. I have a doubt in the version
> compatibility strings... The core driver must support the UFS 2.0 controller 
> and
> this patch set includes a patch that adds 2.0 capabilities to it.

Ok. It wasn't clear to me that this series added support for features
specific to 2.0.

> The core driver can get from the controller's version and with that
> use or not a specific 2.0 feature.

It can be detected from the hardware?

> What would be the real added-value of having a compatibility string like
> "snps,ufshcd-1.1" and "snps,ufshcd-2.0" if the driver can perform as 2.0 if it
> detects a 2.0 controller?

Generally having specify strings ensure that it's possible to handle
things in future (e.g. errata workarounds), or if we realise something
isn't as clear-cut as we thought it was (i.e. 2.0 not being a strict
superset of 1.1).

It's difficult to predict when you need that, so we err on the side of
requiring it. At worst it means you have a small redundant few
characters in a DT, but that's a much better proposition than having too
little information.

> Are you saying that a user that puts "snps,ufshcd-1.1"
> in the DT compatibility string disables the UFS 2.0 in the core driver despite
> the controller is 2.0? Please clarify.

If you can consistently and safely detect that the HW is 2.0, using 2.0
functionality is fine.

Regardless, you should have a -1.1 compatible string for the 1.1 HW, and
a -2.0 string for the 2.0 HW, so that DTs are explicit about what the
hardware is. If 2.0 is intended to be a superset of 1.1, you can have a
1.1 fallback entry for the 2.0 hardware.

Thanks,
Mark.
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Hannes Reinecke]

On 02/08/2016 04:12 PM, Keith Busch wrote:
> On Mon, Feb 08, 2016 at 11:13:50AM +0100, Christoph Hellwig wrote:
>> On Mon, Feb 08, 2016 at 12:01:16PM +0200, Sagi Grimberg wrote:
>>>
 Do we have defined sysfs attributes for NVMe devices nowadays?
>>>
>>> /sys/block/nvme0n1/uuid
>>
>> That's only supported for NVMe 1.1 and higher devices, and optional.
>> For older or stupid devices we need to support the algorithm based
>> on the serial attribute from nvme_fill_device_id_scsi_string() in
>> drivers/nvme/host/scsi.c.
> 
> It's even worse. NGUID was defined for 1.2 devices and higher. 1.1
> devices should have EUI-64 at:
>  
>   /sys/block/nvmeXnY/eui
> 
> 1.2 devices will have either uuid or eui (or both).
> 
> The majority of devices in circulation today are 1.0, and need to concat
> these three entries to make a unique identifier:
> 
>   /sys/block/nvmeXnY/device/serial
>   /sys/block/nvmeXnY/device/model
>   /sys/block/nvmeXnY/nsid

Ok, so what about having a 'wwid' attribute which provides combined
information (like scsi has)?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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

Re: Question for Patch"libsas: fix "sysfs group not found" warnings at port teardown time"

[John Garry]

On 05/02/2016 21:33, Praveen Murali wrote:

Hi Yijing,
   The fix was deemed inappropriate and I think the explanation provided by 
James was kind similar to what your observation is. Also, as far as I remember 
the consensus was that these error messages (sysfs group not found) are 
harmless at this point. I think James can provide a better explanation and 
direction for you (copying him here).

Praveen



I can't find the original full discussion on this. My impression is that 
the fix is incorrect as the port should not be deleted in 
sas_destruct_devices(). I also tried this patch and got a NULL deference 
when I unplugged the disk from the expander.


We get the warn as the port is deleted before the device which is 
attached to it. The tricky part is that the port and devices are deleted 
in seperate work structs being processed in same work queue (shost wq). 
The first cannot be relinquished to allow the second to run.


One (undesirable) solution is to call sas_destruct_devices() directly 
from sas_unregister_dev().



On Feb 5, 2016, at 1:20 AM, wangyijing  wrote:

Hi Dan and Praveen,
   I found a patch titled "libsas: fix "sysfs group not found" warnings at port 
teardown time" by google,
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html

I found the same warning calltrace in my platform, but I didn't find the patch 
changes in the latest kernel 4.5-rc2.
So is this issue still in kernel ?

I think your patch could fix this issue we found, but I'm worried about another 
problem.

Now when unplug a disk

LLDD report a event loss_of_singal
sas_deform_port
sas_unregister_domain_devices
sas_unregister_dev
sas_discover_event(dev->port, DISCE_DESTRUCT);
sas_port_delete
phy->port = NULL;

and after your patch changes

LLDD report a event loss_of_singal
sas_deform_port
sas_unregister_domain_devices
sas_unregister_dev
sas_discover_event(dev->port, DISCE_DESTRUCT);
phy->port = NULL;

...
sas_destruct_devices
sas_port_delete   //now we actually delete the port device, but we 
set  phy->port = NULL;  before this time.


So if we hotplug the disk quickly, plug,unplug,plug,
The new dmaed event(plug) would try to alloc and add a new port, but the old 
port device is still alive.
Another calltrace would occur

WARNING: CPU: 0 PID: 1038 at lib/kobject.c:240 
kobject_add_internal+0x258/0x318()
kobject_add_internal failed for port-0:0 with -EEXIST, don't try to register 
things with the same name in the same directory.
CPU: 0 PID: 1038 Comm: kworker/u64:2 Tainted: GW   4.1.6+ #140
[] dump_backtrace+0x0/0x124
[] show_stack+0x10/0x1c
[] warn_slowpath_fmt+0x4c/0x58
[] device_add+0x28c/0x5b8
[] sas_port_add+0x20/0xbc
[] sas_porte_bytes_dmaed
[] process_one_work+0x13c/0x344

Because I am not a sas guy, so if you could comment this or post new patch, I 
would be thanks a lot!

Thanks!
Yijing.



--
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


--
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




--
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

[Bug 111381] mvsas 0.8.16 on Marvell 88SE9485 reports timeouts on load

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=111381

--- Comment #4 from Gabriel A. Devenyi  ---
After much more research and reading, I believe I've found the root issue
causing the communication timeouts to the disks. I have not changed any cables
(other than reseating everything).

I came across several reports of marvell (mvsas) controllers randomly causing
issues with load, which mentioned SMART.

http://www.spinics.net/lists/linux-ide/msg50075.html
https://bugzilla.kernel.org/show_bug.cgi?id=42679

So I decided to stop smartd and try my load tests.

I have now gone through three iterations of high-load zfs scrubs along with
iotest.sh hammering the array simultaneously with no timeouts or communications
issues. I believe this indicates some issue with the driver/controller/disks
handling smart commands during load.

Do you have any recommendations as how I can test this further? Is there any
debug info I can provide?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

T10 adds locally assigned UUID designation descriptor

[Douglas Gilbert]

Recently, in draft spc5r08, T10 added a locally assigned RFC 4122
UUID *** designation descriptor. That descriptor can now be
returned for VPD page 0x83 (device identification) amongst others.
It can be used anywhere SCSI needs a unique identifier expanding
the previous set of preferred identifiers: EUI, NAA and SCSI_name
(iSCSI).

In the soon to be released sg3_utils version 1.42 the new UUID
designation descriptor is decoded including Hannes' --export
option found in sg_inq, for example:

# sg_inq --export /dev/sg0
  ...
  SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeee

Perhaps some udev work is needed to incorporate this new identifier.

Doug Gilbert

** see  https://en.wikipedia.org/wiki/Universally_unique_identifier
--
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 3/4] qla2xxx: Add DebugFS node for target sess list.

[Himanshu Madhani]

Hi Nic, 


On 2/6/16, 8:40 PM, "Nicholas A. Bellinger"  wrote:

>Hi Himanshu & Quinn,
>
>On Thu, 2016-02-04 at 11:45 -0500, Himanshu Madhani wrote:
>> From: Quinn Tran 
>> 
>>  #cat  /sys/kernel/debug/qla2xxx/qla2xxx_31/tgt_sess
>>  qla2xxx_31
>>  Port ID   Port NameHandle
>>  ff:fc:01  21:fd:00:05:33:c7:ec:16  0
>>  01:0e:00  21:00:00:24:ff:7b:8a:e4  1
>>  01:0f:00  21:00:00:24:ff:7b:8a:e5  2
>>  
>> 
>> Signed-off-by: Quinn Tran 
>> Signed-off-by: Himanshu Madhani 
>> ---
>>  drivers/scsi/qla2xxx/qla_def.h|1 +
>>  drivers/scsi/qla2xxx/qla_dfs.c|   55
>>
>>  drivers/scsi/qla2xxx/qla_target.c |   56
>>
>>  3 files changed, 93 insertions(+), 19 deletions(-)
>> 
>
>So looking at this patch beyond the debugfs part, it does change where
>->check_initiator_node_acl() gets call during qlt_create_sess().
>
>I assume this is related to new debugfs attribute, and these changes
>(plus others in qlt_del_sess_work_fn) are not bug-fixes on their own,
>correct..?
>
>Aside from that, I don't have an objection to merge as v4.6 for-next
>code if QLogic finds it useful for debugging.

Yes. The changes in this patch are strictly for making information
available via debugFS
and not bug-fixes on their own. This information has been requested by few
customer who
finds this information useful for debugging and in addition they use this
information in
their configuration scripts as well.


>
>
>
>> diff --git a/drivers/scsi/qla2xxx/qla_def.h
>>b/drivers/scsi/qla2xxx/qla_def.h
>> index 9872f34..e6c5bcf 100644
>> --- a/drivers/scsi/qla2xxx/qla_def.h
>> +++ b/drivers/scsi/qla2xxx/qla_def.h
>> @@ -2929,6 +2929,7 @@ struct qlt_hw_data {
>>  
>>  uint8_t tgt_node_name[WWN_SIZE];
>>  
>> +struct dentry *dfs_tgt_sess;
>>  struct list_head q_full_list;
>>  uint32_t num_pend_cmds;
>>  uint32_t num_qfull_cmds_alloc;
>> diff --git a/drivers/scsi/qla2xxx/qla_dfs.c
>>b/drivers/scsi/qla2xxx/qla_dfs.c
>> index cd8b96a..34272fd 100644
>> --- a/drivers/scsi/qla2xxx/qla_dfs.c
>> +++ b/drivers/scsi/qla2xxx/qla_dfs.c
>> @@ -13,6 +13,47 @@ static struct dentry *qla2x00_dfs_root;
>>  static atomic_t qla2x00_dfs_root_count;
>>  
>>  static int
>> +qla2x00_dfs_tgt_sess_show(struct seq_file *s, void *unused)
>> +{
>> +scsi_qla_host_t *vha = s->private;
>> +struct qla_hw_data *ha = vha->hw;
>> +unsigned long flags;
>> +struct qla_tgt_sess *sess = NULL;
>> +struct qla_tgt *tgt= vha->vha_tgt.qla_tgt;
>> +
>> +seq_printf(s, "%s\n",vha->host_str);
>> +if (tgt) {
>> +seq_printf(s, "Port ID   Port NameHandle\n");
>> +
>> +spin_lock_irqsave(>tgt.sess_lock, flags);
>> +list_for_each_entry(sess, >sess_list, sess_list_entry) {
>> +seq_printf(s, "%02x:%02x:%02x  %8phC  %d\n",
>> +   
>> sess->s_id.b.domain,sess->s_id.b.area,
>> +   sess->s_id.b.al_pa,  sess->port_name,
>> +   sess->loop_id);
>> +}
>> +spin_unlock_irqrestore(>tgt.sess_lock, flags);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int
>> +qla2x00_dfs_tgt_sess_open(struct inode *inode, struct file *file)
>> +{
>> +scsi_qla_host_t *vha = inode->i_private;
>> +return single_open(file, qla2x00_dfs_tgt_sess_show, vha);
>> +}
>> +
>> +
>> +static const struct file_operations dfs_tgt_sess_ops = {
>> +.open   = qla2x00_dfs_tgt_sess_open,
>> +.read   = seq_read,
>> +.llseek = seq_lseek,
>> +.release= single_release,
>> +};
>> +
>> +static int
>>  qla_dfs_fw_resource_cnt_show(struct seq_file *s, void *unused)
>>  {
>>  struct scsi_qla_host *vha = s->private;
>> @@ -248,6 +289,15 @@ create_nodes:
>>  "Unable to create debugfs fce node.\n");
>>  goto out;
>>  }
>> +
>> +ha->tgt.dfs_tgt_sess = debugfs_create_file("tgt_sess",
>> +S_IRUSR, ha->dfs_dir, vha, _tgt_sess_ops);
>> +if (!ha->tgt.dfs_tgt_sess) {
>> +ql_log(ql_log_warn, vha, 0x,
>> +"Unable to create debugFS tgt_sess node.\n");
>> +goto out;
>> +}
>> +
>>  out:
>>  return 0;
>>  }
>> @@ -257,6 +307,11 @@ qla2x00_dfs_remove(scsi_qla_host_t *vha)
>>  {
>>  struct qla_hw_data *ha = vha->hw;
>>  
>> +if (ha->tgt.dfs_tgt_sess) {
>> +debugfs_remove(ha->tgt.dfs_tgt_sess);
>> +ha->tgt.dfs_tgt_sess = NULL;
>> +}
>> +
>>  if (ha->dfs_fw_resource_cnt) {
>>  debugfs_remove(ha->dfs_fw_resource_cnt);
>>  ha->dfs_fw_resource_cnt = NULL;
>> diff --git a/drivers/scsi/qla2xxx/qla_target.c
>>b/drivers/scsi/qla2xxx/qla_target.c
>> index 46c6679..a754aa4 100644
>> --- 

re: megaraid_sas: Task management support

[Dan Carpenter]

Hello Sumit Saxena,

The patch 31796fa184ee: "megaraid_sas: Task management support" from
Jan 28, 2016, leads to the following static checker warning:

drivers/scsi/megaraid/megaraid_sas_base.c:1788 
megasas_update_sdev_properties()
warn: if statement not indented

drivers/scsi/megaraid/megaraid_sas_base.c
  1781  } else {
  1782  device_id = ((sdev->channel % 2) * 
MEGASAS_MAX_DEV_PER_CHANNEL)
  1783  + sdev->id;
  1784  local_map_ptr = fusion->ld_drv_map[(instance->map_id & 
1)];
  1785  ld = MR_TargetIdToLdGet(device_id, local_map_ptr);
  1786  raid = MR_LdRaidGet(ld, local_map_ptr);
  1787  
  1788  if (raid->capability.ldPiMode == 
MR_PROT_INFO_TYPE_CONTROLLER)
  1789  blk_queue_update_dma_alignment(sdev->request_queue, 
0x7);

It looks like the code is correct but the patch just deleted a tab
accidentally.

  1790  mr_device_priv_data->is_tm_capable =
  1791  raid->capability.tmCapable;
  1792  }

regards,
dan carpenter
--
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 2/2] add support for DWC UFS Host Controller

[Joao Pinto]

This patch has the goal to add support for DesignWare UFS Controller
specific operations and to add specific platform and pci drivers.

Signed-off-by: Joao Pinto 
---
Changes v3->v4 (Arnd Bergmann and Mark Rutland):
- SCSI_UFS_DWC_HOOKS is now silent and selected by the SCSI_UFS_DWC_PLAT
 or SCSI_UFS_DWC_PCI
- Compatibility string has the ufs core version for info purposes since
 the driver is capable of getting the controller version from its 
 registers
- Created ufs-dwc-pci glue driver with specific DWC data
- MPHY configuration remains in the ufshcd-dwc since it is unipro
 attribute writting only not following the a linux phy framework logic
Changes v2->v3 (Julian Calaby):
- Implement a common DWC code to be used by the platform and pci glue
 drivers
- Synopsys ID & Class added to the existing pci driver and specific DWC
 was also added to the pci driver
Changes v1->v2 (Akinobu Mita):
- Implement a platform driver that uses the existing UFS core driver
- Add DWC specific code to the existing UFS core driver

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  50 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 +
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 768 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  26 +
 drivers/scsi/ufs/ufshcd.c |  61 +-
 drivers/scsi/ufs/ufshcd.h |  22 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 13 files changed, 1299 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt 
b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
new file mode 100644
index 000..f38a3f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
@@ -0,0 +1,17 @@
+* Universal Flash Storage (UFS) DesignWare Host Controller
+
+DWC_UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1"
+  or "snps,ufshcd-2.0")
+- reg   : 
+- interrupts: 
+
+Example:
+   dwc_ufshcd@0xD000 {
+   compatible = "snps,ufshcd-2.0";
+   reg = < 0xD000 0x1 >;
+   interrupts = < 24 >;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index d2f94e2..3db3c4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11006,6 +11006,12 @@ S: Supported
 F: Documentation/scsi/ufs.txt
 F: drivers/scsi/ufs/
 
+UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
+M: Joao Pinto 
+L: linux-scsi@vger.kernel.org
+S: Supported
+F: drivers/scsi/ufs/*dwc*
+
 UNSORTED BLOCK IMAGES (UBI)
 M: Artem Bityutskiy 
 M: Richard Weinberger 
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f45307..8c130de 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,53 @@ config SCSI_UFS_QCOM
 
  Select this if you have UFS controller on QCOM chipset.
  If unsure, say N.
+
+config SCSI_UFS_DWC_HOOKS
+   bool
+
+config SCSI_UFS_DWC_PLAT
+   tristate "DesignWare UFS controller platform glue driver"
+   depends on SCSI_UFSHCD_PLATFORM
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller platform glue driver.
+
+ Select this if you have a DesignWare UFS controller on Platform bus.
+ If unsure, say N.
+
+config SCSI_UFS_DWC_PCI
+   tristate "DesignWare UFS controller pci glue driver"
+   depends on SCSI_UFSHCD_PCI
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller pci glue driver.
+
+ Select this if you have a DesignWare UFS controller on pci bus.
+ If unsure, say N.
+
+config SCSI_UFS_DWC_MPHY_TC
+   bool "Support for the Synopsys MPHY Test Chip"
+   depends on SCSI_UFS_DWC_HOOKS && (SCSI_UFSHCD_PCI || SCSI_UFS_DWC_PLAT)
+   ---help---
+ This selects the support for the Synopsys MPHY Test Chip.
+
+ Select this if you have a Synopsys MPHY Test Chip.
+ If unsure, say N.
+
+config SCSI_UFS_DWC_20BIT_RMMI
+   bool "20-bit RMMI 

Re: [v4 01/14] scsi: ufs-qcom: add number of lanes per direction

[Rob Herring]

On Thu, Feb 04, 2016 at 12:36:07PM +0200, Yaniv Gardi wrote:
> Different platform may have different number of lanes
> for the UFS link.
> Add parameter to device tree specifying how many lanes
> should be configured for the UFS link.
> 
> Signed-off-by: Gilad Broner 
> Signed-off-by: Yaniv Gardi 
> 
> ---
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  3 ++
>  drivers/scsi/ufs/ufs-qcom.c| 39 
> --
>  drivers/scsi/ufs/ufshcd-pltfrm.c   | 19 +++
>  drivers/scsi/ufs/ufshcd.c  |  1 +
>  drivers/scsi/ufs/ufshcd.h  |  2 ++
>  5 files changed, 47 insertions(+), 17 deletions(-)

Acked-by: Rob Herring 
--
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: T10 adds locally assigned UUID designation descriptor

[James Bottomley]

On Mon, 2016-02-08 at 12:33 -0500, Douglas Gilbert wrote:
> Recently, in draft spc5r08, T10 added a locally assigned RFC 4122
> UUID *** designation descriptor. That descriptor can now be
> returned for VPD page 0x83 (device identification) amongst others.
> It can be used anywhere SCSI needs a unique identifier expanding
> the previous set of preferred identifiers: EUI, NAA and SCSI_name
> (iSCSI).
> 
> In the soon to be released sg3_utils version 1.42 the new UUID
> designation descriptor is decoded including Hannes' --export
> option found in sg_inq, for example:
> 
> # sg_inq --export /dev/sg0
>...
>SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeee
> 
> Perhaps some udev work is needed to incorporate this new identifier.

Hm, we're going to have to do this carefully.  With the move to GPT
partitions, both the UUID= designator in fstab and the /dev/disk/by
-uuid/ of udev means the GPT UUID.  In theory the design of the UUID
space is to allow random selection without clashing, so we could just
place the SCSI ones in here as well and perhaps there won't be a
problem, but I'd like us to think about the consequences first.

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 00/23] ALUA device handler update, part II

[Bart Van Assche]

On 02/08/2016 06:37 AM, Hannes Reinecke wrote:

And for the impatient I've pushed the entire patchset to my kernel
repository at kernel.org:

kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel.git alua-2.v5


Hello Hannes,

I will try to free up some time to help with reviewing and testing this 
patch series. But before I can do that the v4.5-rc multipath code needs 
to be stabilized first. See also 
https://www.redhat.com/archives/dm-devel/2016-February/msg00066.html.


Bart.
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Christoph Hellwig]

On Sun, Feb 07, 2016 at 03:07:21PM -0800, James Bottomley wrote:
> > I run root-on-nvme on my laptop, and I haven't observed any problems.
> 
> Me too apparently.  It looks like this problem may be SUSE specific
> unless another distro has enabled this.  I can see why they would: you
> do need persistent names for devices, even NVMe ones.

I don't have root on nvme, just my xfstests device, but I still didn't
see the problem, neither did my various nvme development setups.

> I opened a bug against SUSE to tell them to turn it on:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=965497
> 
> The second problem is that there's currently no way to transition to
> using the serial attribute the way the udev 60-persistent-storage.rules
> are written, so if distros have some by-id hack, it will have to be
> maintained for a while.  I annotated the already closed bug on this in
> systemd with the rules that work for me.

We now expose the NVMe serial and NGUI, out of which the evpd page is
mangled depending on the NVMe spec version that the device supports as
sysfs attributes, distros can do the same mangling if they want to
support their old ids.
--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Hannes Reinecke]

On 02/08/2016 12:07 AM, James Bottomley wrote:
> On Sun, 2016-02-07 at 15:28 -0700, Jens Axboe wrote:
>> On 02/07/2016 09:04 AM, James Bottomley wrote:
>>> On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:
 Keith said it should be on by default, and I promised him to
 change
 it once we run into problems, which I guess this counts as.

 But just curious:  what distro are you using?  Upstream systemd
 explicitly rejected using scsi_id for NVMe here:

https://github.com/systemd/systemd/issues/1453

 and all my test systems don't do this either.
>>>
>>> This was SUSE (in my case, openSUSE Leap).  I just checked the
>>> source
>>> package; they patch the by-id rules back in for NVME:
>>>
>>> # PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe
>>> -devices.patch (bsc#944132)
>>> Patch1101:  1101-rules-persistent-device-names-for-NVMe
>>> -devices.patch
>>>
>>> The bugzilla is giving access denied for bug id 944132, so it's
>>> likely
>>> some proprietary vendor problem.  The patch has no preamble, so
>>> it's
>>> hard to tell what they were thinking.
>>
>> I run root-on-nvme on my laptop, and I haven't observed any problems.
> 
> Me too apparently.  It looks like this problem may be SUSE specific
> unless another distro has enabled this.  I can see why they would: you
> do need persistent names for devices, even NVMe ones.
> 
>> Generally I hate for options to default y unless absolutely 
>> necessary, it's a sure fire way to feature creep your kernel without 
>> noticing. I don't think getting all hot about this issue is fair, if 
>> the only known case is suse.
> 
> Well, OK, I'm annoyed because it was a systemd system which means
> debugging boot failures are excruciatingly difficult so it took me a
> week and a half to find out what the problem was.  Perhaps I was a bit
> rash to label this as an easily foreseen problem.
> 
> I opened a bug against SUSE to tell them to turn it on:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=965497
> 
> The second problem is that there's currently no way to transition to
> using the serial attribute the way the udev 60-persistent-storage.rules
> are written, so if distros have some by-id hack, it will have to be
> maintained for a while.  I annotated the already closed bug on this in
> systemd with the rules that work for me.
> 
Why, but you can.
That's precisely what I did with the transition to sg_inq; I've
added a new set of rules (55-sg_inq.rules and 59-sg-symlinks.rules)
which will override the values from 60-persistent-storage.rules.

Do we have defined sysfs attributes for NVMe devices nowadays?
If so I'd be willing to create/send some sysfs rules for them.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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 v4 1/2] fixed typo in ufshcd-pltfrm

[Joao Pinto]

Fixed typo in ufshcd-pltfrm.

Signed-off-by: Joao Pinto 
---
Changes v0->v4:
- Nothing changed (just to keep up with patch set version).

 drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index d2a7b12..0522891 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init);
 
 MODULE_AUTHOR("Santosh Yaragnavi ");
 MODULE_AUTHOR("Vinayak Holikatti ");
-MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver");
+MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(UFSHCD_DRIVER_VERSION);
-- 
1.8.1.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

[PATCH v4 0/2] add support for DWC UFS Controller

[Joao Pinto]

The work consisted of:
- Fixed typo in ufshcd-pltfrm.c
- Tweak ufshcd.c for UFS 2.0 support
- Implement ufshcd-dwc which contains all DWC HW specific code
- Unipro attributes were added and new registers were added to the driver
- Implement a ufs-dwc glue platform driver
- Implement a ufs-dwc-pci glue pci driver

Joao Pinto (2):
  fixed typo in ufshcd-pltfrm
  add support for DWC UFS Host Controller

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  50 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 +
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 768 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  26 +
 drivers/scsi/ufs/ufshcd-pltfrm.c  |   2 +-
 drivers/scsi/ufs/ufshcd.c |  61 +-
 drivers/scsi/ufs/ufshcd.h |  22 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 14 files changed, 1300 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

-- 
1.8.1.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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Jens Axboe]

On 02/07/2016 09:04 AM, James Bottomley wrote:

On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:

Keith said it should be on by default, and I promised him to change
it once we run into problems, which I guess this counts as.

But just curious:  what distro are you using?  Upstream systemd
explicitly rejected using scsi_id for NVMe here:

https://github.com/systemd/systemd/issues/1453

and all my test systems don't do this either.


This was SUSE (in my case, openSUSE Leap).  I just checked the source
package; they patch the by-id rules back in for NVME:

# PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe-devices.patch 
(bsc#944132)
Patch1101:  1101-rules-persistent-device-names-for-NVMe-devices.patch

The bugzilla is giving access denied for bug id 944132, so it's likely
some proprietary vendor problem.  The patch has no preamble, so it's
hard to tell what they were thinking.


I run root-on-nvme on my laptop, and I haven't observed any problems. 
Generally I hate for options to default y unless absolutely necessary, 
it's a sure fire way to feature creep your kernel without noticing. I 
don't think getting all hot about this issue is fair, if the only known 
case is suse.


If anything, let's make the description better. It's trying to be funny, 
it'd be better if it was descriptive and covered this case as well.


--
Jens Axboe

--
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: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Hannes Reinecke]

On 02/07/2016 05:04 PM, James Bottomley wrote:
> On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:
>> Keith said it should be on by default, and I promised him to change
>> it once we run into problems, which I guess this counts as.
>>
>> But just curious:  what distro are you using?  Upstream systemd
>> explicitly rejected using scsi_id for NVMe here:
>>
>>  https://github.com/systemd/systemd/issues/1453
>>
>> and all my test systems don't do this either.
> 
> This was SUSE (in my case, openSUSE Leap).  I just checked the source
> package; they patch the by-id rules back in for NVME:
> 
> # PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe-devices.patch 
> (bsc#944132)
> Patch1101:  1101-rules-persistent-device-names-for-NVMe-devices.patch
> 
> The bugzilla is giving access denied for bug id 944132, so it's likely
> some proprietary vendor problem.  The patch has no preamble, so it's
> hard to tell what they were thinking.
> 
They didn't think at all. That abovementioned bug just states 'by-id
symlinks for NVMe drives are missing'.
And they fixed it by add the respective rules (using sg_inq) to udev.

There's no mentioning of any NVMe specific sysfs attributes whatsoever.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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

Re: T10 adds locally assigned UUID designation descriptor

[Douglas Gilbert]

On 16-02-08 02:00 PM, James Bottomley wrote:

On Mon, 2016-02-08 at 12:33 -0500, Douglas Gilbert wrote:

Recently, in draft spc5r08, T10 added a locally assigned RFC 4122
UUID *** designation descriptor. That descriptor can now be
returned for VPD page 0x83 (device identification) amongst others.
It can be used anywhere SCSI needs a unique identifier expanding
the previous set of preferred identifiers: EUI, NAA and SCSI_name
(iSCSI).

In the soon to be released sg3_utils version 1.42 the new UUID
designation descriptor is decoded including Hannes' --export
option found in sg_inq, for example:

# sg_inq --export /dev/sg0
...
SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeee

Perhaps some udev work is needed to incorporate this new identifier.


Hm, we're going to have to do this carefully.  With the move to GPT
partitions, both the UUID= designator in fstab and the /dev/disk/by
-uuid/ of udev means the GPT UUID.  In theory the design of the UUID
space is to allow random selection without clashing, so we could just
place the SCSI ones in here as well and perhaps there won't be a
problem, but I'd like us to think about the consequences first.


The UUID proposal (16-005r1 from Fred Knight and "Dr. Hannes Reinecke")
was somewhat controversial with five T10 members voting against it. The
minutes state: "The members voting no stated concern that this proposal
may result in market confusion, and those members intend to develop
proposals to mitigate any confusion."

Locally assigned identifiers are not new: there already is an 8 byte
locally assigned NAA identifier (NAA=3). It is not much used, perhaps
the new locally assigned UUID (which is 16 bytes long) will find
more use. As for the 'sg_inq --export' naming, that seems to nail
down the context of the new UUID pretty well:
  SCSI_IDENT_[TARGET|PORT|LUN]_UUID
with the identifier itself in canonical UUID format. So there should
be no confusion there. And partitions are nested inside logical
units and SCSI does not define those (apart from on tapes).

Doug Gilbert


--
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

[Bug 111381] mvsas 0.8.16 on Marvell 88SE9485 reports timeouts on load with SMART commands

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=111381

Gabriel A. Devenyi  changed:

   What|Removed |Added

Summary|mvsas 0.8.16 on Marvell |mvsas 0.8.16 on Marvell
   |88SE9485 reports timeouts   |88SE9485 reports timeouts
   |on load |on load with SMART commands

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: T10 adds locally assigned UUID designation descriptor

[Knight, Frederick]

To add a little more information, the reason for the "NO" votes was as follows:

If a storage device implements this TODAY - and the only unique identifier in 
VPD page 0x83 is the UUID identifier, then, any existing shipping host will not 
find any unique identifier that it recognizes.  That host could do any number 
of other things (including but not limited to):
1) prevent the device from being used;
2) enable only a SINGLE path to the device (do not allow MPIO to operate on a 
device for which it cannot find a unique ID);
3) enable MPIO to the device using the unique ID of "NONE".

Both 1 & 2 are workable situations.  BUT, #3 is a problem; not if you have just 
1 of these UUID only devices, but if you have a bunch of them, and the host 
incorrectly assumes they are all the SAME device, and it tries to do IO based 
on that assumption.

So that is the background.  The "NO" votes were based on the belief by those 
companies that situation #3 was a forgone conclusion, and they didn't want to 
add any new features to the storage until after the hosts added code to support 
those new features - which the hosts can't do until there are storage devices 
built (based on a standard) which they can use for testing - CATCH-22.

The "YES" votes were based on the assumption that storage would not be 
configured with ONLY the UUID value unless the storage manager knew that the 
host to which it would be connected could actually support a UUID only storage 
system.  A configuration of a UUID only storage and a host that does not 
support UUID only storage is a configuration error.  No different than a "thin 
provisioned" LUN being configured for use by a host that prohibits the use of 
thin provisioned LUNs. Basically it is assumed that initial deployments of UUID 
identifiers would be in conjunction with other (NAA/EUI/etc) identifiers in 
page 0x83). Remember, real H/W vendors already own NAA and EUI values.  The 
primary creator of the UUID form will be S/W defined storage LUNs (as indicated 
in the preface material in the proposal), where there is no NAA or EUI 
available.

It simply goes back to the catch-22 - which comes first, the host support or 
the storage device support.  The solution is expected to show up in the next 
revision of the standard - there will be a temporary editor's note added 
indicating something along the lines of: a UUID only VPD page 0x83 should not 
be implemented in a storage device until it is known that the host supports 
such a configuration.  That note will be removed before final ANSI/ISO 
publication, but it will remain during the draft cycle.   At least, that is 
where the discussion ended up last I knew - we'll find out at the next meeting.

There was some minor discussion about that lack of uniqueness guarantees, but 
basically the committee said, you get what you get, and if you don't like it, 
don't use it.  You can also see, that the data structure is already primed for 
the addition of the 32 byte UUID value (if/when anyone ever invents such a 
beast, we'll examine whether it too should be added).

So I hope that clarifies some of the background around the controversy.

Fred Knight


-Original Message-
From: Douglas Gilbert [mailto:dgilb...@interlog.com] 
Sent: Monday, February 08, 2016 3:04 PM
To: James Bottomley; SCSI development list
Cc: Knight, Frederick
Subject: Re: T10 adds locally assigned UUID designation descriptor

On 16-02-08 02:00 PM, James Bottomley wrote:
> On Mon, 2016-02-08 at 12:33 -0500, Douglas Gilbert wrote:
>> Recently, in draft spc5r08, T10 added a locally assigned RFC 4122
>> UUID *** designation descriptor. That descriptor can now be
>> returned for VPD page 0x83 (device identification) amongst others.
>> It can be used anywhere SCSI needs a unique identifier expanding
>> the previous set of preferred identifiers: EUI, NAA and SCSI_name
>> (iSCSI).
>>
>> In the soon to be released sg3_utils version 1.42 the new UUID
>> designation descriptor is decoded including Hannes' --export
>> option found in sg_inq, for example:
>>
>> # sg_inq --export /dev/sg0
>> ...
>> SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeee
>>
>> Perhaps some udev work is needed to incorporate this new identifier.
>
> Hm, we're going to have to do this carefully.  With the move to GPT
> partitions, both the UUID= designator in fstab and the /dev/disk/by
> -uuid/ of udev means the GPT UUID.  In theory the design of the UUID
> space is to allow random selection without clashing, so we could just
> place the SCSI ones in here as well and perhaps there won't be a
> problem, but I'd like us to think about the consequences first.

The UUID proposal (16-005r1 from Fred Knight and "Dr. Hannes Reinecke")
was somewhat controversial with five T10 members voting against it. The
minutes state: "The members voting no stated concern that this proposal
may result in market confusion, and those members intend to develop
proposals to mitigate any confusion."

Locally