Re: [PATCH v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Greg KH
On Tue, Aug 12, 2014 at 11:38:37AM +0530, Sanjeev Sharma wrote:
 spin_is_locked() always return false in uniprocessor configuration and 
 therefore it
 would be advise to replace with lockdep_assert_held().

Add on some architectures in here somewhere, as it's not broken on the
large majority of UP cpus :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Sanjeev Sharma
on some architecture spin_is_locked() always return false in
uniprocessor configuration and therefore it would be advise
to replace with lockdep_assert_held().

Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
---
Changes in v3:
 incorporated review comment suggested by Greg

 drivers/usb/storage/uas.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 3f42785..05b2d8e 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info *devinfo,
struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
 
uas_log_cmd_state(cmnd, caller);
-   WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
+   lockdep_assert_held(devinfo-lock);
WARN_ON_ONCE(cmdinfo-state  COMMAND_ABORTED);
cmdinfo-state |= COMMAND_ABORTED;
cmdinfo-state = ~IS_IN_WORK_LIST;
@@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
struct uas_dev_info *devinfo = cmnd-device-hostdata;
 
-   WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
+   lockdep_assert_held(devinfo-lock);
cmdinfo-state |= IS_IN_WORK_LIST;
schedule_work(devinfo-work);
 }
@@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
char *caller)
struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
 
-   WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
+   lockdep_assert_held(devinfo-lock);
if (cmdinfo-state  (COMMAND_INFLIGHT |
  DATA_IN_URB_INFLIGHT |
  DATA_OUT_URB_INFLIGHT |
@@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
struct urb *urb;
int err;
 
-   WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
+   lockdep_assert_held(devinfo-lock);
if (cmdinfo-state  SUBMIT_STATUS_URB) {
urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo-stream);
if (!urb)
-- 
1.7.11.7

--
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 v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Sharma, Sanjeev
Done !

Thanks
Sanjeev Sharma

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Tuesday, August 12, 2014 11:32 AM
To: Sharma, Sanjeev
Cc: hdego...@redhat.com; kra...@redhat.com; mdharm-...@one-eyed-alien.net; 
linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; 
linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

On Tue, Aug 12, 2014 at 11:38:37AM +0530, Sanjeev Sharma wrote:
 spin_is_locked() always return false in uniprocessor configuration and 
 therefore it would be advise to replace with lockdep_assert_held().

Add on some architectures in here somewhere, as it's not broken on the large 
majority of UP cpus :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Hans de Goede
Hi,

On 08/12/2014 08:40 AM, Sanjeev Sharma wrote:
 on some architecture spin_is_locked() always return false in
 uniprocessor configuration and therefore it would be advise
 to replace with lockdep_assert_held().
 
 Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
 ---
 Changes in v3:
  incorporated review comment suggested by Greg

Thanks, this is still:

Acked-by: Hans de Goede hdego...@redhat.com

Regards,

Hans

 
  drivers/usb/storage/uas.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
 index 3f42785..05b2d8e 100644
 --- a/drivers/usb/storage/uas.c
 +++ b/drivers/usb/storage/uas.c
 @@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info 
 *devinfo,
   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
  
   uas_log_cmd_state(cmnd, caller);
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   WARN_ON_ONCE(cmdinfo-state  COMMAND_ABORTED);
   cmdinfo-state |= COMMAND_ABORTED;
   cmdinfo-state = ~IS_IN_WORK_LIST;
 @@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
   struct uas_dev_info *devinfo = cmnd-device-hostdata;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   cmdinfo-state |= IS_IN_WORK_LIST;
   schedule_work(devinfo-work);
  }
 @@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
 char *caller)
   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
   struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   if (cmdinfo-state  (COMMAND_INFLIGHT |
 DATA_IN_URB_INFLIGHT |
 DATA_OUT_URB_INFLIGHT |
 @@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
   struct urb *urb;
   int err;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   if (cmdinfo-state  SUBMIT_STATUS_URB) {
   urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo-stream);
   if (!urb)
 
--
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 v2] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Guenter Roeck
On Tue, Aug 12, 2014 at 02:01:53PM +0800, Greg KH wrote:
 On Tue, Aug 12, 2014 at 11:38:37AM +0530, Sanjeev Sharma wrote:
  spin_is_locked() always return false in uniprocessor configuration and 
  therefore it
  would be advise to replace with lockdep_assert_held().
 
 Add on some architectures in here somewhere, as it's not broken on the
 large majority of UP cpus :)
 
FWIW, it is confirmed broken on mips (32 and 64 bit), ppc, and sparc64.
I have not tested on x86. Might be worth trying. arm64 seems to be ok,
unless I did something wrong in my test, as well as at least some of
the architectures which don't support smp to start with (such as sparc32
or microblaze).

Guenter
--
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 v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

2014-08-12 Thread Sharma, Sanjeev
Yes I have incorporated review comment from Greg.

Regards
Sanjeev Sharma

-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com] 
Sent: Tuesday, August 12, 2014 11:59 AM
To: Sharma, Sanjeev
Cc: gre...@linuxfoundation.org; kra...@redhat.com; 
mdharm-...@one-eyed-alien.net; linux-...@vger.kernel.org; 
linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

Hi,

On 08/12/2014 08:40 AM, Sanjeev Sharma wrote:
 on some architecture spin_is_locked() always return false in 
 uniprocessor configuration and therefore it would be advise to replace 
 with lockdep_assert_held().
 
 Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
 ---
 Changes in v3:
  incorporated review comment suggested by Greg

Thanks, this is still:

Acked-by: Hans de Goede hdego...@redhat.com

Regards,

Hans

 
  drivers/usb/storage/uas.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c 
 index 3f42785..05b2d8e 100644
 --- a/drivers/usb/storage/uas.c
 +++ b/drivers/usb/storage/uas.c
 @@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info 
 *devinfo,
   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
  
   uas_log_cmd_state(cmnd, caller);
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   WARN_ON_ONCE(cmdinfo-state  COMMAND_ABORTED);
   cmdinfo-state |= COMMAND_ABORTED;
   cmdinfo-state = ~IS_IN_WORK_LIST;
 @@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
   struct uas_dev_info *devinfo = cmnd-device-hostdata;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   cmdinfo-state |= IS_IN_WORK_LIST;
   schedule_work(devinfo-work);
  }
 @@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
 char *caller)
   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
   struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   if (cmdinfo-state  (COMMAND_INFLIGHT |
 DATA_IN_URB_INFLIGHT |
 DATA_OUT_URB_INFLIGHT |
 @@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
   struct urb *urb;
   int err;
  
 - WARN_ON_ONCE(!spin_is_locked(devinfo-lock));
 + lockdep_assert_held(devinfo-lock);
   if (cmdinfo-state  SUBMIT_STATUS_URB) {
   urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo-stream);
   if (!urb)
 
--
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 v1] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips

2014-08-12 Thread Yaniv Gardi
The files in this change implement the UFS HW (controller  PHY) specific
behavior in Qualcomm MSM chips.

Signed-off-by: Yaniv Gardi yga...@codeaurora.org
---
 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c |  254 +++
 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h |  216 ++
 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c |  368 ++
 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h |  735 
 drivers/scsi/ufs/ufs-msm-phy.c  |  646 ++
 drivers/scsi/ufs/ufs-msm-phy.h  |  193 ++
 drivers/scsi/ufs/ufs-msm.c  | 1119 +++
 drivers/scsi/ufs/ufs-msm.h  |  158 +
 8 files changed, 3689 insertions(+)
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy.h
 create mode 100644 drivers/scsi/ufs/ufs-msm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm.h

diff --git a/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c 
b/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
new file mode 100644
index 000..2b48bac
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright (c) 2013-2014, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/time.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/iopoll.h
+#include linux/platform_device.h
+#include linux/msm-bus.h
+
+#include ufshcd.h
+#include unipro.h
+#include ufs-msm.h
+#include ufs-msm-phy.h
+#include ufs-msm-phy-qmp-20nm.h
+
+#define UFS_PHY_NAME ufs_msm_phy_qmp_20nm
+
+static int ufs_msm_phy_qmp_20nm_phy_calibrate(struct ufs_msm_phy *ufs_msm_phy)
+{
+   struct ufs_msm_phy_calibration *tbl_A, *tbl_B;
+   int tbl_size_A, tbl_size_B;
+   int rate = UFS_MSM_LIMIT_HS_RATE;
+   int err;
+
+   tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A);
+   tbl_A = phy_cal_table_rate_A;
+
+   tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
+   tbl_B = phy_cal_table_rate_B;
+
+   err = ufs_msm_phy_calibrate(ufs_msm_phy, tbl_A, tbl_size_A,
+   tbl_B, tbl_size_B, rate);
+
+   if (err)
+   dev_err(ufs_msm_phy-dev, %s: ufs_msm_phy_calibrate() failed 
%d\n,
+   __func__, err);
+
+   return err;
+}
+
+static int ufs_msm_phy_qmp_20nm_init(struct phy *generic_phy)
+{
+   struct ufs_msm_phy_qmp_20nm *phy = phy_get_drvdata(generic_phy);
+   struct ufs_msm_phy *phy_common = phy-common_cfg;
+   int err = 0;
+
+   err = ufs_msm_phy_init_clks(generic_phy, phy_common);
+   if (err) {
+   dev_err(phy_common-dev, %s: ufs_msm_phy_init_clks() failed 
%d\n,
+   __func__, err);
+   goto out;
+   }
+
+   err = ufs_msm_phy_init_vregulators(generic_phy, phy_common);
+   if (err)
+   dev_err(phy_common-dev, %s: ufs_msm_phy_init_vregulators() 
failed %d\n,
+   __func__, err);
+
+out:
+   return err;
+}
+
+static
+void ufs_msm_phy_qmp_20nm_power_control(struct ufs_msm_phy *phy, bool val)
+{
+   if (val) {
+   writel_relaxed(0x1, phy-mmio + UFS_PHY_POWER_DOWN_CONTROL);
+   /*
+* Before any transactions involving PHY, ensure PHY knows
+* that it's analog rail is powered ON.
+*/
+   mb();
+
+   if (phy-quirks 
+   MSM_UFS_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE) {
+   /*
+* Give atleast 1us delay after restoring PHY analog
+* power.
+*/
+   usleep_range(1, 2);
+   writel_relaxed(0x0A, phy-mmio +
+  QSERDES_COM_SYSCLK_EN_SEL_TXBAND);
+   writel_relaxed(0x08, phy-mmio +
+  QSERDES_COM_SYSCLK_EN_SEL_TXBAND);
+   /*
+* Make sure workaround is deactivated before proceeding
+* with normal PHY operations.
+*/
+   mb();
+   }
+   } else {
+   if (phy-quirks 
+   

Re: [PATCH v2 RESEND 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()

2014-08-12 Thread Alexander Gordeev
On Mon, Aug 11, 2014 at 01:14:54PM -0400, James Smart wrote:
 Alexander,
 
 I haven't looked too deeply, but it's clear it doesn't jive with what we've
 discussed in the past. Your original patches missed several other similar
 sections for revision. I had sent a revised set of patches.
 
 I was also unclear as to the merge path the patches were taking, as it was
 mod'ing areas that have already changed in the scsi misc tree, but the misc
 tree didn' have the pci mods.  I take it this is heading to Christoph's tree
 ?  and that it has picked up the pci mods ?

James,

I lost the context and not sure what PCI modifications you are referring :(
I will send a patch that combines your version shortly.

Thanks!

 -- james s

-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips

2014-08-12 Thread Yaniv Gardi
The files in this change implement the UFS HW (controller  PHY) specific
behavior in Qualcomm MSM chips.

Signed-off-by: Yaniv Gardi yga...@codeaurora.org
---
 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c |  254 +++
 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h |  216 ++
 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c |  368 ++
 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h |  735 
 drivers/scsi/ufs/ufs-msm-phy.c  |  646 ++
 drivers/scsi/ufs/ufs-msm-phy.h  |  193 ++
 drivers/scsi/ufs/ufs-msm.c  | 1119 +++
 drivers/scsi/ufs/ufs-msm.h  |  158 +
 8 files changed, 3689 insertions(+)
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy.c
 create mode 100644 drivers/scsi/ufs/ufs-msm-phy.h
 create mode 100644 drivers/scsi/ufs/ufs-msm.c
 create mode 100644 drivers/scsi/ufs/ufs-msm.h

diff --git a/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c 
b/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
new file mode 100644
index 000..2b48bac
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright (c) 2013-2014, Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/time.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/iopoll.h
+#include linux/platform_device.h
+#include linux/msm-bus.h
+
+#include ufshcd.h
+#include unipro.h
+#include ufs-msm.h
+#include ufs-msm-phy.h
+#include ufs-msm-phy-qmp-20nm.h
+
+#define UFS_PHY_NAME ufs_msm_phy_qmp_20nm
+
+static int ufs_msm_phy_qmp_20nm_phy_calibrate(struct ufs_msm_phy *ufs_msm_phy)
+{
+   struct ufs_msm_phy_calibration *tbl_A, *tbl_B;
+   int tbl_size_A, tbl_size_B;
+   int rate = UFS_MSM_LIMIT_HS_RATE;
+   int err;
+
+   tbl_size_A = ARRAY_SIZE(phy_cal_table_rate_A);
+   tbl_A = phy_cal_table_rate_A;
+
+   tbl_size_B = ARRAY_SIZE(phy_cal_table_rate_B);
+   tbl_B = phy_cal_table_rate_B;
+
+   err = ufs_msm_phy_calibrate(ufs_msm_phy, tbl_A, tbl_size_A,
+   tbl_B, tbl_size_B, rate);
+
+   if (err)
+   dev_err(ufs_msm_phy-dev, %s: ufs_msm_phy_calibrate() failed 
%d\n,
+   __func__, err);
+
+   return err;
+}
+
+static int ufs_msm_phy_qmp_20nm_init(struct phy *generic_phy)
+{
+   struct ufs_msm_phy_qmp_20nm *phy = phy_get_drvdata(generic_phy);
+   struct ufs_msm_phy *phy_common = phy-common_cfg;
+   int err = 0;
+
+   err = ufs_msm_phy_init_clks(generic_phy, phy_common);
+   if (err) {
+   dev_err(phy_common-dev, %s: ufs_msm_phy_init_clks() failed 
%d\n,
+   __func__, err);
+   goto out;
+   }
+
+   err = ufs_msm_phy_init_vregulators(generic_phy, phy_common);
+   if (err)
+   dev_err(phy_common-dev, %s: ufs_msm_phy_init_vregulators() 
failed %d\n,
+   __func__, err);
+
+out:
+   return err;
+}
+
+static
+void ufs_msm_phy_qmp_20nm_power_control(struct ufs_msm_phy *phy, bool val)
+{
+   if (val) {
+   writel_relaxed(0x1, phy-mmio + UFS_PHY_POWER_DOWN_CONTROL);
+   /*
+* Before any transactions involving PHY, ensure PHY knows
+* that it's analog rail is powered ON.
+*/
+   mb();
+
+   if (phy-quirks 
+   MSM_UFS_PHY_QUIRK_HIBERN8_EXIT_AFTER_PHY_PWR_COLLAPSE) {
+   /*
+* Give atleast 1us delay after restoring PHY analog
+* power.
+*/
+   usleep_range(1, 2);
+   writel_relaxed(0x0A, phy-mmio +
+  QSERDES_COM_SYSCLK_EN_SEL_TXBAND);
+   writel_relaxed(0x08, phy-mmio +
+  QSERDES_COM_SYSCLK_EN_SEL_TXBAND);
+   /*
+* Make sure workaround is deactivated before proceeding
+* with normal PHY operations.
+*/
+   mb();
+   }
+   } else {
+   if (phy-quirks 
+   

[PATCH v3 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()

2014-08-12 Thread Alexander Gordeev
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: James Smart james.sm...@emulex.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/lpfc/lpfc_init.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index a5769a9..37f2a20 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8211,9 +8211,9 @@ lpfc_sli4_pci_mem_unset(struct lpfc_hba *phba)
  * @phba: pointer to lpfc hba data structure.
  *
  * This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-3 interface specs. The kernel function pci_enable_msix() is
- * called to enable the MSI-X vectors. Note that pci_enable_msix(), once
- * invoked, enables either all or nothing, depending on the current
+ * with SLI-3 interface specs. The kernel function pci_enable_msix_exact()
+ * is called to enable the MSI-X vectors. Note that pci_enable_msix_exact(),
+ * once invoked, enables either all or nothing, depending on the current
  * availability of PCI vector resources. The device driver is responsible
  * for calling the individual request_irq() to register each MSI-X vector
  * with a interrupt handler, which is done in this function. Note that
@@ -8237,8 +8237,8 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
phba-msix_entries[i].entry = i;
 
/* Configure MSI-X capability structure */
-   rc = pci_enable_msix(phba-pcidev, phba-msix_entries,
-   ARRAY_SIZE(phba-msix_entries));
+   rc = pci_enable_msix_exact(phba-pcidev, phba-msix_entries,
+  LPFC_MSIX_VECTORS);
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0420 PCI enable MSI-X failed (%d)\n, rc);
@@ -8775,16 +8775,14 @@ out:
  * @phba: pointer to lpfc hba data structure.
  *
  * This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-4 interface spec. The kernel function pci_enable_msix() is called
- * to enable the MSI-X vectors. Note that pci_enable_msix(), once invoked,
- * enables either all or nothing, depending on the current availability of
- * PCI vector resources. The device driver is responsible for calling the
- * individual request_irq() to register each MSI-X vector with a interrupt
- * handler, which is done in this function. Note that later when device is
- * unloading, the driver should always call free_irq() on all MSI-X vectors
- * it has done request_irq() on before calling pci_disable_msix(). Failure
- * to do so results in a BUG_ON() and a device will be left with MSI-X
- * enabled and leaks its vectors.
+ * with SLI-4 interface spec. The kernel function pci_enable_msix_range()
+ * is called to enable the MSI-X vectors. The device driver is responsible
+ * for calling the individual request_irq() to register each MSI-X vector
+ * with a interrupt handler, which is done in this function. Note that
+ * later when device is unloading, the driver should always call free_irq()
+ * on all MSI-X vectors it has done request_irq() on before calling
+ * pci_disable_msix(). Failure to do so results in a BUG_ON() and a device
+ * will be left with MSI-X enabled and leaks its vectors.
  *
  * Return codes
  * 0 - successful
@@ -8805,17 +8803,14 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
phba-sli4_hba.msix_entries[index].entry = index;
vectors++;
}
-enable_msix_vectors:
-   rc = pci_enable_msix(phba-pcidev, phba-sli4_hba.msix_entries,
-vectors);
-   if (rc  1) {
-   vectors = rc;
-   goto enable_msix_vectors;
-   } else if (rc) {
+   rc = pci_enable_msix_range(phba-pcidev, phba-sli4_hba.msix_entries,
+  2, vectors);
+   if (rc  0) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
0484 PCI enable MSI-X failed (%d)\n, rc);
goto vec_fail_out;
}
+   vectors = rc;
 
/* Log MSI-X vector assignment */
for (index = 0; index  vectors; index++)
-- 
1.9.3

-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
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


[RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

2014-08-12 Thread Sreekanth Reddy
Sending the this patch once agin using git send-email.

Up to now, Driver allocates a single contiguous block of memory
pool for all reply queues and passes down a single address in the
ReplyDescriptorPostQueueAddress field of the IOC Init Request
Message to the firmware.

When firmware receives this address, it will program each of the
Reply Descriptor Post Queue registers, as each reply queue has its
own register. Thus the firmware, starting from a base address it
determines the starting address of the subsequent reply queues
through some simple arithmetic calculations.

The size of this contiguous block of memory pool is directly proportional
to number of MSI-X vectors and the HBA queue depth. For example higher
MSIX vectors requires larger contiguous block of memory pool.

But some of the OS kernels are unable to allocate this larger
contiguous block of memory pool.

So, the proposal is to allocate memory independently for each
Reply Queue and pass down all of the addresses to the firmware.
Then the firmware will just take each address and program the value
into the correct register.

When HBAs with older firmware(i.e. without RDPQ capability) is used
with this new driver then the max_msix_vectors value would be set
to 8 by default.

Change_set in v2:

1. Declared _base_get_ioc_facts() function at the beginning of the 
mpt2sas_base.c
file instead of moving all these functions before mpt2sas_base_map_resources() 
function
a. _base_wait_for_doorbell_int()
b. _base_wait_for_doorbell_ack()
c. _base_wait_for_doorbell_not_used()
d. _base_handshake_req_reply_wait()
e. _base_get_ioc_facts()

2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit 
mask
after allocating RDPQ pools by calling the function 
_base_change_consistent_dma_mask.
This is to ensure that all the upper 32 bits of RDPQ entries's base address to 
be same.

3. Reduced the redundancy between the RDPQ and non-RDPQ support in these 
following functions
a. _base_release_memory_pools()
b. _base_allocate_memory_pools()
c. _base_send_ioc_init()
d. _base_make_ioc_operational()

Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
 drivers/scsi/mpt2sas/mpt2sas_base.c | 233 +++-
 drivers/scsi/mpt2sas/mpt2sas_base.h |  18 ++-
 2 files changed, 193 insertions(+), 58 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 24d0e52..018ae10 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -92,6 +92,11 @@ static int disable_discovery = -1;
 module_param(disable_discovery, int, 0);
 MODULE_PARM_DESC(disable_discovery,  disable discovery );
 
+static int dma_mask;
+
+static int
+_base_get_ioc_facts(struct MPT2SAS_ADAPTER *ioc, int sleep_flag);
+
 /**
  * _scsih_set_fwfault_debug - global setting of ioc-fwfault_debug.
  *
@@ -1179,17 +1184,22 @@ static int
 _base_config_dma_addressing(struct MPT2SAS_ADAPTER *ioc, struct pci_dev *pdev)
 {
struct sysinfo s;
-   char *desc = NULL;
+   u64 consistent_dma_mask;
+
+   if (dma_mask)
+   consistent_dma_mask = DMA_BIT_MASK(64);
+   else
+   consistent_dma_mask = DMA_BIT_MASK(32);
 
if (sizeof(dma_addr_t)  4) {
const uint64_t required_mask =
dma_get_required_mask(pdev-dev);
if ((required_mask  DMA_BIT_MASK(32))  
!pci_set_dma_mask(pdev,
DMA_BIT_MASK(64))  !pci_set_consistent_dma_mask(pdev,
-   DMA_BIT_MASK(64))) {
+   consistent_dma_mask)) {
ioc-base_add_sg_single = _base_add_sg_single_64;
ioc-sge_size = sizeof(Mpi2SGESimple64_t);
-   desc = 64;
+   dma_mask = 64;
goto out;
}
}
@@ -1198,18 +1208,29 @@ _base_config_dma_addressing(struct MPT2SAS_ADAPTER 
*ioc, struct pci_dev *pdev)
 !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32))) {
ioc-base_add_sg_single = _base_add_sg_single_32;
ioc-sge_size = sizeof(Mpi2SGESimple32_t);
-   desc = 32;
+   dma_mask = 32;
} else
return -ENODEV;
 
  out:
si_meminfo(s);
-   printk(MPT2SAS_INFO_FMT %s BIT PCI BUS DMA ADDRESSING SUPPORTED, 
-   total mem (%ld kB)\n, ioc-name, desc, convert_to_kb(s.totalram));
+   printk(MPT2SAS_INFO_FMT
+   %d BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (%ld kB)\n,
+   ioc-name, dma_mask, convert_to_kb(s.totalram));
 
return 0;
 }
 
+static int
+_base_change_consistent_dma_mask(struct MPT2SAS_ADAPTER *ioc,
+ struct pci_dev *pdev)
+{
+   if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+   if (pci_set_consistent_dma_mask(pdev, 

RE: [PATCH 08/10] [scsi] mpt2sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state.

2014-08-12 Thread Sreekanth Reddy
Driver initialization fails if driver tries to send IOC facts request message 
when the IOC is in reset or in a fault state.

This patch will make sure that
 1.Driver to send IOC facts request message only if HBA is in operational or 
ready state.
 2.If IOC is in fault state, a diagnostic reset would be issued.
 3.If IOC is in reset state then driver will wait for 10 seconds to exit out of 
reset state.
   If the HBA continues to be in reset state, then the HBA wouldn't be claimed 
by the driver.

Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
 drivers/scsi/mpt2sas/mpt2sas_base.c | 65 +
 1 file changed, 65 insertions(+)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 018ae10..dadce5c 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -97,6 +97,9 @@ static int dma_mask;
 static int
 _base_get_ioc_facts(struct MPT2SAS_ADAPTER *ioc, int sleep_flag);
 
+static int
+_base_diag_reset(struct MPT2SAS_ADAPTER *ioc, int sleep_flag);
+
 /**
  * _scsih_set_fwfault_debug - global setting of ioc-fwfault_debug.
  *
@@ -3461,6 +3464,61 @@ _base_get_port_facts(struct MPT2SAS_ADAPTER *ioc, int 
port, int sleep_flag)
 }
 
 /**
+ * _base_wait_for_iocstate - Wait until the card is in READY or OPERATIONAL
+ * @ioc: per adapter object
+ * @timeout:
+ * @sleep_flag: CAN_SLEEP or NO_SLEEP
+ *
+ * Returns 0 for success, non-zero for failure.
+ */
+static int
+_base_wait_for_iocstate(struct MPT2SAS_ADAPTER *ioc, int timeout,
+   int sleep_flag)
+{
+   u32 ioc_state;
+   int rc;
+
+   dinitprintk(ioc, printk(MPT2SAS_INFO_FMT %s\n, ioc-name,
+   __func__));
+
+   if (ioc-pci_error_recovery)
+   return 0;
+
+   ioc_state = mpt2sas_base_get_iocstate(ioc, 0);
+   dhsprintk(ioc, printk(MPT2SAS_INFO_FMT %s: ioc_state(0x%08x)\n,
+   ioc-name, __func__, ioc_state));
+
+   if (((ioc_state  MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_READY) ||
+   (ioc_state  MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_OPERATIONAL)
+   return 0;
+
+   if (ioc_state  MPI2_DOORBELL_USED) {
+   dhsprintk(ioc, printk(MPT2SAS_INFO_FMT
+   unexpected doorbell activ!e\n, ioc-name));
+   goto issue_diag_reset;
+   }
+
+   if ((ioc_state  MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_FAULT) {
+   mpt2sas_base_fault_info(ioc, ioc_state 
+   MPI2_DOORBELL_DATA_MASK);
+   goto issue_diag_reset;
+   }
+
+   ioc_state = _base_wait_on_iocstate(ioc, MPI2_IOC_STATE_READY,
+   timeout, sleep_flag);
+   if (ioc_state) {
+   printk(MPT2SAS_ERR_FMT
+   %s: failed going to ready state (ioc_state=0x%x)\n,
+   ioc-name, __func__, ioc_state);
+   return -EFAULT;
+   }
+
+ issue_diag_reset:
+   rc = _base_diag_reset(ioc, sleep_flag);
+   return rc;
+}
+
+/**
  * _base_get_ioc_facts - obtain ioc facts reply and save in ioc
  * @ioc: per adapter object
  * @sleep_flag: CAN_SLEEP or NO_SLEEP
@@ -3478,6 +3536,13 @@ _base_get_ioc_facts(struct MPT2SAS_ADAPTER *ioc, int 
sleep_flag)
dinitprintk(ioc, printk(MPT2SAS_INFO_FMT %s\n, ioc-name,
__func__));
 
+   r = _base_wait_for_iocstate(ioc, 10, sleep_flag);
+   if (r) {
+   printk(MPT2SAS_ERR_FMT %s: failed getting to correct state\n,
+   ioc-name, __func__);
+   return r;
+   }
+
mpi_reply_sz = sizeof(Mpi2IOCFactsReply_t);
mpi_request_sz = sizeof(Mpi2IOCFactsRequest_t);
memset(mpi_request, 0, mpi_request_sz);
-- 
2.0.2

--
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: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

2014-08-12 Thread Joe Perches
On Tue, 2014-08-12 at 14:54 +0530, Sreekanth Reddy wrote:
 So, the proposal is to allocate memory independently for each
 Reply Queue and pass down all of the addresses to the firmware.
 Then the firmware will just take each address and program the value
 into the correct register.

trivial note:

 diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
 b/drivers/scsi/mpt2sas/mpt2sas_base.c
[]
 @@ -1179,17 +1184,22 @@ static int
  _base_config_dma_addressing(struct MPT2SAS_ADAPTER *ioc, struct pci_dev 
 *pdev)
  {
   struct sysinfo s;
 - char *desc = NULL;
 + u64 consistent_dma_mask;
 +
 + if (dma_mask)
 + consistent_dma_mask = DMA_BIT_MASK(64);
 + else
 + consistent_dma_mask = DMA_BIT_MASK(32);
  
   if (sizeof(dma_addr_t)  4) {
   const uint64_t required_mask =
   dma_get_required_mask(pdev-dev);
   if ((required_mask  DMA_BIT_MASK(32))  
 !pci_set_dma_mask(pdev,
   DMA_BIT_MASK(64))  !pci_set_consistent_dma_mask(pdev,
 - DMA_BIT_MASK(64))) {
 + consistent_dma_mask)) {

This would be easier to read if the embedded functions
within the if were on separate lines like:

if ((required_mask  DMA_BIT_MASK(32)) 
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) 
!pci_set_consistent_dma_mask(pdev, consistent_dma_mask)) {


--
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: [RESEND][PATCH 7/8][SCSI]mpt3sas: Added Reply Descriptor Post Queue (RDPQ) Array support

2014-08-12 Thread Sreekanth Reddy
Sending this patch once again using git send-email.

Up to now, Driver allocates a single contiguous block of memory
pool for all reply queues and passes down a single address in the
ReplyDescriptorPostQueueAddress field of the IOC Init Request
Message to the firmware.

When firmware receives this address, it will program each of the
Reply Descriptor Post Queue registers, as each reply queue has its
own register. Thus the firmware, starting from a base address it
determines the starting address of the subsequent reply queues
through some simple arithmetic calculations.

The size of this contiguous block of memory pool is directly proportional
to number of MSI-X vectors and the HBA queue depth. For example higher
MSIX vectors requires larger contiguous block of memory pool.

But some of the OS kernels are unable to allocate this larger
contiguous block of memory pool.

So, the proposal is to allocate memory independently for each
Reply Queue and pass down all of the addresses to the firmware.
Then the firmware will just take each address and program the value
into the correct register.

When HBAs with older firmware(i.e. without RDPQ capability) is used
with this new driver then the max_msix_vectors value would be set
to 8 by default.

Change set in v2:

1. Declared the _base_get_ioc_facts() functions at the beginning of the 
mpt3sas_base.c file
instead of moving all these functions before mpt3sas_base_map_resources() 
function
a. _base_wait_for_doorbell_int()
b. _base_wait_for_doorbell_ack()
c. _base_wait_for_doorbell_not_used()
d. _base_handshake_req_reply_wait()
e. _base_get_ioc_facts()

2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit 
mask
after allocating RDPQ pools by calling the function 
_base_change_consistent_dma_mask.
This is to ensure that all the upper 32 bits of RDPQ entries's base address to 
be same.

3. Reduced the redundancy between the RDPQ and non-RDPQ support in these 
following functions
a. _base_release_memory_pools()
b. _base_allocate_memory_pools()
c. _base_send_ioc_init()
d. _base_make_ioc_operational()

Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 231 +++-
 drivers/scsi/mpt3sas/mpt3sas_base.h |  18 ++-
 2 files changed, 189 insertions(+), 60 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index d71f135..408eb81 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -92,6 +92,11 @@ MODULE_PARM_DESC(mpt3sas_fwfault_debug,
 enable detection of firmware fault and halt firmware - (default=0));
 
 
+static int dma_mask;
+
+static int
+_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+
 /**
  * _scsih_set_fwfault_debug - global setting of ioc-fwfault_debug.
  *
@@ -1482,17 +1487,23 @@ static int
 _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev)
 {
struct sysinfo s;
-   char *desc = NULL;
+   u64 consistent_dma_mask;
+
+   if (dma_mask)
+   consistent_dma_mask = DMA_BIT_MASK(64);
+   else
+   consistent_dma_mask = DMA_BIT_MASK(32);
 
if (sizeof(dma_addr_t)  4) {
const uint64_t required_mask =
dma_get_required_mask(pdev-dev);
if ((required_mask  DMA_BIT_MASK(32)) 
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) 
-   !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+   !pci_set_consistent_dma_mask(pdev,
+ DMA_BIT_MASK(consistent_dma_mask))) {
ioc-base_add_sg_single = _base_add_sg_single_64;
ioc-sge_size = sizeof(Mpi2SGESimple64_t);
-   desc = 64;
+   dma_mask = 64;
goto out;
}
}
@@ -1501,19 +1512,30 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER 
*ioc, struct pci_dev *pdev)
 !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32))) {
ioc-base_add_sg_single = _base_add_sg_single_32;
ioc-sge_size = sizeof(Mpi2SGESimple32_t);
-   desc = 32;
+   dma_mask = 32;
} else
return -ENODEV;
 
  out:
si_meminfo(s);
pr_info(MPT3SAS_FMT
-   %s BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (%ld kB)\n,
-   ioc-name, desc, convert_to_kb(s.totalram));
+   %d BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (%ld kB)\n,
+   ioc-name, dma_mask, convert_to_kb(s.totalram));
 
return 0;
 }
 
+static int
+_base_change_consistent_dma_mask(struct MPT3SAS_ADAPTER *ioc,
+ struct pci_dev *pdev)
+{
+   if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ 

Re: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

2014-08-12 Thread Sreekanth Reddy
On Tue, Aug 12, 2014 at 3:07 PM, Joe Perches j...@perches.com wrote:
 On Tue, 2014-08-12 at 14:54 +0530, Sreekanth Reddy wrote:
 So, the proposal is to allocate memory independently for each
 Reply Queue and pass down all of the addresses to the firmware.
 Then the firmware will just take each address and program the value
 into the correct register.

 trivial note:

 diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
 b/drivers/scsi/mpt2sas/mpt2sas_base.c
 []
 @@ -1179,17 +1184,22 @@ static int
  _base_config_dma_addressing(struct MPT2SAS_ADAPTER *ioc, struct pci_dev 
 *pdev)
  {
   struct sysinfo s;
 - char *desc = NULL;
 + u64 consistent_dma_mask;
 +
 + if (dma_mask)
 + consistent_dma_mask = DMA_BIT_MASK(64);
 + else
 + consistent_dma_mask = DMA_BIT_MASK(32);

   if (sizeof(dma_addr_t)  4) {
   const uint64_t required_mask =
   dma_get_required_mask(pdev-dev);
   if ((required_mask  DMA_BIT_MASK(32))  
 !pci_set_dma_mask(pdev,
   DMA_BIT_MASK(64))  !pci_set_consistent_dma_mask(pdev,
 - DMA_BIT_MASK(64))) {
 + consistent_dma_mask)) {

 This would be easier to read if the embedded functions
 within the if were on separate lines like:

Accepted. next time onwards I will take care of this.


 if ((required_mask  DMA_BIT_MASK(32)) 
 !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) 
 !pci_set_consistent_dma_mask(pdev, consistent_dma_mask)) {


--
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: [RESEND][PATCH 8/8][SCSI]mpt3sas: Bump mpt3sas driver version to 04.100.00.00

2014-08-12 Thread Sreekanth Reddy
Hi Martin,

Among the mpt3sas phase2 and phase3 patch set, following are the
patches which you have completed the review

1. [RESEND][PATCH 1/8][SCSI]mpt3sas: MPI2.5 Rev G (2.5.2) specifications
2. [RESEND][PATCH 2/8][SCSI]mpt3sas: Clear PFA Status on SGPIO when
PFA Drive is Removed or Replaced
3. [RESEND][PATCH 3/8][SCSI]mpt3sas: Bump mpt3sas driver version to 03.100.00.00
4. [RESEND][PATCH 4/8][SCSI]mpt3sas: MPI2.5 Rev H (2.5.3) specifications
5. [RESEND][PATCH 5/8][SCSI]mpt3sas: Copyright in driver sources is
updated for year the 2014
6. [RESEND][PATCH 6/8][SCSI]mpt3sas: Added OEM branding Strings
7. [RESEND][PATCH 8/8][SCSI]mpt3sas: Bump mpt3sas driver version to 04.100.00.00

Following below single patch which is remained for review completion

1. [RESEND][PATCH 7/8][SCSI]mpt3sas: Added Reply Descriptor Post Queue
(RDPQ) Array support

So, Can you please review this patch, so that I can repost this patch
set once again by appending your Signed-off-by signature.

Regards,
Sreekanth

On Tue, Jul 15, 2014 at 10:26 PM, Martin K. Petersen
martin.peter...@oracle.com wrote:
 Sreekanth == Reddy, Sreekanth sreekanth.re...@avagotech.com writes:

 Sreekanth Bump mpt3sas driver version to 04.100.00.00.

 Reviewed-by: Martin K. Petersen martin.peter...@oracle.com

 --
 Martin K. Petersen  Oracle Linux Engineering
--
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: [RESEND][PATCH 10/10][SCSI]mpt2sas: Bump mpt2sas driver version to 18.100.00.00

2014-08-12 Thread Sreekanth Reddy
Hi Martin,

Among the mpt2sas phase17 and phase18 patch set, following are the
patches which you have completed the review

1. [RESEND][PATCH 01/10][SCSI]mpt2sas: Added driver module parameter
max_msix_vectors
2. [RESEND][PATCH 02/10][SCSI]mpt2sas: MPI2 Rev Y (2.00.17) and Rev Z
(2.00.18) specifications
3. [RESEND][PATCH 03/10][SCSI]mpt2sas: Copyright in driver sources is
updated for year the 2014
4. [RESEND][PATCH 04/10][SCSI]mpt2sas: Clear PFA Status on SGPIO when
PFA Drive is Removed or Replaced
5. [RESEND][PATCH 05/10][SCSI]mpt2sas: Bump mpt2sas driver version to
17.100.00.00
6. [PATCH] [SCSI] mpt2sas: Avoid type casting for direct I/O commands
7. [RESEND][PATCH 10/10][SCSI]mpt2sas: Bump mpt2sas driver version to
18.100.00.00

Following are the patches which are remain for review completion

1. [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post
Queue (RDPQ) Array support
2. [RESEND][PATCH 08/10] [scsi] mpt2sas: Get IOC_FACTS information
using handshake protocol only after HBA card gets into READY or
Operational state.
3. [RESEND][PATCH 09/10][SCSI]mpt2sas: Added module parameter
'unblock_io' to unblock IO's during disk

So, Can you please review these three patches, so that I can repost
this patch set once again by appending your Signed-off-by signature.

Regards,
Sreekanth


On Tue, Jul 15, 2014 at 10:21 PM, Martin K. Petersen
martin.peter...@oracle.com wrote:
 Sreekanth == Reddy, Sreekanth sreekanth.re...@avagotech.com writes:

 Sreekanth Bump mpt2sas driver version to 18.100.00.00.

 Reviewed-by: Martin K. Petersen martin.peter...@oracle.com

 --
 Martin K. Petersen  Oracle Linux Engineering
--
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 v2 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead of pci_enable_msix()

2014-08-12 Thread Alexander Gordeev
On Mon, Aug 11, 2014 at 11:02:56AM +, Anil Gurumurthy wrote:
 Acked-by: Anil Gurumurthy anil.gurumur...@qlogic.com

Many thanks, Anil!

If your Ack apply to this patch only or to all three
'bfa' patches in this series?

Thanks!

 -Original Message-
 From: Alexander Gordeev [mailto:agord...@redhat.com] 
 Sent: 11 August 2014 13:09
 To: linux-kernel
 Cc: Anil Gurumurthy; Vijaya Mohan Guvva; linux-scsi; linux-pci; Anil 
 Gurumurthy; Sudarsana Kalluru
 Subject: Re: [PATCH v2 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead 
 of pci_enable_msix()
 
 On Wed, Jul 16, 2014 at 08:05:08PM +0200, Alexander Gordeev wrote:
  As result of deprecation of MSI-X/MSI enablement functions
  pci_enable_msix() and pci_enable_msi_block() all drivers using these 
  two interfaces need to be updated to use the new 
  pci_enable_msi_range()  or pci_enable_msi_exact() and 
  pci_enable_msix_range() or pci_enable_msix_exact() interfaces.
 
 Anil, Sudarsana,
 
 Could you please review bfa patches in this series?
 
 Thanks!
 
  Signed-off-by: Alexander Gordeev agord...@redhat.com
  Cc: Anil Gurumurthy aguru...@brocade.com
  Cc: Vijaya Mohan Guvva vmo...@brocade.com
  Cc: linux-scsi@vger.kernel.org
  Cc: linux-...@vger.kernel.org
  Acked-by: Anil Gurumurthy anil.gurumur...@qlogic.com
  ---
   drivers/scsi/bfa/bfad.c |   20 ++--
   1 files changed, 6 insertions(+), 14 deletions(-)
  
  diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c index 
  c18279f..e90a374 100644
  --- a/drivers/scsi/bfa/bfad.c
  +++ b/drivers/scsi/bfa/bfad.c
  @@ -1234,29 +1234,21 @@ bfad_setup_intr(struct bfad_s *bfad)
  if ((bfa_asic_id_ctc(pdev-device)  !msix_disable_ct) ||
 (bfa_asic_id_cb(pdev-device)  !msix_disable_cb)) {
   
  -   error = pci_enable_msix(bfad-pcidev, msix_entries, bfad-nvec);
  +   error = pci_enable_msix_exact(bfad-pcidev,
  + msix_entries, bfad-nvec);
  /* In CT1  CT2, try to allocate just one vector */
  -   if (error  0  bfa_asic_id_ctc(pdev-device)) {
  +   if (error == -ENOSPC  bfa_asic_id_ctc(pdev-device)) {
  printk(KERN_WARNING bfa %s: trying one msix 
 vector failed to allocate %d[%d]\n,
 bfad-pci_name, bfad-nvec, error);
  bfad-nvec = 1;
  -   error = pci_enable_msix(bfad-pcidev,
  -   msix_entries, bfad-nvec);
  +   error = pci_enable_msix_exact(bfad-pcidev,
  + msix_entries, 1);
  }
   
  -   /*
  -* Only error number of vector is available.
  -* We don't have a mechanism to map multiple
  -* interrupts into one vector, so even if we
  -* can try to request less vectors, we don't
  -* know how to associate interrupt events to
  -*  vectors. Linux doesn't duplicate vectors
  -* in the MSIX table for this case.
  -*/
  if (error) {
  printk(KERN_WARNING bfad%d: 
  -  pci_enable_msix failed (%d), 
  +  pci_enable_msix_exact failed (%d), 
 use line based.\n,
  bfad-inst_no, error);
  goto line_based;
  --
  1.7.7.6
  

-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
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: [Xen-devel] [PATCH V4 2/4] Introduce xen-scsifront module

2014-08-12 Thread Juergen Gross

On 08/11/2014 07:50 PM, Christoph Hellwig wrote:

On Mon, Aug 11, 2014 at 12:27:29PM +0200, Juergen Gross wrote:

What do you mean with unusual? You mean transferring the EH action to
Dom0?


Yes.  Note that hyperv tries something similar and they've run into
timeout issues, you might want to read up the recent thread on that.


+   } else {
+   xenbus_printf(XBT_NIL, dev-nodename,
+ state_str, %d,
+ XenbusStateConnected);
+   }


Just print this message in -slave_configure.


This is calling for problems, I think. xenbus_printf() is not just a
printing function, but it changes an entry in the xenstore. And this
requires locking, switching threads, ...

I doubt doing this while holding SCSI-internal locks is a good idea.


Oh, I thought xenbus_printf was just a logging wrapper.

Doing major work in the slave_* callouts is not a problem, that's what
they were designed for.


Okay.



For the successful case the xenbus_printf should be done in
-slave_configure.  For the failure case you probably want to do it
from -slave_destroy based on the absence of a flag set in -slave_configure,
e.g. in slave_configure:

sdev-hostdata = (void *)1UL;

and in -slave_destroy:

if (!sdev-hostdata)


I don't think I'll need the flag. The action is the same if the device
is being destroyed again because of already existing or when it is
really removed.


...

although you might see something like this based on external scanning
through procfs/sysfs as mentioned earlier, so please take a look at
how all these corner cases could effect you.


I'll add a check if .slave_configure() and .slave_destroy() are running
in the same task as scsi_add_device() or scsi_remove_device(). This
should rule out all of these corner cases.


Juergen

--
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: [Xen-devel] [PATCH V4 3/4] Introduce XEN scsiback module

2014-08-12 Thread Juergen Gross

On 08/11/2014 08:14 PM, Christoph Hellwig wrote:

+#include scsi/scsi_dbg.h


__scsi_print_sense()


+#include scsi/scsi_eh.h


struct scsi_sense_hdr


+#include scsi/scsi_tcq.h


SG_ALL



What do you need these for?  Normally target drivers shouldn't need
these.


+struct vscsibk_emulate {
+   void (*pre_function)(struct vscsibk_pend *, void *);
+   void (*post_function)(struct vscsibk_pend *, void *);
+};


This doesn't seem to be used.


Correct. Will delete.




+#define scsiback_get(_b) (atomic_inc((_b)-nr_unreplied_reqs))
+#define scsiback_put(_b)   \
+   do {\
+   if (atomic_dec_and_test((_b)-nr_unreplied_reqs))   \
+   wake_up((_b)-waiting_to_free);\
+   } while (0)


Normal Linux style would be to make these inline functions.


Okay. I'll change those.




+static void scsiback_notify_work(struct vscsibk_info *info)
+{
+   info-waiting_reqs = 1;
+   wake_up(info-wq);
+}
+
+static irqreturn_t scsiback_intr(int irq, void *dev_id)
+{
+   scsiback_notify_work((struct vscsibk_info *)dev_id);
+   return IRQ_HANDLED;
+}


Seems like this driver should get the same threaded irq treatment as
the initiator side?


Indeed.




+static void scsiback_disconnect(struct vscsibk_info *info)
+{
+   if (info-kthread) {
+   kthread_stop(info-kthread);
+   info-kthread = NULL;
+   wake_up(info-shutdown_wq);
+   }
+
+   wait_event(info-waiting_to_free,
+   atomic_read(info-nr_unreplied_reqs) == 0);
+
+   if (info-irq) {
+   unbind_from_irqhandler(info-irq, info);
+   info-irq = 0;
+   }
+
+   if (info-ring.sring) {
+   xenbus_unmap_ring_vfree(info-dev, info-ring.sring);
+   info-ring.sring = NULL;
+   }
+}


Also the same treatment for goto based init failure unwinding.


Yep.


Juergen

--
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: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

2014-08-12 Thread Elliott, Robert (Server Storage)


 -Original Message-
 From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
 ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE
 Sent: Friday, 08 August, 2014 6:50 AM
...
 Subject: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in
 __scsi_print_sense()
 
 A device name is output like sda: Sense Key : Medium Error [current]
 in __scsi_print_sense(), but it should be [sda] Sense Key : Medium Error
 [current] because other printk messages output a device name like [sda]
 foo.
 
...
 diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
 index c6a7a4a..a0e8159 100644
 --- a/drivers/scsi/constants.c
 +++ b/drivers/scsi/constants.c
 @@ -1470,7 +1470,7 @@ void __scsi_print_sense(struct scsi_device *sdev,
 const char *name,
   return;
   }
 
 - sdev_printk(KERN_INFO, sdev, %s: Sense Key : %s %s%s\n, name,
 + sdev_printk(KERN_INFO, sdev, [%s] Sense Key : %s %s%s\n, name,
  scsi_sense_key_string(sshdr.sense_key),
  scsi_sense_type_string(sshdr),
  scsi_sense_format_string(sshdr));
 


The callers of __scsi_print_sense do not always pass in a name
like sda.  In fact, sd.c doesn't even call that function; its
sd_print_sense_hdr calls sd_printk (which prints name as [%s])
and scsi_show_sense_hdr.

There are just 3 kernel files that call this function:
osst.c: __scsi_print_sense(osst , SRpnt-sense, 
SCSI_SENSE_BUFFERSIZE);
osst.c: __scsi_print_sense(osst , SRpnt-sense, 
SCSI_SENSE_BUFFERSIZE);
There is a separate call to printk just before each of those,
which prints out the name, without [].

sg.c:   __scsi_print_sense(__func__, sense,
That's printing the C function name.

st.c:__scsi_print_sense(name, SRpnt-sense, 
SCSI_SENSE_BUFFERSIZE);
st.c:   __scsi_print_sense(name, SRpnt-sense, 
SCSI_SENSE_BUFFERSIZE);
This is more like what you have in mind.


---
Rob ElliottHP Server Storage


N�r��yb�X��ǧv�^�)޺{.n�+{{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler - general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0

2014-08-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=81861

--- Comment #3 from linux-...@crashplan.pro ---
Because Ubuntu doesn't provide debug symbols for their mainline kernel builds
http://comments.gmane.org/gmane.linux.ubuntu.devel.kernel.general/40661 I am
reverting back to their kernel version 3.13.0-24.46

That results in a kernel crash on port 8C: 
BUG: unable to handle kernel NULL pointer dereference at 0255

Full output:
[   25.212661] mvsas :01:00.0: mvsas: driver version 0.8.16
[   25.212703] mvsas :01:00.0: enabling device ( - 0002)
[   25.213249] mvsas :01:00.0: mvsas: PCI-E x8, Bandwidth Usage: 5.0 Gbps
[   31.994771] scsi5 : mvsas
[   31.995530] sas: phy-5:0 added to port-5:0, phy_mask:0x1 (50014380182cf0e6)
[   31.995564] /build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c 1218:set
wide port phy map 1
[   32.005672] sas: phy1 matched wide port0
[   32.005695] sas: phy-5:1 added to port-5:0, phy_mask:0x3 (50014380182cf0e6)
[   32.005720] /build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c 1218:set
wide port phy map 3
[   32.025591] sas: phy2 matched wide port0
[   32.025611] sas: phy-5:2 added to port-5:0, phy_mask:0x7 (50014380182cf0e6)
[   32.025635] /build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c 1218:set
wide port phy map 7
[   32.055410] sas: phy3 matched wide port0
[   32.055427] sas: phy-5:3 added to port-5:0, phy_mask:0xf (50014380182cf0e6)
[   32.055452] /build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c 1218:set
wide port phy map f
[   32.095144] sas: DOING DISCOVERY on port 0, pid:127
[   32.096843] sas: ex 50014380182cf0e6 phy00:D:0 attached: 
(no device)
[   32.097408] sas: ex 50014380182cf0e6 phy01:D:0 attached: 
(no device)
[   32.097917] sas: ex 50014380182cf0e6 phy02:D:0 attached: 
(no device)
[   32.098503] sas: ex 50014380182cf0e6 phy03:D:0 attached: 
(no device)
[   32.099044] sas: ex 50014380182cf0e6 phy04:D:0 attached: 
(no device)
[   32.099628] sas: ex 50014380182cf0e6 phy05:D:0 attached: 
(no device)
[   32.100205] sas: ex 50014380182cf0e6 phy06:D:0 attached: 
(no device)
[   32.100739] sas: ex 50014380182cf0e6 phy07:D:0 attached: 
(no device)
[   32.101310] sas: ex 50014380182cf0e6 phy08:D:0 attached: 
(no device)
[   32.101840] sas: ex 50014380182cf0e6 phy09:D:0 attached: 
(no device)
[   32.102412] sas: ex 50014380182cf0e6 phy10:D:0 attached: 
(no device)
[   32.102959] sas: ex 50014380182cf0e6 phy11:D:0 attached: 
(no device)
[   32.103545] sas: ex 50014380182cf0e6 phy12:D:0 attached: 
(no device)
[   32.104128] sas: ex 50014380182cf0e6 phy13:D:0 attached: 
(no device)
[   32.104661] sas: ex 50014380182cf0e6 phy14:D:0 attached: 
(no device)
[   32.105273] sas: ex 50014380182cf0e6 phy15:D:0 attached: 
(no device)
[   32.105781] sas: ex 50014380182cf0e6 phy16:D:0 attached: 
(no device)
[   32.106385] sas: ex 50014380182cf0e6 phy17:D:0 attached: 
(no device)
[   32.106904] sas: ex 50014380182cf0e6 phy18:D:0 attached: 
(no device)
[   32.107486] sas: ex 50014380182cf0e6 phy19:D:0 attached: 
(no device)
[   32.108020] sas: ex 50014380182cf0e6 phy20:D:0 attached: 
(no device)
[   32.108605] sas: ex 50014380182cf0e6 phy21:D:0 attached: 
(no device)
[   32.109183] sas: ex 50014380182cf0e6 phy22:D:0 attached: 
(no device)
[   32.109714] sas: ex 50014380182cf0e6 phy23:D:0 attached: 
(no device)
[   32.110357] sas: ex 50014380182cf0e6 phy24:U:A attached: 5005043011ab
(host)
[   32.110929] sas: ex 50014380182cf0e6 phy25:U:A attached: 5005043011ab
(host)
[   32.111558] sas: ex 50014380182cf0e6 phy26:U:A attached: 5005043011ab
(host)
[   32.112181] sas: ex 50014380182cf0e6 phy27:U:A attached: 5005043011ab
(host)
[   32.112774] sas: ex 50014380182cf0e6 phy28:S:9 attached: 50014380182cf0dc
(stp)
[   32.113366] sas: ex 50014380182cf0e6 phy29:S:9 attached: 50014380182cf0dd
(stp)
[   32.113934] sas: ex 50014380182cf0e6 phy30:S:9 attached: 50014380182cf0de
(stp)
[   32.114557] sas: ex 50014380182cf0e6 phy31:S:9 attached: 50014380182cf0df
(stp)
[   32.115138] sas: ex 50014380182cf0e6 phy32:S:0 attached: 
(no device)
[   32.115654] sas: ex 50014380182cf0e6 phy33:S:0 attached: 
(no device)
[   32.116198] sas: ex 50014380182cf0e6 phy34:S:0 attached: 
(no device)
[   32.116711] sas: ex 50014380182cf0e6 phy35:S:0 attached: 
(no device)
[   32.117003] sas: ex 50014380182cf0e6 phy36:D:A attached: 50014380182cf0e5
(host+target)
[   32.118398] sas: DONE DISCOVERY on port 0, pid:127, result:0
[   32.118435] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[   32.118465] sas: ata6: 

Re: [PATCH V4 3/4] Introduce XEN scsiback module

2014-08-12 Thread Nicholas A. Bellinger
Hi Juergen  Co,

Finally had a chance to review this code.  Comments are inline below..

On Fri, 2014-08-08 at 09:49 +0200, jgr...@suse.com wrote:
 From: Juergen Gross jgr...@suse.com
 
 Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU
 to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
 are passed to the pvSCSI backend in a driver domain (usually Dom0) which is
 owner of the physical device. This allows e.g. to use SCSI tape drives in a
 XEN domU.
 
 The code is taken from the pvSCSI implementation in XEN done by Fujitsu based
 on Linux kernel 2.6.18.
 
 Changes from the original version are:
 - port to upstream kernel
 - put all code in just one source file
 - adapt to Linux style guide
 - use target core infrastructure instead doing pure pass-through
 - enable module unloading
 - support SG-list in grant page(s)
 - support task abort
 - remove redundant struct backend
 - allocate resources dynamically
 - correct minor error in scsiback_fast_flush_area
 - free allocated resources in case of error during I/O preparation
 - remove CDB emulation, now handled by target core infrastructure
 
 Signed-off-by: Juergen Gross jgr...@suse.com
 
 Xen related parts
 Acked-by: David Vrabel david.vra...@citrix.com
 ---

SNIP

 diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
 new file mode 100644
 index 000..4a0d6e3
 --- /dev/null
 +++ b/drivers/xen/xen-scsiback.c

SNIP

 +struct scsiback_nacl {
 + /* Binary World Wide unique Port Name for pvscsi Initiator port */
 + u64 iport_wwpn;
 + /* ASCII formatted WWPN for Sas Initiator port */
 + char iport_name[VSCSI_NAMELEN];
 + /* Returned by scsiback_make_nodeacl() */
 + struct se_node_acl se_node_acl;
 +};
 +

Given that this code is similar to how loopback + vhost-scsi function,
and uses a (locally) generated nexus for each WWPN endpoint, the
scsiback_nacl and associated code will be unused should be be dropped.

SNIP

 +static void scsiback_do_resp_with_sense(char *sense_buffer, int32_t result,
 + uint32_t resid, struct vscsibk_pend *pending_req)
 +{
 + struct vscsiif_response *ring_res;
 + struct vscsibk_info *info = pending_req-info;
 + int notify;
 + struct scsi_sense_hdr sshdr;
 + unsigned long flags;
 + unsigned len;
 +
 + spin_lock_irqsave(info-ring_lock, flags);
 +
 + ring_res = RING_GET_RESPONSE(info-ring, info-ring.rsp_prod_pvt);
 + info-ring.rsp_prod_pvt++;
 +
 + ring_res-rslt   = result;
 + ring_res-rqid   = pending_req-rqid;
 +
 + if (sense_buffer != NULL 
 + scsi_normalize_sense(sense_buffer, VSCSIIF_SENSE_BUFFERSIZE,
 +  sshdr)) {
 + len = min_t(unsigned, 8 + sense_buffer[7],
 + VSCSIIF_SENSE_BUFFERSIZE);
 + memcpy(ring_res-sense_buffer, sense_buffer, len);
 + ring_res-sense_len = len;
 + } else {
 + ring_res-sense_len = 0;
 + }
 +
 + ring_res-residual_len = resid;
 +
 + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(info-ring, notify);
 + spin_unlock_irqrestore(info-ring_lock, flags);
 +
 + if (notify)
 + notify_remote_via_irq(info-irq);
 +
 + if (pending_req-v2p)
 + kref_put(pending_req-v2p-kref,
 +  scsiback_free_translation_entry);
 +
 + kmem_cache_free(scsiback_cachep, pending_req);
 +}
 +
 +static void scsiback_cmd_done(struct vscsibk_pend *pending_req)
 +{
 + struct vscsibk_info *info = pending_req-info;
 + unsigned char *sense_buffer;
 + unsigned int resid;
 + int errors;
 +
 + sense_buffer = pending_req-sense_buffer;
 + resid= pending_req-se_cmd.residual_count;
 + errors   = pending_req-result;
 +
 + if (errors  log_print_stat)
 + scsiback_print_status(sense_buffer, errors, pending_req);
 +
 + scsiback_fast_flush_area(pending_req);
 + scsiback_do_resp_with_sense(sense_buffer, errors, resid, pending_req);
 + scsiback_put(info);
 +
 + transport_generic_free_cmd(pending_req-se_cmd, 0);
 +}
 +

The usage here of scsiback_do_resp_with_sense() - kmem_cache_free() for
*pending_req, and then invoking transport_generic_free_cmd() with
pending_req-se_cmd is an free after use bug..

So the way this should work is similar to how loopback currently does
things:

  - Move the kmem_cache_free() for pending_req from 
scsiback_do_resp_with_sense() to scsiback_release_cmd()
  - Remove the transport_generic_free_cmd() from scsiback_cmd_done()
  - Copy what tcm_loop_check_stop_free() does into 
scsiback_check_stop_free(), and remove target_put_sess_cmd()

 +static void scsiback_cmd_exec(struct vscsibk_pend *pending_req)
 +{
 + struct se_cmd *se_cmd = pending_req-se_cmd;
 + struct se_session *sess = pending_req-v2p-tpg-tpg_nexus-tvn_se_sess;
 + int rc;
 +
 + memset(pending_req-sense_buffer, 0, VSCSIIF_SENSE_BUFFERSIZE);
 +
 + 

[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler - general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0

2014-08-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=81861

--- Comment #4 from linux-...@crashplan.pro ---
Trying to debug mvs_task_prep with the help of the tutorial at
http://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/.

# cat /sys/module/mvsas/sections/.init.text
0xa00c8000

# cd /lib/modules/3.13.0-24-generic/kernel/drivers/scsi/mvsas

# gdb mvsas.ko

(gdb) add-symbol-file
/usr/lib/debug/lib/modules/3.13.0-24-generic/kernel/drivers/scsi/mvsas/mvsas.ko
0xa00c8000

(gdb) disassemble mvs_task_prep

Hex to decimal: 0x72e = +1838

0xa00ca81e +1838:mov0x254(%rbx),%ecx

Thanks to the trick from
https://blogs.oracle.com/ksplice/entry/8_gdb_tricks_you_should
(gdb) set substitute-path /build/buildd /home/user/src

(gdb) list *0xa00ca81e
0xa00ca81e is in mvs_task_prep
(/build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c:471).
Line number 466 out of range;
/build/buildd/linux-3.13.0/drivers/scsi/mvsas/mv_sas.c has 306 lines.

I guess my gdb version 7.7 has a line counting bug according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730630

A manual approach using
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=blob;f=drivers/scsi/mvsas/mv_sas.c;h=6c1f223a8e1d335fa7c86a374e470e666e848906;hb=HEAD:

467 slot = mvi-slot_info[tag];
468 slot-tx = mvi-tx_prod;
469 del_q = TXQ_MODE_I | tag |
470 (TXQ_CMD_STP  TXQ_CMD_SHIFT) |
471 (MVS_PHY_ID  TXQ_PHY_SHIFT) |
472 (mvi_dev-taskfileset  TXQ_SRS_SHIFT);
473 mvi-tx[mvi-tx_prod] = cpu_to_le32(del_q);

Results that (MVS_PHY_ID  TXQ_PHY_SHIFT) is the offending code.

How should that be patched?

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


[PATCH v3 2/3] cxgb4: use module_long_probe_init()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com

cxgb4 probe can take up to over 1 minute when the firmware is
is written and installed on the device, even after this the device
driver still does some device probing and can take quite a bit.
This driver needs fixing but right now it simply wont' work on
some systems. Use the new module_long_probe_init() to annotate
this driver's probe is broken and require some love, but makes
the driver operational until that is fixed.

Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Joseph Salisbury joseph.salisb...@canonical.com
Cc: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk
Cc: Tim Gardner tim.gard...@canonical.com
Cc: Pierre Fersing pierre-fers...@pierref.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Benjamin Poirier bpoir...@suse.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Hariprasad S haripra...@chelsio.com
Cc: Santosh Rastapur sant...@chelsio.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 36ebbda..5d8231d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -34,6 +34,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME :  fmt
 
+#include linux/kthread.h
 #include linux/bitmap.h
 #include linux/crc32.h
 #include linux/ctype.h
@@ -6815,5 +6816,5 @@ static void __exit cxgb4_cleanup_module(void)
destroy_workqueue(workq);
 }
 
-module_init(cxgb4_init_module);
-module_exit(cxgb4_cleanup_module);
+module_long_probe_init(cxgb4_init_module);
+module_long_probe_exit(cxgb4_cleanup_module);
-- 
2.0.3

--
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 v3 3/3] mptsas: use module_long_probe_init()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com

Its reported that mptsas can at times take over 30 seconds
to recognize SCSI storage devices [0], this is done on the
driver's probe path. Use the the new module_long_probe_init()
to annotate this driver's probe is broken and require some love,
but makes the driver operational until that is fixed.

[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705

Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Joseph Salisbury joseph.salisb...@canonical.com
Cc: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk
Cc: Tim Gardner tim.gard...@canonical.com
Cc: Pierre Fersing pierre-fers...@pierref.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Benjamin Poirier bpoir...@suse.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Hariprasad S haripra...@chelsio.com
Cc: Santosh Rastapur sant...@chelsio.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/message/fusion/mptsas.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 0707fa2..c2bb72b 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -43,6 +43,7 @@
 */
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 
+#include linux/kthread.h
 #include linux/module.h
 #include linux/kernel.h
 #include linux/slab.h
@@ -5439,5 +5440,5 @@ mptsas_exit(void)
mpt_deregister(mptsasDeviceResetCtx);
 }
 
-module_init(mptsas_init);
-module_exit(mptsas_exit);
+module_long_probe_init(mptsas_init);
+module_long_probe_exit(mptsas_exit);
-- 
2.0.3

--
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 v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-12 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com

Tetsuo bisected and found that commit 786235ee kthread: make
kthread_create() killable modified kthread_create() to bail as
soon as SIGKILL is received. This is causing some issues with
some drivers and at times boot. Joseph then found that failures
occur as the systemd-udevd process sends SIGKILL to modprobe if
probe on a driver takes over 30 seconds. When this happens probe
will fail on any driver, its why booting on some system will fail
if the driver happens to be a storage related driver. Some folks
have suggested fixing this by modifying kthread_create() to not
leave upon SIGKILL [3], upon review Oleg rejected this change and
the discussion was punted out to systemd to see if the default
timeout could be increased from 30 seconds to 120. The opinion of
the systemd maintainers is that the driver's behavior should
be fixed [4]. Linus seems to agree [5], however more recently even
networking drivers have been reported to fail on probe since just
writing the firmware to a device and kicking it can take easy over
60 seconds [6]. Benjamim was able to trace the issues recently
reported on cxgb4 down to the same systemd-udevd 30 second timeout [6].

This is an alternative solution which enables drivers that are
known to take long to use kthread_run(), this avoids the 30 second
timeout and lets us annotate drivers with long init sequences that
need some love.

[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705
[1] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1297248
[2] http://lists.freedesktop.org/archives/systemd-devel/2014-March/018006.html
[3] http://thread.gmane.org/gmane.linux.ubuntu.devel.kernel.general/39123
[4] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/17860
[5] http://article.gmane.org/gmane.linux.kernel/1671333
[6] https://bugzilla.novell.com/show_bug.cgi?id=877622

Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Kay Sievers k...@vrfy.org
Cc: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk
Cc: Tim Gardner tim.gard...@canonical.com
Cc: Pierre Fersing pierre-fers...@pierref.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Benjamin Poirier bpoir...@suse.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Hariprasad S haripra...@chelsio.com
Cc: Santosh Rastapur sant...@chelsio.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---

A few implementation notes:

1) Two wrappers are used to simply enable the same prototype
   as expected on modules for module_init()

2) The new helpers are stuffed under kthread.h since including
   kthread.h on init.h caused major issues which are not easy
   to resolve, in fact even including kernel.h in init.h cases
   some issues. We could have keep this under init.h if we ifef'd
   on _LINUX_KTHREAD_H as well but this seems a bit cleaner.

 include/linux/kthread.h | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 13d5520..2ba 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_KTHREAD_H
 #define _LINUX_KTHREAD_H
 /* Simple interface for creating and stopping kernel threads without mess. */
+#include linux/init.h
 #include linux/err.h
 #include linux/sched.h
 
@@ -128,4 +129,38 @@ bool queue_kthread_work(struct kthread_worker *worker,
 void flush_kthread_work(struct kthread_work *work);
 void flush_kthread_worker(struct kthread_worker *worker);
 
+#ifndef MODULE
+
+#define module_long_probe_init(x)  __initcall(x);
+#define module_long_probe_exit(x)  __exitcall(x);
+
+#else
+/* To be used by modules which can take over 30 seconds at probe */
+#define module_long_probe_init(initfn) \
+   static struct task_struct *__init_thread;   \
+   static int _long_probe_##initfn(void *arg)  \
+   {   \
+   return initfn();\
+   }   \
+   static inline __init int __long_probe_##initfn(void)\
+   {   \
+   __init_thread = kthread_run(_long_probe_##initfn,\
+   NULL,   \
+   #initfn);   \
+   if (IS_ERR(__init_thread))  \
+

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-12 Thread Tetsuo Handa
Luis R. Rodriguez wrote:
 Tetsuo bisected and found that commit 786235ee \kthread: make
 kthread_create() killable\ modified kthread_create() to bail as
 soon as SIGKILL is received.

I just wrote commit 786235ee. It is not Tetsuo who bisected it.

 @@ -128,4 +129,38 @@ bool queue_kthread_work(struct kthread_worker *worker,
 void flush_kthread_work(struct kthread_work *work);
 void flush_kthread_worker(struct kthread_worker *worker);
 
 +#ifndef MODULE
 +
 +#define module_long_probe_init(x)  __initcall(x);
 +#define module_long_probe_exit(x)  __exitcall(x);
 +
 +#else
 +/* To be used by modules which can take over 30 seconds at probe */
 +#define module_long_probe_init(initfn)\\
 + static struct task_struct *__init_thread;  \\
 + static int _long_probe_##initfn(void *arg)  \\
 + {   \\
 +  return initfn();\\
 + }   \\
 + static inline __init int __long_probe_##initfn(void) \\
 + {   \\
 +  __init_thread = kthread_run(_long_probe_##initfn,\\
 + NULL,  \\
 + #initfn);  \\
 +  if (IS_ERR(__init_thread))   \\
 +   return PTR_ERR(__init_thread);  \\
 +  return 0; \\
 + }   \\
 + module_init(__long_probe_##initfn);
 +/* To be used by modules that require module_long_probe_init() */
 +#define module_long_probe_exit(exitfn)\\
 + static inline void __long_probe_##exitfn(void)  \\
 + {   \\
 +  exitfn(); \\

exitfn() must not be called if initfn() failed or has not
completed yet. You need a bool variable for indicating that
we are ready to call exitfn().

Also, subsequent userspace operations may fail if
we return to userspace before initfn() completes
(e.g. device nodes are not created yet).

 +  if (__init_thread)\\
 +   kthread_stop(__init_thread);  \\

We can\'t use kthread_stop() here because we have to
wait for initfn() to succeed before exitfn() is called.

 + }   \\
 + module_exit(__long_probe_##exitfn);
 +#endif /* MODULE */
 +
 #endif /* _LINUX_KTHREAD_H */
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

2014-08-12 Thread Greg KH
On Wed, Aug 13, 2014 at 07:59:06AM +0900, Tetsuo Handa wrote:
 Luis R. Rodriguez wrote:
  Tetsuo bisected and found that commit 786235ee \kthread: make
  kthread_create() killable\ modified kthread_create() to bail as
  soon as SIGKILL is received.
 
 I just wrote commit 786235ee. It is not Tetsuo who bisected it.
 
  @@ -128,4 +129,38 @@ bool queue_kthread_work(struct kthread_worker *worker,
  void flush_kthread_work(struct kthread_work *work);
  void flush_kthread_worker(struct kthread_worker *worker);
  
  +#ifndef MODULE
  +
  +#define module_long_probe_init(x)  __initcall(x);
  +#define module_long_probe_exit(x)  __exitcall(x);
  +
  +#else
  +/* To be used by modules which can take over 30 seconds at probe */
  +#define module_long_probe_init(initfn)\\
  + static struct task_struct *__init_thread;  \\
  + static int _long_probe_##initfn(void *arg)  \\
  + {   \\
  +  return initfn();\\
  + }   \\
  + static inline __init int __long_probe_##initfn(void) \\
  + {   \\
  +  __init_thread = kthread_run(_long_probe_##initfn,\\
  + NULL,  \\
  + #initfn);  \\
  +  if (IS_ERR(__init_thread))   \\
  +   return PTR_ERR(__init_thread);  \\
  +  return 0; \\
  + }   \\
  + module_init(__long_probe_##initfn);
  +/* To be used by modules that require module_long_probe_init() */
  +#define module_long_probe_exit(exitfn)\\
  + static inline void __long_probe_##exitfn(void)  \\
  + {   \\
  +  exitfn(); \\
 
 exitfn() must not be called if initfn() failed or has not
 completed yet. You need a bool variable for indicating that
 we are ready to call exitfn().
 
 Also, subsequent userspace operations may fail if
 we return to userspace before initfn() completes
 (e.g. device nodes are not created yet).

I doubt that this will be a problem, as device nodes are usually created
_after_ module_init() returns.

But the cleanup issues are real on error paths.  Given that these
drivers will need work anyway, I don't think it's really a big deal.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace

2014-08-12 Thread Yoshihiro YUNOMAE

Hi Douglas,

Thank you for your comment.

(2014/08/08 22:07), Douglas Gilbert wrote:

On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote:

Hi All,

This patch set introduces new traceevents in order to output
continuous error
messages. Current SCSI printk messages in upstream kernel can be
divided by and
mixed with other messages. Even if each error message has its device id,
sometimes we can easily be lost in mixed logs because the message's
device id
is separated from it's body. To avoid it, I'd like to use traceevents to
store error messages into the ftrace or perf buuffer, because traceevents
are atomically commited to the buffer.

In this patch set, all printk messages are removed based on a local
discussion with Hannes, but I think printk messages should be kept
because all
users don't enable traceevents and rsyslog can store as files.

However, if printk of logging branch is kept, the messages are
duplicate and
it can induce stack overflow by using local buffer(*1).

  (*1) https://lkml.org/lkml/2014/5/20/742

So, my suggestion is follows:

1) printk
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can check the
error
messages without any settings.

2) traceevents
To get the complete messages, we can use ftrace or perf (or something
on them).
Users can always understand correct messages, but they need to set up the
tracers.

This patch set is based on Hannes' logging branch:
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


[1/10] ~  [6/10]: just cleanup for logging branch
[7/10] ~ [10/10]: introduce new traceevents

Any comments are welcome!


In sg3_utils there are now string yielding equivalents
to the sense buffer print functions. They take a form
like this:
   char * get_sense_str(const unsigned char * sense_buffer,
int sb_len, int blen, char * b);

So this just does the hard work of decoding the sense buffer
(or saying it is invalid) the result of which it places in
buffer 'b'. And 'b' is returned (so this function can be in
the arguments of a driver's printing function).

Adding such string functions would give other parts of the
SCSI subsystem the capability of tailoring their own
messages that include sense data information.


Existing sense buffer print function could be kept and
implemented using the newer _str variants. Would that
be worth the trouble?


I have already sent the idea using local buffer on this February,
but it was rejected by James (*1). By using stack region for local
buffer, stack overflow can occur. So, I implemented this feature
to atomically output an error message with device information.

(*1) https://lkml.org/lkml/2014/5/20/742

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com


--
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: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

2014-08-12 Thread Yoshihiro YUNOMAE

Hi Elliot,

Thank you for your comment.

(2014/08/12 23:51), Elliott, Robert (Server Storage) wrote:




-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE
Sent: Friday, 08 August, 2014 6:50 AM

...

Subject: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in
__scsi_print_sense()

A device name is output like sda: Sense Key : Medium Error [current]
in __scsi_print_sense(), but it should be [sda] Sense Key : Medium Error
[current] because other printk messages output a device name like [sda]
foo.


...

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index c6a7a4a..a0e8159 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1470,7 +1470,7 @@ void __scsi_print_sense(struct scsi_device *sdev,
const char *name,
return;
}

-   sdev_printk(KERN_INFO, sdev, %s: Sense Key : %s %s%s\n, name,
+   sdev_printk(KERN_INFO, sdev, [%s] Sense Key : %s %s%s\n, name,
   scsi_sense_key_string(sshdr.sense_key),
   scsi_sense_type_string(sshdr),
   scsi_sense_format_string(sshdr));




The callers of __scsi_print_sense do not always pass in a name
like sda.  In fact, sd.c doesn't even call that function; its
sd_print_sense_hdr calls sd_printk (which prints name as [%s])
and scsi_show_sense_hdr.


OK, I understood.
Current Linux kernel also outputs name: in __scsi_print_sense(),
so we should not change this.

Thanks,
Yoshihiro YUNOMOAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com


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