[PATCH 06/13] ia64, scsi: update references for the device-io book

2017-05-14 Thread Mauro Carvalho Chehab
The book is now at Documentation/driver-api/device-io.rst.
Update such references.

Signed-off-by: Mauro Carvalho Chehab 
---
 arch/ia64/include/asm/io.h | 2 +-
 arch/ia64/sn/kernel/iomv.c | 2 +-
 drivers/scsi/qla1280.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 5de673ac9cb1..a2540e21f919 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -117,7 +117,7 @@ extern int valid_mmap_phys_addr_range (unsigned long pfn, 
size_t count);
  * following the barrier will arrive after all previous writes.  For most
  * ia64 platforms, this is a simple 'mf.a' instruction.
  *
- * See Documentation/DocBook/deviceiobook.tmpl for more information.
+ * See Documentation/driver-api/device-io.rst for more information.
  */
 static inline void ___ia64_mmiowb(void)
 {
diff --git a/arch/ia64/sn/kernel/iomv.c b/arch/ia64/sn/kernel/iomv.c
index c77ebdf98119..2b22a71663c1 100644
--- a/arch/ia64/sn/kernel/iomv.c
+++ b/arch/ia64/sn/kernel/iomv.c
@@ -63,7 +63,7 @@ EXPORT_SYMBOL(sn_io_addr);
 /**
  * __sn_mmiowb - I/O space memory barrier
  *
- * See arch/ia64/include/asm/io.h and Documentation/DocBook/deviceiobook.tmpl
+ * See arch/ia64/include/asm/io.h and Documentation/driver-api/device-io.rst
  * for details.
  *
  * On SN2, we wait for the PIO_WRITE_STATUS SHub register to clear.
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 634254a52301..8a29fb09db14 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -3390,7 +3390,7 @@ qla1280_isp_cmd(struct scsi_qla_host *ha)
 *On PCI bus, order reverses and write of 6 posts, then index 5,
 *   causing chip to issue full queue of stale commands
 * The mmiowb() prevents future writes from crossing the barrier.
-* See Documentation/DocBook/deviceiobook.tmpl for more information.
+* See Documentation/driver-api/device-io.rst for more information.
 */
WRT_REG_WORD(®->mailbox4, ha->req_ring_index);
mmiowb();
-- 
2.9.3



Re: [Consult]: Can the coming Huawei scsi device handler be accepted in the scsi/device_handler

2017-05-14 Thread Guan Junxiong
Hi, Christoph Hellwig
  Thanks for your reply. But I am  a little confused:

  Our Huawei scsi device handler will support ALUA. Besides , some new 
enhancements such as error self negotiation
on the scsi (maybe NMVe in the future) error status handling to enhance 
reliability.  Here are two choices:
   1) Alter the scsi_dh_alua.c directly and make a generic way to handle error 
status.
   2) Add a new file named scsi_dh_huawei.c which implements the ALUA feature 
and error negotiation feature.

   Can those two choices be accepted by linux-scsi?

On 2017/5/13 12:07, Guan Junxiong wrote:
>> Hello,Alasdair and Mike:
>> I am going to add our vendor specific Huawei scsi device handler based 
>> on scsi_dh
>> framework into the linux/drivers/scsi/device_handler directory.
>> Is it possible to be merged into the device handler list?
>> 
>> I am looking forward to your reply.
>> Best withes to you!
>> 
>Any new device must support ALUA, other device handlers are legacy only.

>And btw, the right list for this is linux-scsi.



Re: [Consult]: Can the coming Huawei scsi device handler be accepted in the scsi/device_handler

2017-05-14 Thread Christoph Hellwig
On Mon, May 15, 2017 at 12:08:12PM +0800, Guan Junxiong wrote:
> Hi, Christoph Hellwig
>   Thanks for your reply. But I am  a little confused:
> 
>   Our Huawei scsi device handler will support ALUA. Besides , some new 
> enhancements such as error self negotiation
> on the scsi (maybe NMVe in the future) error status handling to enhance 
> reliability.  Here are two choices:
>1) Alter the scsi_dh_alua.c directly and make a generic way to handle 
> error status.
>2) Add a new file named scsi_dh_huawei.c which implements the ALUA feature 
> and error negotiation feature.
> 
>Can those two choices be accepted by linux-scsi?

The choice is 

 (3) get your enhancements standardized in T10 and NVMe.


Re: [RFC] scsi: generate uevent for SCSI sense code

2017-05-14 Thread Hannes Reinecke
On 05/12/2017 09:02 PM, Song Liu wrote:
> 
>> On May 3, 2017, at 5:50 PM, Song Liu  wrote:
>>
>> This patch adds capability for SCSI layer to generate uevent for SCSI
>> sense code. The feature is gated by CONFIG_SCSI_SENSE_UEVENT.
>>
>> We can configure which sense keys generate uevent for each device
>> through sysfs entry sense_event_filter. For example, the following
>> enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
>> on scsi drive sdc:
>>
>>echo 0x000c > /sys/block/sdc/device/sense_event_filter
>>
>> Here is an example output captured by udevadm:
>>
>> KERNEL[1214.945358] change   /devices/pci:00/XXX
>> ACTION=change
>> DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/host6/XXX
>> DEVTYPE=scsi_device
>> DRIVER=sd
>> LBA=0
>> MODALIAS=scsi:t-0x00
>> SDEV_UA=SCSI_SENSE
>> SENSE_CODE=3/11/14
>> SEQNUM=4536
>> SIZE=4096
>> SUBSYSTEM=scsi
>>
>> Signed-off-by: Song Liu 
>> ---
>> drivers/scsi/Kconfig   | 14 +++
>> drivers/scsi/scsi_error.c  | 26 
>> drivers/scsi/scsi_lib.c| 27 +++--
>> drivers/scsi/scsi_sysfs.c  | 60 
>> ++
>> include/scsi/scsi_device.h | 26 +++-
>> 5 files changed, 150 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>> index 3c52867..4f7f211 100644
>> --- a/drivers/scsi/Kconfig
>> +++ b/drivers/scsi/Kconfig
>> @@ -237,6 +237,20 @@ config SCSI_LOGGING
>>there should be no noticeable performance impact as long as you have
>>logging turned off.
>>
>> +config SCSI_SENSE_UEVENT
>> +bool "SCSI sense code logging"
>> +depends on SCSI
>> +default n
>> +---help---
>> +  This turns on uevent for SCSI sense code.
>> +
>> +  You can configure which sense keys generate uevent for each device
>> +  through sysfs entry sense_event_filter. For example, the following
>> +  enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
>> +  on scsi drive sdc:
>> +
>> +  echo 0x000c > /sys/block/sdc/device/sense_event_filter
>> +
>> config SCSI_SCAN_ASYNC
>>  bool "Asynchronous SCSI scanning"
>>  depends on SCSI
>> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
>> index d70c67c..eda150e 100644
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -426,6 +426,31 @@ static void scsi_report_sense(struct scsi_device *sdev,
>>  }
>> }
>>
>> +/*
>> + * generate uevent when receiving sense code from device
>> + */
>> +static void scsi_send_sense_uevent(struct scsi_device *sdev,
>> +   struct scsi_cmnd *scmd,
>> +   struct scsi_sense_hdr *sshdr)
>> +{
>> +#ifdef CONFIG_SCSI_SENSE_UEVENT
>> +struct scsi_event *evt;
>> +
>> +if (!test_bit(sshdr->sense_key & 0xf,
>> +  &sdev->sense_event_filter))
>> +return;
>> +evt = sdev_evt_alloc(SDEV_EVT_SCSI_SENSE, GFP_ATOMIC);
>> +if (!evt)
>> +return;
>> +
>> +evt->sense_evt_data.lba = scsi_get_lba(scmd);
>> +evt->sense_evt_data.size = blk_rq_bytes(scmd->request);
>> +memcpy(&evt->sense_evt_data.sshdr, sshdr,
>> +   sizeof(struct scsi_sense_hdr));
>> +sdev_evt_send(sdev, evt);
>> +#endif
>> +}
>> +
>> /**
>>  * scsi_check_sense - Examine scsi cmd sense
>>  * @scmd:Cmd to have sense checked.
>> @@ -446,6 +471,7 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>>  return FAILED;  /* no valid sense data */
>>
>>  scsi_report_sense(sdev, &sshdr);
>> +scsi_send_sense_uevent(sdev, scmd, &sshdr);
>>
>>  if (scsi_sense_is_deferred(&sshdr))
>>  return NEEDS_RETRY;
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 95f963b..1095f27 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -2656,8 +2656,9 @@ EXPORT_SYMBOL(scsi_device_set_state);
>>  */
>> static void scsi_evt_emit(struct scsi_device *sdev, struct scsi_event *evt)
>> {
>> -int idx = 0;
>> -char *envp[3];
>> +int idx = 0, i;
>> +char *envp[5];  /* SDEV_EVT_SCSI_SENSE needs most entries (4) */
>> +int free_envp = -1;
>>
>>  switch (evt->evt_type) {
>>  case SDEV_EVT_MEDIA_CHANGE:
>> @@ -2682,6 +2683,23 @@ static void scsi_evt_emit(struct scsi_device *sdev, 
>> struct scsi_event *evt)
>>  case SDEV_EVT_ALUA_STATE_CHANGE_REPORTED:
>>  envp[idx++] = "SDEV_UA=ASYMMETRIC_ACCESS_STATE_CHANGED";
>>  break;
>> +#ifdef CONFIG_SCSI_SENSE_UEVENT
>> +case SDEV_EVT_SCSI_SENSE:
>> +envp[idx++] = "SDEV_UA=SCSI_SENSE";
>> +for (i = idx; i < idx + 3; ++i) {
>> +envp[i] = kzalloc(32, GFP_ATOMIC);
>> +if (!envp[i])
>> +break;
>> +free_envp = i;
>> +}
>> +snprintf(envp[idx++], 32, "LBA=%lu", evt->sense_evt_data.lba);
>> +