date:20150603

[PATCH] advansys: fix compilation errors and warnings when CONFIG_PCI is not set

2015-06-03 Thread Johannes Thumshirn

Fix compilation errors on forgotten #include  and warnings when
CONFIG_PCI is not set.

Reported-by: Jim Davis 
Signed-off-by: Johannes Thumshirn 
---
 drivers/scsi/advansys.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 14d3aa5..4305178 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -9435,6 +9436,7 @@ static int AscInitSetConfig(struct pci_dev *pdev, struct 
Scsi_Host *shost)
  * on big-endian platforms so char fields read as words are actually being
  * unswapped on big-endian platforms.
  */
+#ifdef CONFIG_PCI
 static ADVEEP_3550_CONFIG Default_3550_EEPROM_Config = {
ADV_EEPROM_BIOS_ENABLE, /* cfg_lsw */
0x, /* cfg_msw */
@@ -9771,7 +9773,6 @@ static ADVEEP_38C1600_CONFIG 
ADVEEP_38C1600_Config_Field_IsChar = {
0   /* 63 reserved */
 };
 
-#ifdef CONFIG_PCI
 /*
  * Wait for EEPROM command to complete
  */
@@ -11385,7 +11386,9 @@ static int advansys_board_found(struct Scsi_Host 
*shost, unsigned int iop,
  err_unmap:
if (boardp->ioremap_addr)
iounmap(boardp->ioremap_addr);
+#ifdef CONFIG_PCI
  err_shost:
+#endif
return ret;
 }
 
-- 
1.8.5.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: bisected regression: qla2xxx endianness on sparc64

2015-06-03 Thread Meelis Roos

On Mon, 10 Nov 2014, Christoph Hellwig wrote:

> On Mon, Nov 03, 2014 at 03:09:47PM -0500, Chad Dupuis wrote:
> > We should revert that change. What were some of the other failures you were
> > seeing?
> 
> Can you please send me the revert ASAP?

Since QLogic is still silent on this one, I will send it to you:

Revert change that breaks QLA2XXX on big-endian systems, 
__constant_cpu_to_le16() is still needed.

Signed-off-by: Meelis Roos 

diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h
index 42bb357..88d3143 100644
--- a/drivers/scsi/qla2xxx/qla_fw.h
+++ b/drivers/scsi/qla2xxx/qla_fw.h
@@ -91,7 +91,7 @@ struct nvram_24xx {
/* Firmware Initialization Control Block. */
uint16_t version;
uint16_t reserved_1;
-   __le16 frame_payload_size;
+   uint16_t frame_payload_size;
uint16_t execution_throttle;
uint16_t exchange_count;
uint16_t hard_address;
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 285cb20..ed973a1 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2658,18 +2658,18 @@ qla2x00_nvram_config(scsi_qla_host_t *vha)
nv->firmware_options[1] = BIT_7 | BIT_5;
nv->add_firmware_options[0] = BIT_5;
nv->add_firmware_options[1] = BIT_5 | BIT_4;
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->special_options[1] = BIT_7;
} else if (IS_QLA2200(ha)) {
nv->firmware_options[0] = BIT_2 | BIT_1;
nv->firmware_options[1] = BIT_7 | BIT_5;
nv->add_firmware_options[0] = BIT_5;
nv->add_firmware_options[1] = BIT_5 | BIT_4;
-   nv->frame_payload_size = 1024;
+   nv->frame_payload_size = __constant_cpu_to_le16(1024);
} else if (IS_QLA2100(ha)) {
nv->firmware_options[0] = BIT_3 | BIT_1;
nv->firmware_options[1] = BIT_5;
-   nv->frame_payload_size = 1024;
+   nv->frame_payload_size = __constant_cpu_to_le16(1024);
}
 
nv->max_iocb_allocation = __constant_cpu_to_le16(256);
@@ -2705,7 +2705,7 @@ qla2x00_nvram_config(scsi_qla_host_t *vha)
 * are valid.
 */
if (ia64_platform_is("sn2")) {
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
if (IS_QLA23XX(ha))
nv->special_options[1] = BIT_7;
}
@@ -5022,7 +5022,7 @@ qla24xx_nvram_config(scsi_qla_host_t *vha)
memset(nv, 0, ha->nvram_size);
nv->nvram_version = __constant_cpu_to_le16(ICB_VERSION);
nv->version = __constant_cpu_to_le16(ICB_VERSION);
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->execution_throttle = __constant_cpu_to_le16(0x);
nv->exchange_count = __constant_cpu_to_le16(0);
nv->hard_address = __constant_cpu_to_le16(124);
@@ -5969,7 +5969,7 @@ qla81xx_nvram_config(scsi_qla_host_t *vha)
memset(nv, 0, ha->nvram_size);
nv->nvram_version = __constant_cpu_to_le16(ICB_VERSION);
nv->version = __constant_cpu_to_le16(ICB_VERSION);
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->execution_throttle = __constant_cpu_to_le16(0x);
nv->exchange_count = __constant_cpu_to_le16(0);
nv->port_name[0] = 0x21;

-- 
Meelis Roos (mr...@linux.ee)
--
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

qla2xxx crash on sparc64 (bus error)

2015-06-03 Thread Meelis Roos

Debian packaged 4.0.4 hangs on qla2xxx init so I decided to try latest 
git (4.1.0-rc6-00040-gc46a024). Got the following error:

[   71.232300] ERROR(1): Cheetah error trap taken afsr[00100800] 
afar[07fd00100040] TL1(0)
[   71.350495] ERROR(1): TPC[6f4a4c] TNPC[6f4a50] O7[6f4a40] TSTATE[9980001602]
[   71.442359] ERROR(1): TPC

qla2x00_mailbox_command+0xd0c is after mbox_done, between first and 
second ql_dbg call, likely at start of preparing the arguments to the 
second ql_dbg call. However, I can not see the output of first ql_dbg in 
dmesg, so debug is probably not very active.

  6f49dc:   40 00 66 f9 call  70e5c0 
  6f49e0:   96 12 e0 d0 or  %o3, 0xd0, %o3
  6f49e4:   10 68 00 0a b  %xcc, 6f4a0c 
  6f49e8:   d8 16 60 08 lduh  [ %i1 + 8 ], %o4
  6f49ec:   7f f6 69 cd call  48f120 
  6f49f0:   d0 5f a7 f7 ldx  [ %fp + 0x7f7 ], %o0
  6f49f4:   80 a6 a0 00 cmp  %i2, 0
  6f49f8:   02 48 00 3e be  %icc, 6f4af0 
  6f49fc:   15 00 10 21 sethi  %hi(0x408400), %o2
  6f4a00:   c4 17 a7 cd lduh  [ %fp + 0x7cd ], %g2
  6f4a04:   ab 28 a0 10 sll  %g2, 0x10, %l5
  6f4a08:   d8 16 60 08 lduh  [ %i1 + 8 ], %o4
  6f4a0c:   94 10 20 81 mov  0x81, %o2
  6f4a10:   17 00 26 4f sethi  %hi(0x993c00), %o3
  6f4a14:   da 16 60 0a lduh  [ %i1 + 0xa ], %o5
  6f4a18:   11 04 00 00 sethi  %hi(0x1000), %o0
  6f4a1c:   92 10 00 1b mov  %i3, %o1
  6f4a20:   c4 16 60 0c lduh  [ %i1 + 0xc ], %g2
  6f4a24:   95 2a b0 05 sllx  %o2, 5, %o2
  6f4a28:   96 12 e0 e8 or  %o3, 0xe8, %o3
  6f4a2c:   c2 16 60 0e lduh  [ %i1 + 0xe ], %g1
  6f4a30:   ab 35 60 10 srl  %l5, 0x10, %l5
  6f4a34:   ab 3d 60 00 sra  %l5, 0, %l5
  6f4a38:   ea 73 a8 bf stx  %l5, [ %sp + 0x8bf ]
  6f4a3c:   c4 73 a8 af stx  %g2, [ %sp + 0x8af ]
  6f4a40:   40 00 66 e0 call  70e5c0 
  6f4a44:   c2 73 a8 b7 stx  %g1, [ %sp + 0x8b7 ]
  6f4a48:   98 04 e0 44 add  %l3, 0x44, %o4
  6f4a4c:   d8 83 03 a0 lda  [ %o4 ] #ASI_PHYS_BYPASS_EC_E_L, %o4
  6f4a50:   da 5f 64 80 ldx  [ %i5 + 0x480 ], %o5
  6f4a54:   84 04 e0 0c add  %l3, 0xc, %g2
  6f4a58:   c4 80 83 a0 lda  [ %g2 ] #ASI_PHYS_BYPASS_EC_E_L, %g2
  6f4a5c:   82 04 e0 10 add  %l3, 0x10, %g1
  6f4a60:   c2 80 43 a0 lda  [ %g1 ] #ASI_PHYS_BYPASS_EC_E_L, %g1
  6f4a64:   15 00 11 15 sethi  %hi(0x445400), %o2
  6f4a68:   17 00 26 4f sethi  %hi(0x993c00), %o3
  6f4a6c:   85 30 a0 00 srl  %g2, 0, %g2
  6f4a70:   83 30 60 00 srl  %g1, 0, %g1
  6f4a74:   c4 73 a8 af stx  %g2, [ %sp + 0x8af ]
  6f4a78:   11 04 00 00 sethi  %hi(0x1000), %o0
  6f4a7c:   92 10 00 18 mov  %i0, %o1
  6f4a80:   c2 73 a8 b7 stx  %g1, [ %sp + 0x8b7 ]
  6f4a84:   95 32 b0 0a srlx  %o2, 0xa, %o2
  6f4a88:   96 12 e1 30 or  %o3, 0x130, %o3
  6f4a8c:   99 33 20 00 srl  %o4, 0, %o4
  6f4a90:   40 00 66 cc call  70e5c0 

Probably one of the RD_REG_DWORD() invocations. This defined like
#define RD_REG_DWORD(addr)readl(addr)

I instrumented the code to print the addresses and they seem to be 
normal:
reg=07fd0010, ®->isp24.host_status=07fd00100044

Additional test confirms that the crash comes from
RD_REG_DWORD(®->isp24.host_status)


[   58.078540] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
8.07.00.18-k.
[   58.185410] PCI: Enabling device: (:00:01.0), cmd 3
[   58.253300] qla2xxx [:00:01.0]-001d: : Found an ISP2312 irq 16 iobase 
0x07fe0012c000.
[   58.716237] scsi host0: qla2xxx
[   58.761020] qla2xxx [:00:01.0]-00fb:0: QLogic QLA2340-SUN - Sun 133MHz 
PCI-X to 2Gb FC, Single Channel.
[   58.888413] qla2xxx [:00:01.0]-00fc:0: ISP2312: PCI (33 MHz) @ 
:00:01.0 hdma- host#=0 fw=3.03.28 IPX.
[   59.018098] PCI: Enabling device: (:00:03.0), cmd 3
[   59.085899] qla2xxx [:00:03.0]-001d: : Found an ISP2312 irq 17 iobase 
0x07fe0012e000.
[   59.548230] scsi host1: qla2xxx
[   59.592692] qla2xxx [:00:03.0]-00fb:1: QLogic QLA2340 - Sun 133MHz PCI-X 
to 2Gb FC, Single Channel.
[   59.715490] qla2xxx [:00:03.0]-00fc:1: ISP2312: PCI (33 MHz) @ 
:00:03.0 hdma- host#=1 fw=3.03.28 IPX.
[   59.845200] PCI: Enabling device: (0001:00:04.0), cmd 3
[   59.912984] qla2xxx [0001:00:04.0]-001d: : Found an ISP2200 irq 19 iobase 
0x07fd0010.
[   60.025094] qla2xxx [0001:00:04.0]-0050:2: No matching ROM signature.
[   60.203162] qla2xxx [0001:00:04.0]-0064:2: Inconsistent NVRAM detected: 
checksum=0x0 id= version=0x0.
[   60.324848] qla2xxx [0001:00:04.0]-0065:2: Falling back to functioning (yet 
invalid -- WWPN) defaults.
[   60.446514] qla2xxx [0001:00:04.0]-0069:2: NVRAM configuration failed.
[   71.232300] ERROR(1): Cheetah error trap taken afsr[00100800] 
afar[07fd00100040] TL1(0)
[   71.3

[PATCH v2 0/4] fixing building errors and warnings when components

2015-06-03 Thread Yaniv Gardi

V2:
In this Version, comments from reviewers were addressed
and also, added another change: PATCH v2 4/4
In this change we glue the variant attributes (vops, etc)
at the time of the platform probing, so they can be used
by the driver when it doing its initialization phase.

V1:
The following combination of components, when SCSI_UFS_QCOM=y
and PHY_QCOM_UFS=m is illegal and causes build errors.
The 3rd patch in the series enables the SCSI_UFS_QCOM component to 
be compiled as a module (by changing its configuration to tristate).
So now, compiling SCSI_UFS_QCOM=m forces PHY_QCOM_UFS=m, and 
SCSI_UFS_QCOM=y forces PHY_QCOM_UFS=y.

In addition, when PHY_QCOM_UFS=m, external functions in 
phy-ufs-qcom.c should be exported. The 1st patch fixes it.

Another issue that we see when SCSI_UFS_QCOM=m is a warning that
the 2nd patch fixes.

notice:
checkpatch gives an error on the commit message of patch 1/3
in the series. Ignore as the commit message is the build errors
that this patch fixes.

Yaniv Gardi (4):
  phy: qcom-ufs: fix build error when the component is built as a module
  scsi: ufs-qcom: fix compilation warning if compiled as a module
  scsi: ufs-qcom: update configuration option of SCSI_UFS_QCOM component
  scsi: ufs: probe and init of variant driver from the platform device

 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  8 
 drivers/phy/phy-qcom-ufs.c | 11 +
 drivers/scsi/ufs/Kconfig   |  2 +-
 drivers/scsi/ufs/ufs-qcom.c| 47 +-
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 33 +--
 5 files changed, 86 insertions(+), 15 deletions(-)

-- 
1.8.5.2

-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/4] phy: qcom-ufs: fix build error when the component is built as a module

2015-06-03 Thread Yaniv Gardi

Export the following functions in order to avoid build errors
when the component PHY_QCOM_UFS is compiled as a module:

ERROR: "ufs_qcom_phy_disable_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_enable_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_is_pcs_ready" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_disable_iface_clk" [drivers/scsi/ufs/ufs-qcom.ko] 
undefined!
ERROR: "ufs_qcom_phy_start_serdes" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_calibrate_phy" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_enable_dev_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] 
undefined!
ERROR: "ufs_qcom_phy_set_tx_lane_enable" [drivers/scsi/ufs/ufs-qcom.ko] 
undefined!
ERROR: "ufs_qcom_phy_disable_dev_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] 
undefined!
ERROR: "ufs_qcom_phy_save_controller_version" [drivers/scsi/ufs/ufs-qcom.ko] 
undefined!
ERROR: "ufs_qcom_phy_enable_iface_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined!
make[1]: *** [__modpost] Error 1

Signed-off-by: Yaniv Gardi 

---
 drivers/phy/phy-qcom-ufs.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
index f9c618f..6140a8b 100644
--- a/drivers/phy/phy-qcom-ufs.c
+++ b/drivers/phy/phy-qcom-ufs.c
@@ -432,6 +432,7 @@ out_disable_src:
 out:
return ret;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_ref_clk);
 
 static
 int ufs_qcom_phy_disable_vreg(struct phy *phy,
@@ -474,6 +475,7 @@ void ufs_qcom_phy_disable_ref_clk(struct phy *generic_phy)
phy->is_ref_clk_enabled = false;
}
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_ref_clk);
 
 #define UFS_REF_CLK_EN (1 << 5)
 
@@ -517,11 +519,13 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy 
*generic_phy)
 {
ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, true);
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_dev_ref_clk);
 
 void ufs_qcom_phy_disable_dev_ref_clk(struct phy *generic_phy)
 {
ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, false);
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_dev_ref_clk);
 
 /* Turn ON M-PHY RMMI interface clocks */
 int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
@@ -550,6 +554,7 @@ int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
 out:
return ret;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_iface_clk);
 
 /* Turn OFF M-PHY RMMI interface clocks */
 void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
@@ -562,6 +567,7 @@ void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
phy->is_iface_clk_enabled = false;
}
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_iface_clk);
 
 int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
 {
@@ -578,6 +584,7 @@ int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_start_serdes);
 
 int ufs_qcom_phy_set_tx_lane_enable(struct phy *generic_phy, u32 tx_lanes)
 {
@@ -595,6 +602,7 @@ int ufs_qcom_phy_set_tx_lane_enable(struct phy 
*generic_phy, u32 tx_lanes)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_set_tx_lane_enable);
 
 void ufs_qcom_phy_save_controller_version(struct phy *generic_phy,
  u8 major, u16 minor, u16 step)
@@ -605,6 +613,7 @@ void ufs_qcom_phy_save_controller_version(struct phy 
*generic_phy,
ufs_qcom_phy->host_ctrl_rev_minor = minor;
ufs_qcom_phy->host_ctrl_rev_step = step;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_save_controller_version);
 
 int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy, bool is_rate_B)
 {
@@ -625,6 +634,7 @@ int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy, 
bool is_rate_B)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_calibrate_phy);
 
 int ufs_qcom_phy_remove(struct phy *generic_phy,
struct ufs_qcom_phy *ufs_qcom_phy)
@@ -662,6 +672,7 @@ int ufs_qcom_phy_is_pcs_ready(struct phy *generic_phy)
return ufs_qcom_phy->phy_spec_ops->
is_physical_coding_sublayer_ready(ufs_qcom_phy);
 }
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_is_pcs_ready);
 
 int ufs_qcom_phy_power_on(struct phy *generic_phy)
 {
-- 
1.8.5.2

-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
--
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 3/4] scsi: ufs-qcom: update configuration option of SCSI_UFS_QCOM component

2015-06-03 Thread Yaniv Gardi

This change is required in order to be able to build the component
as a module.

Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index e945383..5f45307 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -72,7 +72,7 @@ config SCSI_UFSHCD_PLATFORM
  If unsure, say N.
 
 config SCSI_UFS_QCOM
-   bool "QCOM specific hooks to UFS controller platform driver"
+   tristate "QCOM specific hooks to UFS controller platform driver"
depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
select PHY_QCOM_UFS
help
-- 
1.8.5.2

-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
--
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 4/4] scsi: ufs: probe and init of variant driver from the platform device

2015-06-03 Thread Yaniv Gardi

It does so by adding the following changes:
1. Introducing SCSI_UFS_QCOM as a platform device. Its probe
   function registers a set of vops to its driver_data.
2. Adding an optional device tree sub-node, under SCSI_UFSHCD_PLATFORM.
   Now, the probe function of SCSI_UFSHCD_PLATFORM invokes the probe
   function of its sub-node (if it exists), by calling
   of_platform_populate(). It ensures that vops are set, and ready to
   be used, by the time the UFSHCD driver starts its initialization
   procedure.

Signed-off-by: Yaniv Gardi 

---
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  8 +
 drivers/scsi/ufs/ufs-qcom.c| 40 ++
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 33 +++---
 3 files changed, 68 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 5357919..e2f3058 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -55,3 +55,11 @@ Example:
clock-names = "core_clk", "ref_clk", "iface_clk";
freq-table-hz = <1 2>, <0 0>, <0 0>;
};
+
+This is an example to a variant sub-node of ufshc:
+   ufs_variant {
+   compatible = "qcom,ufs_variant";
+   };
+
+This sub-node holds various specific information that is not defined in the
+standard and that may differ between platforms.
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 6671a8e..ad5ffa8 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1018,4 +1018,44 @@ static const struct ufs_hba_variant_ops 
ufs_hba_qcom_vops = {
 };
 EXPORT_SYMBOL(ufs_hba_qcom_vops);
 
+/**
+ * ufs_qcom_probe - probe routine of the driver
+ * @pdev: pointer to Platform device handle
+ *
+ * Always return 0
+ */
+static int ufs_qcom_probe(struct platform_device *pdev)
+{
+   dev_set_drvdata(&pdev->dev, (void *)&ufs_hba_qcom_vops);
+   return 0;
+}
+
+/**
+ * ufs_qcom_remove - set driver_data of the device to NULL
+ * @pdev: pointer to platform device handle
+ *
+ * Always return 0
+ */
+static int ufs_qcom_remove(struct platform_device *pdev)
+{
+   dev_set_drvdata(&pdev->dev, NULL);
+   return 0;
+}
+
+static const struct of_device_id ufs_qcom_of_match[] = {
+   { .compatible = "qcom,ufs_variant"},
+   {},
+};
+
+static struct platform_driver ufs_qcom_pltform = {
+   .probe  = ufs_qcom_probe,
+   .remove = ufs_qcom_remove,
+   .driver = {
+   .name   = "ufs_qcom",
+   .owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(ufs_qcom_of_match),
+   },
+};
+module_platform_driver(ufs_qcom_pltform);
+
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 7db9564..7bf2f44 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -36,22 +36,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ufshcd.h"
 
 static const struct of_device_id ufs_of_match[];
-static struct ufs_hba_variant_ops *get_variant_ops(struct device *dev)
-{
-   if (dev->of_node) {
-   const struct of_device_id *match;
-
-   match = of_match_node(ufs_of_match, dev->of_node);
-   if (match)
-   return (struct ufs_hba_variant_ops *)match->data;
-   }
-
-   return NULL;
-}
 
 static int ufshcd_parse_clock_info(struct ufs_hba *hba)
 {
@@ -300,6 +289,9 @@ static int ufshcd_pltfrm_probe(struct platform_device *pdev)
struct resource *mem_res;
int irq, err;
struct device *dev = &pdev->dev;
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *ufs_variant_node;
+   struct platform_device *ufs_variant_pdev;
 
mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mmio_base = devm_ioremap_resource(dev, mem_res);
@@ -321,7 +313,22 @@ static int ufshcd_pltfrm_probe(struct platform_device 
*pdev)
goto out;
}
 
-   hba->vops = get_variant_ops(&pdev->dev);
+   err = of_platform_populate(node, NULL, NULL, &pdev->dev);
+   if (err)
+   dev_err(&pdev->dev,
+   "%s: of_platform_populate() failed\n", __func__);
+
+   ufs_variant_node = of_get_next_available_child(node, NULL);
+
+   if (!ufs_variant_node) {
+   dev_dbg(&pdev->dev, "failed to find ufs_variant_node child\n");
+   } else {
+   ufs_variant_pdev = of_find_device_by_node(ufs_variant_node);
+
+   if (ufs_variant_pdev)
+   hba->vops = (struct ufs_hba_variant_ops *)
+   dev_get_drvdata(&ufs_variant_pdev->dev);
+   }
 
err = ufshcd_parse_clock_info(hba);
if (err) {
-- 
1.8.5.2

-- 
QUALCOMM ISRAEL,

[PATCH v2 2/4] scsi: ufs-qcom: fix compilation warning if compiled as a module

2015-06-03 Thread Yaniv Gardi

This change fixes a compilation warning that happens if SCSI_UFS_QCOM
is compiled as a module.
Also this patch fixes an error happens when insmod the module:
"ufs_qcom: module license 'unspecified' taints kernel."

Signed-off-by: Yaniv Gardi 

---
 drivers/scsi/ufs/ufs-qcom.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 6652a81..6671a8e 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -885,12 +885,15 @@ out:
 
 #defineANDROID_BOOT_DEV_MAX30
 static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
-static int get_android_boot_dev(char *str)
+
+#ifndef MODULE
+static int __init get_android_boot_dev(char *str)
 {
strlcpy(android_boot_dev, str, ANDROID_BOOT_DEV_MAX);
return 1;
 }
 __setup("androidboot.bootdevice=", get_android_boot_dev);
+#endif
 
 /**
  * ufs_qcom_init - bind phy with controller
@@ -1014,3 +1017,5 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops 
= {
.resume = ufs_qcom_resume,
 };
 EXPORT_SYMBOL(ufs_hba_qcom_vops);
+
+MODULE_LICENSE("GPL v2");
-- 
1.8.5.2

-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation
--
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 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-03 Thread Christoph Hellwig

This makes lockdep very unhappy, rightly so.  If you execute
one end_io function inside another you basіcally nest every possible
lock taken in the I/O completion path.  Also adding more work
to the hardirq path generally isn't a smart idea.  Can you explain
what issues you were seeing and how much this helps?  Note that
the workqueue usage in the target core so far is fairly basic, so
there should some low hanging fruit.

[   21.119148] 
[   21.119382] =
[   21.120012] [ INFO: possible recursive locking detected ]
[   21.120639] 4.1.0-rc1+ #489 Not tainted
[   21.121131] -
[   21.121754] swapper/0/0 is trying to acquire lock:
[   21.122324]  (&(&fq->mq_flush_lock)->rlock){-.}, at: 
[] flush_end_io+0x66/0x220
[   21.122451] 
[   21.122451] but task is already holding lock:
[   21.122451]  (&(&fq->mq_flush_lock)->rlock){-.}, at: 
[] flush_end_io+0x66/0x220
[   21.122451] 
[   21.122451] other info that might help us debug this:
[   21.122451]  Possible unsafe locking scenario:
[   21.122451] 
[   21.122451]CPU0
[   21.122451]
[   21.122451]   lock(&(&fq->mq_flush_lock)->rlock);
[   21.122451]   lock(&(&fq->mq_flush_lock)->rlock);
[   21.122451] 
[   21.122451]  *** DEADLOCK ***
[   21.122451] 
[   21.122451]  May be due to missing lock nesting notation
[   21.122451] 
[   21.122451] 3 locks held by swapper/0/0:
[   21.122451]  #0:  (&(&vp_dev->lock)->rlock){-.-...}, at: 
[] vp_vring_interrupt+0x2c/0x90
[   21.122451]  #1:  (&(&virtscsi_vq->vq_lock)->rlock){-.-...}, at: 
[] virtscsi_vq_done+0x26/0x90
[   21.122451]  #2:  (&(&fq->mq_flush_lock)->rlock){-.}, at: 
[] flush_end_io+0x66/0x220
[   21.122451] 
[   21.122451] stack backtrace:
[   21.122451] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc1+ #489
[   21.122451] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   21.122451]  82c34820 88007fc03618 81e3396f 

[   21.122451]  82445500 88007fc036c8 811209a9 
88007fc17d18
[   21.122451]    82c34820 
88007fc17d18
[   21.122451] Call Trace:
[   21.122451][] dump_stack+0x45/0x57
[   21.122451]  [] validate_chain.isra.37+0xd39/0x1160
[   21.122451]  [] __lock_acquire+0x488/0xd40
[   21.122451]  [] ? __kernel_text_address+0x58/0x80
[   21.122451]  [] lock_acquire+0xaf/0x130
[   21.122451]  [] ? flush_end_io+0x66/0x220
[   21.122451]  [] _raw_spin_lock_irqsave+0x49/0x60
[   21.122451]  [] ? flush_end_io+0x66/0x220
[   21.122451]  [] flush_end_io+0x66/0x220
[   21.122451]  [] __blk_mq_end_request+0x2f/0x70
[   21.122451]  [] scsi_end_request+0x7d/0x1e0
[   21.122451]  [] scsi_io_completion+0x110/0x610
[   21.122451]  [] ? __lock_acquire+0x488/0xd40
[   21.122451]  [] scsi_finish_command+0xdb/0x140
[   21.122451]  [] scsi_softirq_done+0x136/0x150
[   21.122451]  [] __blk_mq_complete_request+0x8e/0x130
[   21.122451]  [] blk_mq_complete_request+0x29/0x30
[   21.122451]  [] scsi_mq_done+0x28/0x60
[   21.122451]  [] tcm_loop_queue_status+0x3b/0xb0
[   21.122451]  [] target_complete_irq+0x8a/0x250
[   21.122451]  [] target_complete_cmd+0x1fa/0x2a0
[   21.122451]  [] iblock_end_io_flush+0x2a/0x60
[   21.122451]  [] bio_endio+0x53/0x90
[   21.122451]  [] blk_update_request+0x98/0x360
[   21.122451]  [] blk_mq_end_request+0x1e/0x80
[   21.122451]  [] blk_flush_complete_seq+0xe4/0x320
[   21.122451]  [] flush_end_io+0x138/0x220
[   21.122451]  [] __blk_mq_end_request+0x2f/0x70
[   21.122451]  [] scsi_end_request+0x7d/0x1e0
[   21.122451]  [] scsi_io_completion+0x110/0x610
[   21.122451]  [] ? trace_hardirqs_off+0xd/0x10
[   21.122451]  [] scsi_finish_command+0xdb/0x140
[   21.122451]  [] scsi_softirq_done+0x136/0x150
[   21.122451]  [] __blk_mq_complete_request+0x8e/0x130
[   21.122451]  [] blk_mq_complete_request+0x29/0x30
[   21.122451]  [] scsi_mq_done+0x28/0x60
[   21.122451]  [] virtscsi_complete_cmd+0x10f/0x1e0
[   21.122451]  [] ? virtscsi_ctrl_done+0x30/0x30
[   21.122451]  [] virtscsi_vq_done+0x49/0x90
[   21.122451]  [] virtscsi_req_done+0x39/0x40
[   21.122451]  [] vring_interrupt+0x30/0x60
[   21.122451]  [] vp_vring_interrupt+0x5b/0x90
[   21.122451]  [] handle_irq_event_percpu+0x60/0x1d0
[   21.122451]  [] handle_irq_event+0x43/0x70
[   21.122451]  [] handle_edge_irq+0x96/0x110
[   21.122451]  [] handle_irq+0x58/0x130
[   21.122451]  [] ? atomic_notifier_call_chain+0x11/0x20
[   21.122451]  [] do_IRQ+0x57/0x100
[   21.122451]  [] common_interrupt+0x73/0x73
[   21.122451][] ? native_safe_halt+0x6/0x10
[   21.122451]  [] ? trace_hardirqs_on+0xd/0x10
[   21.122451]  [] default_idle+0x1e/0xc0
[   21.122451]  [] arch_cpu_idle+0xa/0x10
[   21.122451]  [] cpu_startup_entry+0x383/0x430
[   21.122451]  [] rest_init+0x128/0x130
[   21.122451]  [] ? csum_partial_copy_generic+0x170/0x170
[   21.122451]  [] start_kernel+0x54a/0x557
[   21.122451]  [] ? set_init_arg+0x58/0x58
[   21.122451]

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

2015-06-03 Thread James Bottomley

On Wed, 2015-06-03 at 11:29 +0200, Jiri Slaby wrote:
> On 06/03/2015, 08:35 AM, gre...@linuxfoundation.org wrote:
> > From 74856fbf441929918c49ff262ace9835048e4e6a Mon Sep 17 00:00:00 2001
> > From: Mark Hounschell 
> > Date: Wed, 13 May 2015 10:49:09 +0200
> > Subject: sd: Disable support for 256 byte/sector disks
> > 
> > From: Mark Hounschell 
> > 
> > commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
> > 
> > 256 bytes per sector support has been broken since 2.6.X,
> > and no-one stepped up to fix this.
> > So disable support for it.
> > 
> > Signed-off-by: Mark Hounschell 
> > Signed-off-by: Hannes Reinecke 
> > Signed-off-by: James Bottomley 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/scsi/sd.c |   19 +--
> >  1 file changed, 5 insertions(+), 14 deletions(-)
> > 
> > --- a/drivers/scsi/sd.c
> > +++ b/drivers/scsi/sd.c
> > @@ -1624,6 +1624,7 @@ static unsigned int sd_completed_bytes(s
> >  {
> > u64 start_lba = blk_rq_pos(scmd->request);
> > u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
> > +   u64 factor = scmd->device->sector_size / 512;
> > u64 bad_lba;
> > int info_valid;
> > /*
> > @@ -1645,16 +1646,9 @@ static unsigned int sd_completed_bytes(s
> > if (scsi_bufflen(scmd) <= scmd->device->sector_size)
> > return 0;
> >  
> > -   if (scmd->device->sector_size < 512) {
> > -   /* only legitimate sector_size here is 256 */
> > -   start_lba <<= 1;
> > -   end_lba <<= 1;
> > -   } else {
> > -   /* be careful ... don't want any overflows */
> > -   unsigned int factor = scmd->device->sector_size / 512;
> > -   do_div(start_lba, factor);
> > -   do_div(end_lba, factor);
> > -   }
> 
> Hmm, you do 'unsigned int' -> 'u64' switch of factor type here. But this
> commit:
> commit ef80d1e18b014af08741cf688e3fdda1fb71363f
> Author: Geert Uytterhoeven 
> Date:   Mon Nov 4 10:21:05 2013 +0100
> 
> [SCSI] sd: Do not call do_div() with a 64-bit divisor
> 
> did the switch in the opposite direction deliberately.
> 
> So why did you do the change, given sector_size is uint?

Primarily because no-one spotted the reversal and none of the static
checkers warns about it.

This is the trivial fix, but we should do something about the checkers.

James

---

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 3b2fcb4..3e137dd 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1600,7 +1600,7 @@ static unsigned int sd_completed_bytes(struct scsi_cmnd 
*scmd)
 {
u64 start_lba = blk_rq_pos(scmd->request);
u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
-   u64 factor = scmd->device->sector_size / 512;
+   unsigned int factor = scmd->device->sector_size / 512;
u64 bad_lba;
int info_valid;
/*

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

2015-06-03 Thread James Bottomley

On Wed, 2015-06-03 at 13:37 +, James Bottomley wrote:
> On Wed, 2015-06-03 at 11:29 +0200, Jiri Slaby wrote:
> > On 06/03/2015, 08:35 AM, gre...@linuxfoundation.org wrote:
> > > From 74856fbf441929918c49ff262ace9835048e4e6a Mon Sep 17 00:00:00 2001
> > > From: Mark Hounschell 
> > > Date: Wed, 13 May 2015 10:49:09 +0200
> > > Subject: sd: Disable support for 256 byte/sector disks
> > > 
> > > From: Mark Hounschell 
> > > 
> > > commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
> > > 
> > > 256 bytes per sector support has been broken since 2.6.X,
> > > and no-one stepped up to fix this.
> > > So disable support for it.
> > > 
> > > Signed-off-by: Mark Hounschell 
> > > Signed-off-by: Hannes Reinecke 
> > > Signed-off-by: James Bottomley 
> > > Signed-off-by: Greg Kroah-Hartman 
> > > 
> > > ---
> > >  drivers/scsi/sd.c |   19 +--
> > >  1 file changed, 5 insertions(+), 14 deletions(-)
> > > 
> > > --- a/drivers/scsi/sd.c
> > > +++ b/drivers/scsi/sd.c
> > > @@ -1624,6 +1624,7 @@ static unsigned int sd_completed_bytes(s
> > >  {
> > >   u64 start_lba = blk_rq_pos(scmd->request);
> > >   u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
> > > + u64 factor = scmd->device->sector_size / 512;
> > >   u64 bad_lba;
> > >   int info_valid;
> > >   /*
> > > @@ -1645,16 +1646,9 @@ static unsigned int sd_completed_bytes(s
> > >   if (scsi_bufflen(scmd) <= scmd->device->sector_size)
> > >   return 0;
> > >  
> > > - if (scmd->device->sector_size < 512) {
> > > - /* only legitimate sector_size here is 256 */
> > > - start_lba <<= 1;
> > > - end_lba <<= 1;
> > > - } else {
> > > - /* be careful ... don't want any overflows */
> > > - unsigned int factor = scmd->device->sector_size / 512;
> > > - do_div(start_lba, factor);
> > > - do_div(end_lba, factor);
> > > - }
> > 
> > Hmm, you do 'unsigned int' -> 'u64' switch of factor type here. But this
> > commit:
> > commit ef80d1e18b014af08741cf688e3fdda1fb71363f
> > Author: Geert Uytterhoeven 
> > Date:   Mon Nov 4 10:21:05 2013 +0100
> > 
> > [SCSI] sd: Do not call do_div() with a 64-bit divisor
> > 
> > did the switch in the opposite direction deliberately.
> > 
> > So why did you do the change, given sector_size is uint?
> 
> Primarily because no-one spotted the reversal and none of the static
> checkers warns about it.
> 
> This is the trivial fix, but we should do something about the checkers.

Actually, I think there's no problem: all the architectures now have the
correct conversion of the base argument.

Author: Andreas Schwab 
Date:   Fri Aug 9 15:14:08 2013 +0200

m68k: Truncate base in do_div()

Fixed this in m68k, which was the last one, so it looks like there's no
issue and ef80d1e18b014af08741cf688e3fdda1fb71363f was pointless.

James

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

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

2015-06-03 Thread Geert Uytterhoeven

On Wed, Jun 3, 2015 at 3:54 PM, James Bottomley
 wrote:
> On Wed, 2015-06-03 at 13:37 +, James Bottomley wrote:
>> On Wed, 2015-06-03 at 11:29 +0200, Jiri Slaby wrote:
>> > On 06/03/2015, 08:35 AM, gre...@linuxfoundation.org wrote:
>> > > From 74856fbf441929918c49ff262ace9835048e4e6a Mon Sep 17 00:00:00 2001
>> > > From: Mark Hounschell 
>> > > Date: Wed, 13 May 2015 10:49:09 +0200
>> > > Subject: sd: Disable support for 256 byte/sector disks
>> > >
>> > > From: Mark Hounschell 
>> > >
>> > > commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
>> > >
>> > > 256 bytes per sector support has been broken since 2.6.X,
>> > > and no-one stepped up to fix this.
>> > > So disable support for it.
>> > >
>> > > Signed-off-by: Mark Hounschell 
>> > > Signed-off-by: Hannes Reinecke 
>> > > Signed-off-by: James Bottomley 
>> > > Signed-off-by: Greg Kroah-Hartman 
>> > >
>> > > ---
>> > >  drivers/scsi/sd.c |   19 +--
>> > >  1 file changed, 5 insertions(+), 14 deletions(-)
>> > >
>> > > --- a/drivers/scsi/sd.c
>> > > +++ b/drivers/scsi/sd.c
>> > > @@ -1624,6 +1624,7 @@ static unsigned int sd_completed_bytes(s
>> > >  {
>> > >   u64 start_lba = blk_rq_pos(scmd->request);
>> > >   u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
>> > > + u64 factor = scmd->device->sector_size / 512;
>> > >   u64 bad_lba;
>> > >   int info_valid;
>> > >   /*
>> > > @@ -1645,16 +1646,9 @@ static unsigned int sd_completed_bytes(s
>> > >   if (scsi_bufflen(scmd) <= scmd->device->sector_size)
>> > >   return 0;
>> > >
>> > > - if (scmd->device->sector_size < 512) {
>> > > - /* only legitimate sector_size here is 256 */
>> > > - start_lba <<= 1;
>> > > - end_lba <<= 1;
>> > > - } else {
>> > > - /* be careful ... don't want any overflows */
>> > > - unsigned int factor = scmd->device->sector_size / 512;
>> > > - do_div(start_lba, factor);
>> > > - do_div(end_lba, factor);
>> > > - }
>> >
>> > Hmm, you do 'unsigned int' -> 'u64' switch of factor type here. But this
>> > commit:
>> > commit ef80d1e18b014af08741cf688e3fdda1fb71363f
>> > Author: Geert Uytterhoeven 
>> > Date:   Mon Nov 4 10:21:05 2013 +0100
>> >
>> > [SCSI] sd: Do not call do_div() with a 64-bit divisor
>> >
>> > did the switch in the opposite direction deliberately.
>> >
>> > So why did you do the change, given sector_size is uint?
>>
>> Primarily because no-one spotted the reversal and none of the static
>> checkers warns about it.
>>
>> This is the trivial fix, but we should do something about the checkers.
>
> Actually, I think there's no problem: all the architectures now have the
> correct conversion of the base argument.
>
> Author: Andreas Schwab 
> Date:   Fri Aug 9 15:14:08 2013 +0200
>
> m68k: Truncate base in do_div()
>
> Fixed this in m68k, which was the last one, so it looks like there's no
> issue and ef80d1e18b014af08741cf688e3fdda1fb71363f was pointless.

FWIW, "[PATCH] mn10300: Truncate base in do_div()"
(http://lkml.iu.edu/hypermail/linux/kernel/1308.2/03544.html)
hasn't been applied yet. But as mn10300 is little endian, it shouldn't
suffer from the bug like m68k did.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

2015-06-03 Thread Suravee Suthikulanit


On 5/28/2015 9:38 PM, Mark Salter wrote:

On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:

>Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
>section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
>object to be specified for DMA-cabpable devices. Therefore, this patch
>specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
>
>In addition, to handle the case when _CCA is missing, arm64 would assign
>dummy_dma_ops to disable DMA capability of the device.
>
>Acked-by: Catalin Marinas
>Signed-off-by: Mark Salter
>Signed-off-by: Suravee Suthikulpanit
>---
>  arch/arm64/Kconfig   |  1 +
>  arch/arm64/include/asm/dma-mapping.h | 18 ++-
>  arch/arm64/mm/dma-mapping.c  | 92 

>  3 files changed, 109 insertions(+), 2 deletions(-)
>
>diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>index 4269dba..95307b4 100644
>--- a/arch/arm64/Kconfig
>+++ b/arch/arm64/Kconfig
>@@ -1,5 +1,6 @@
>  config ARM64
>def_bool y
>+   select ACPI_CCA_REQUIRED if ACPI
>select ACPI_GENERIC_GSI if ACPI
>select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>diff --git a/arch/arm64/include/asm/dma-mapping.h 
b/arch/arm64/include/asm/dma-mapping.h
>index 9437e3d..f0d6d0b 100644
>--- a/arch/arm64/include/asm/dma-mapping.h
>+++ b/arch/arm64/include/asm/dma-mapping.h
>@@ -18,6 +18,7 @@
>
>  #ifdef __KERNEL__
>
>+#include 
>  #include 
>  #include 
>

^^^ This hunk causes build issues with a couple of drivers:

drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined 
[enabled by default]
  #define FALSE 0
  ^
In file included from include/acpi/acpi.h:58:0,
  from include/linux/acpi.h:37,
  from ./arch/arm64/include/asm/dma-mapping.h:21,
  from include/linux/dma-mapping.h:86,
  from ./arch/arm64/include/asm/pci.h:7,
  from include/linux/pci.h:1460,
  from drivers/scsi/megaraid/megaraid_sas_fp.c:37:
include/acpi/actypes.h:433:0: note: this is the location of the previous 
definition
  #define FALSE   (1 == 0)
  ^


In file included from include/acpi/acpi.h:58:0,
  from include/linux/acpi.h:37,
  from ./arch/arm64/include/asm/dma-mapping.h:21,
  from include/linux/dma-mapping.h:86,
  from include/scsi/scsi_cmnd.h:4,
  from drivers/scsi/ufs/ufshcd.h:60,
  from drivers/scsi/ufs/ufshcd.c:43:
include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token
  #define FALSE   (1 == 0)
  ^
drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’
   FALSE = 0,
   ^

This happens because the ACPI definitions of TRUE and FALSE conflict
with local definitions in megaraid and enum declaration in ufs.


Mark,

Thanks for pointing this out. Although, I would think that the 
megaraid_sas_fp.c should have had the #ifndef to check before defining 
the TRUE and FALSE as following.


#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif

This seems to be what other drivers are also doing. If this is okay, I 
can send out a fix-up patch for the megaraid driver.


Thanks,

Suravee

--
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: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

2015-06-03 Thread Mark Salter

On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote:
> On 5/28/2015 9:38 PM, Mark Salter wrote:
> > On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
> >> >Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
> >> >section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
> >> >object to be specified for DMA-cabpable devices. Therefore, this patch
> >> >specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
> >> >
> >> >In addition, to handle the case when _CCA is missing, arm64 would assign
> >> >dummy_dma_ops to disable DMA capability of the device.
> >> >
> >> >Acked-by: Catalin Marinas
> >> >Signed-off-by: Mark Salter
> >> >Signed-off-by: Suravee Suthikulpanit
> >> >---
> >> >  arch/arm64/Kconfig   |  1 +
> >> >  arch/arm64/include/asm/dma-mapping.h | 18 ++-
> >> >  arch/arm64/mm/dma-mapping.c  | 92 
> >> > 
> >> >  3 files changed, 109 insertions(+), 2 deletions(-)
> >> >
> >> >diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> >index 4269dba..95307b4 100644
> >> >--- a/arch/arm64/Kconfig
> >> >+++ b/arch/arm64/Kconfig
> >> >@@ -1,5 +1,6 @@
> >> >  config ARM64
> >> >  def_bool y
> >> >+ select ACPI_CCA_REQUIRED if ACPI
> >> >  select ACPI_GENERIC_GSI if ACPI
> >> >  select ACPI_REDUCED_HARDWARE_ONLY if ACPI
> >> >  select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> >> >diff --git a/arch/arm64/include/asm/dma-mapping.h 
> >> >b/arch/arm64/include/asm/dma-mapping.h
> >> >index 9437e3d..f0d6d0b 100644
> >> >--- a/arch/arm64/include/asm/dma-mapping.h
> >> >+++ b/arch/arm64/include/asm/dma-mapping.h
> >> >@@ -18,6 +18,7 @@
> >> >
> >> >  #ifdef __KERNEL__
> >> >
> >> >+#include 
> >> >  #include 
> >> >  #include 
> >> >
> > ^^^ This hunk causes build issues with a couple of drivers:
> >
> > drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined 
> > [enabled by default]
> >   #define FALSE 0
> >   ^
> > In file included from include/acpi/acpi.h:58:0,
> >   from include/linux/acpi.h:37,
> >   from ./arch/arm64/include/asm/dma-mapping.h:21,
> >   from include/linux/dma-mapping.h:86,
> >   from ./arch/arm64/include/asm/pci.h:7,
> >   from include/linux/pci.h:1460,
> >   from drivers/scsi/megaraid/megaraid_sas_fp.c:37:
> > include/acpi/actypes.h:433:0: note: this is the location of the previous 
> > definition
> >   #define FALSE   (1 == 0)
> >   ^
> >
> >
> > In file included from include/acpi/acpi.h:58:0,
> >   from include/linux/acpi.h:37,
> >   from ./arch/arm64/include/asm/dma-mapping.h:21,
> >   from include/linux/dma-mapping.h:86,
> >   from include/scsi/scsi_cmnd.h:4,
> >   from drivers/scsi/ufs/ufshcd.h:60,
> >   from drivers/scsi/ufs/ufshcd.c:43:
> > include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token
> >   #define FALSE   (1 == 0)
> >   ^
> > drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’
> >FALSE = 0,
> >^
> >
> > This happens because the ACPI definitions of TRUE and FALSE conflict
> > with local definitions in megaraid and enum declaration in ufs.
> >
> Mark,
> 
> Thanks for pointing this out. Although, I would think that the 
> megaraid_sas_fp.c should have had the #ifndef to check before defining 
> the TRUE and FALSE as following.
> 
> #ifndef TRUE
> #define TRUE 1
> #endif
> #ifndef FALSE
> #define FALSE 0
> #endif
> 
> This seems to be what other drivers are also doing. If this is okay, I 
> can send out a fix-up patch for the megaraid driver.
> 

Yeah, or #undef them if defined so megaraid defines them as desired.
And #undef if defined would work for unipro.h as well.


--
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] mptsas: fix depth param in scsi_track_queue_full

2015-06-03 Thread Tomas Henzl

v2: use debug log level to silence the unsurprising information

v1: A user of scsi_track_queue_full should pass to the function
a constant value untill the queue-depth changes, otherwise the
internal logic in scsi_track_queue_full rejects the change.
Other users of this function use a 'sdev->queue_depth - 1'
as depth parameter, let's do the same.

Signed-off-by: Tomas Henzl 
---
 drivers/message/fusion/mptsas.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 551262e4b9..fe8f277567 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -4096,7 +4096,7 @@ mptsas_handle_queue_full_event(struct fw_event_work 
*fw_event)
continue;
}
depth = scsi_track_queue_full(sdev,
-   current_depth - 1);
+   sdev->queue_depth - 1);
if (depth > 0)
sdev_printk(KERN_INFO, sdev,
"Queue depth reduced to (%d)\n",
@@ -4106,7 +4106,7 @@ mptsas_handle_queue_full_event(struct fw_event_work 
*fw_event)
"Tagged Command Queueing is being "
"disabled\n");
else if (depth == 0)
-   sdev_printk(KERN_INFO, sdev,
+   sdev_printk(KERN_DEBUG, sdev,
"Queue depth not changed yet\n");
}
}
-- 
1.9.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] [trivial] scsi:fcoe: Fix typo "a ethernet" in fcoe_transport.c

2015-06-03 Thread Masanari Iida

This patch fix some "a ethernet" in MODULE_DESCRIPTIONS in
fcoe_transport.c

Signed-off-by: Masanari Iida 
---
 drivers/scsi/fcoe/fcoe_transport.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/fcoe/fcoe_transport.c 
b/drivers/scsi/fcoe/fcoe_transport.c
index bdc8989..d7597c0 100644
--- a/drivers/scsi/fcoe/fcoe_transport.c
+++ b/drivers/scsi/fcoe/fcoe_transport.c
@@ -58,7 +58,7 @@ MODULE_PARM_DESC(show, " Show attached FCoE transports");
 module_param_call(create, fcoe_transport_create, NULL,
  (void *)FIP_MODE_FABRIC, S_IWUSR);
 __MODULE_PARM_TYPE(create, "string");
-MODULE_PARM_DESC(create, " Creates fcoe instance on a ethernet interface");
+MODULE_PARM_DESC(create, " Creates fcoe instance on an ethernet interface");
 
 module_param_call(create_vn2vn, fcoe_transport_create, NULL,
  (void *)FIP_MODE_VN2VN, S_IWUSR);
@@ -68,15 +68,15 @@ MODULE_PARM_DESC(create_vn2vn, " Creates a VN_node to 
VN_node FCoE instance "
 
 module_param_call(destroy, fcoe_transport_destroy, NULL, NULL, S_IWUSR);
 __MODULE_PARM_TYPE(destroy, "string");
-MODULE_PARM_DESC(destroy, " Destroys fcoe instance on a ethernet interface");
+MODULE_PARM_DESC(destroy, " Destroys fcoe instance on an ethernet interface");
 
 module_param_call(enable, fcoe_transport_enable, NULL, NULL, S_IWUSR);
 __MODULE_PARM_TYPE(enable, "string");
-MODULE_PARM_DESC(enable, " Enables fcoe on a ethernet interface.");
+MODULE_PARM_DESC(enable, " Enables fcoe on an ethernet interface.");
 
 module_param_call(disable, fcoe_transport_disable, NULL, NULL, S_IWUSR);
 __MODULE_PARM_TYPE(disable, "string");
-MODULE_PARM_DESC(disable, " Disables fcoe on a ethernet interface.");
+MODULE_PARM_DESC(disable, " Disables fcoe on an ethernet interface.");
 
 /* notification function for packets from net device */
 static struct notifier_block libfcoe_notifier = {
-- 
2.4.2.387.gf86f31a

--
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: bisected regression: qla2xxx endianness on sparc64

2015-06-03 Thread Joe Carnuccio

Meelis,

Yes, please revert that patch (it should never have deleted the calls to 
__constant_cpu_to_le16 (those fields are all LE in the HW/nvram)).

-Joe

-Original Message-
From: mr...@math.ut.ee [mailto:mr...@math.ut.ee] On Behalf Of Meelis Roos
Sent: Wednesday, June 03, 2015 1:21 AM
To: Christoph Hellwig
Cc: Chad Dupuis; Joe Carnuccio; Saurav Kashyap; Christoph Hellwig; Dept-Eng 
QLA2xxx Upstream; James E.J. Bottomley; linux-scsi; linux-kernel
Subject: Re: bisected regression: qla2xxx endianness on sparc64

On Mon, 10 Nov 2014, Christoph Hellwig wrote:

> On Mon, Nov 03, 2014 at 03:09:47PM -0500, Chad Dupuis wrote:
> > We should revert that change. What were some of the other failures 
> > you were seeing?
> 
> Can you please send me the revert ASAP?

Since QLogic is still silent on this one, I will send it to you:

Revert change that breaks QLA2XXX on big-endian systems,
__constant_cpu_to_le16() is still needed.

Signed-off-by: Meelis Roos 

diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h 
index 42bb357..88d3143 100644
--- a/drivers/scsi/qla2xxx/qla_fw.h
+++ b/drivers/scsi/qla2xxx/qla_fw.h
@@ -91,7 +91,7 @@ struct nvram_24xx {
/* Firmware Initialization Control Block. */
uint16_t version;
uint16_t reserved_1;
-   __le16 frame_payload_size;
+   uint16_t frame_payload_size;
uint16_t execution_throttle;
uint16_t exchange_count;
uint16_t hard_address;
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c 
index 285cb20..ed973a1 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2658,18 +2658,18 @@ qla2x00_nvram_config(scsi_qla_host_t *vha)
nv->firmware_options[1] = BIT_7 | BIT_5;
nv->add_firmware_options[0] = BIT_5;
nv->add_firmware_options[1] = BIT_5 | BIT_4;
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->special_options[1] = BIT_7;
} else if (IS_QLA2200(ha)) {
nv->firmware_options[0] = BIT_2 | BIT_1;
nv->firmware_options[1] = BIT_7 | BIT_5;
nv->add_firmware_options[0] = BIT_5;
nv->add_firmware_options[1] = BIT_5 | BIT_4;
-   nv->frame_payload_size = 1024;
+   nv->frame_payload_size = __constant_cpu_to_le16(1024);
} else if (IS_QLA2100(ha)) {
nv->firmware_options[0] = BIT_3 | BIT_1;
nv->firmware_options[1] = BIT_5;
-   nv->frame_payload_size = 1024;
+   nv->frame_payload_size = __constant_cpu_to_le16(1024);
}
 
nv->max_iocb_allocation = __constant_cpu_to_le16(256); @@ 
-2705,7 +2705,7 @@ qla2x00_nvram_config(scsi_qla_host_t *vha)
 * are valid.
 */
if (ia64_platform_is("sn2")) {
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
if (IS_QLA23XX(ha))
nv->special_options[1] = BIT_7;
}
@@ -5022,7 +5022,7 @@ qla24xx_nvram_config(scsi_qla_host_t *vha)
memset(nv, 0, ha->nvram_size);
nv->nvram_version = __constant_cpu_to_le16(ICB_VERSION);
nv->version = __constant_cpu_to_le16(ICB_VERSION);
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->execution_throttle = __constant_cpu_to_le16(0x);
nv->exchange_count = __constant_cpu_to_le16(0);
nv->hard_address = __constant_cpu_to_le16(124); @@ -5969,7 
+5969,7 @@ qla81xx_nvram_config(scsi_qla_host_t *vha)
memset(nv, 0, ha->nvram_size);
nv->nvram_version = __constant_cpu_to_le16(ICB_VERSION);
nv->version = __constant_cpu_to_le16(ICB_VERSION);
-   nv->frame_payload_size = 2048;
+   nv->frame_payload_size = __constant_cpu_to_le16(2048);
nv->execution_throttle = __constant_cpu_to_le16(0x);
nv->exchange_count = __constant_cpu_to_le16(0);
nv->port_name[0] = 0x21;

--
Meelis Roos (mr...@linux.ee)
<>

Re: linux-next: build failure after merge of the target-updates tree

2015-06-03 Thread James Bottomley

On Wed, 2015-06-03 at 18:16 +1000, Stephen Rothwell wrote:
> Hi Nicholas,
> 
> After merging the target-updates tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/target/target_core_fabric_lib.c: In function 
> 'target_get_pr_transport_id_len':
> drivers/target/target_core_fabric_lib.c:364:7: error: 'SCSI_PROTOCOL_FCP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_FCP:
>^
> drivers/target/target_core_fabric_lib.c:364:7: note: each undeclared 
> identifier is reported only once for each function it appears in
> drivers/target/target_core_fabric_lib.c:365:7: error: 'SCSI_PROTOCOL_SBP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SBP:
>^
> drivers/target/target_core_fabric_lib.c:366:7: error: 'SCSI_PROTOCOL_SRP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SRP:
>^
> drivers/target/target_core_fabric_lib.c:367:7: error: 'SCSI_PROTOCOL_SAS' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SAS:
>^
> drivers/target/target_core_fabric_lib.c:369:7: error: 'SCSI_PROTOCOL_ISCSI' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_ISCSI:
>^
> drivers/target/target_core_fabric_lib.c: In function 
> 'target_get_pr_transport_id':
> drivers/target/target_core_fabric_lib.c:388:7: error: 'SCSI_PROTOCOL_SAS' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SAS:
>^
> drivers/target/target_core_fabric_lib.c:390:7: error: 'SCSI_PROTOCOL_SBP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SBP:
>^
> drivers/target/target_core_fabric_lib.c:392:7: error: 'SCSI_PROTOCOL_SRP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SRP:
>^
> drivers/target/target_core_fabric_lib.c:394:7: error: 'SCSI_PROTOCOL_FCP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_FCP:
>^
> drivers/target/target_core_fabric_lib.c:396:7: error: 'SCSI_PROTOCOL_ISCSI' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_ISCSI:
>^
> drivers/target/target_core_fabric_lib.c: In function 
> 'target_parse_pr_out_transport_id':
> drivers/target/target_core_fabric_lib.c:411:7: error: 'SCSI_PROTOCOL_SAS' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SAS:
>^
> drivers/target/target_core_fabric_lib.c:418:7: error: 'SCSI_PROTOCOL_SBP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SBP:
>^
> drivers/target/target_core_fabric_lib.c:419:7: error: 'SCSI_PROTOCOL_SRP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_SRP:
>^
> drivers/target/target_core_fabric_lib.c:420:7: error: 'SCSI_PROTOCOL_FCP' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_FCP:
>^
> drivers/target/target_core_fabric_lib.c:423:7: error: 'SCSI_PROTOCOL_ISCSI' 
> undeclared (first use in this function)
>   case SCSI_PROTOCOL_ISCSI:
>^
> 
> Caused by commit 2650d71e244f ("target: move transport ID handling to
> the core") interacting with commit ba929992522b ("target: Minimize SCSI
> header #include directives") from the scsi tree.
> 
> I have added this merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 3 Jun 2015 18:10:46 +1000
> Subject: [PATCH] target: explicitly include scsi_proto.h in 
> target_core_fabric_lib.c
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/target/target_core_fabric_lib.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/target/target_core_fabric_lib.c 
> b/drivers/target/target_core_fabric_lib.c
> index b05578b5b4a0..cb6497ce4b61 100644
> --- a/drivers/target/target_core_fabric_lib.c
> +++ b/drivers/target/target_core_fabric_lib.c
> @@ -35,6 +35,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include 
>  #include 

OK, this gives us a cross tree dependency on the SCSI header split
patches.  Nic, if you base your tree off this commit in mine, I'll make
sure to push early in the merge window.

commit ba929992522b6d1f866b7021bc50da66f8fdd743
Author: Bart Van Assche 
Date:   Fri May 8 10:11:12 2015 +0200

target: Minimize SCSI header #include directives

James



signature.asc
Description: This is a digitally signed message part

[PATCH V2 0/7] scsi: storvsc: Some miscellaneous cleanup

2015-06-03 Thread K. Y. Srinivasan

Cleanup version handling as well as base feature detection on storage
version as opposed to host version.

In this version, I have addressed comments from Dan Carpenter.

K. Y. Srinivasan (1):
  scsi: storvsc: Set the error code correctly in failure conditions

Keith Mange (6):
  scsi: storvsc: Rather than look for sets of specific protocol
versions, make decisions based on ranges.
  scsi: storvsc: Use a single value to track protocol versions
  scsi: storvsc: Untangle the storage protocol negotiation from the
vmbus protocol negotiation.
  scsi: storvsc: use correct defaults for values determined by protocol
negotiation
  scsi: storvsc: use storage protocol version to determine storage
capabilities
  scsi: storvsc: Allow write_same when host is windows 10

 drivers/scsi/storvsc_drv.c |  206 
 1 files changed, 132 insertions(+), 74 deletions(-)

-- 
1.7.4.1

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

[PATCH V2 5/7] scsi: storvsc: use storage protocol version to determine storage capabilities

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Use storage protocol version instead of vmbus protocol
version when determining storage capabilities.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 6f38cdf..58fa47a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1049,7 +1049,7 @@ static int storvsc_channel_init(struct hv_device *device)
 * support multi-channel.
 */
max_chns = vstor_packet->storage_channel_properties.max_channel_cnt;
-   if (vmbus_proto_version >= VERSION_WIN8) {
+   if (vmstor_proto_version >= VMSTOR_PROTO_VERSION_WIN8) {
if (vstor_packet->storage_channel_properties.flags &
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
process_sub_channels = true;
@@ -1491,9 +1491,9 @@ static int storvsc_device_configure(struct scsi_device 
*sdevice)
 * if the device is a MSFT virtual device.
 */
if (!strncmp(sdevice->vendor, "Msft", 4)) {
-   switch (vmbus_proto_version) {
-   case VERSION_WIN8:
-   case VERSION_WIN8_1:
+   switch (vmstor_proto_version) {
+   case VMSTOR_PROTO_VERSION_WIN8:
+   case VMSTOR_PROTO_VERSION_WIN8_1:
sdevice->scsi_level = SCSI_SPC_3;
break;
}
-- 
1.7.4.1

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

[PATCH V2 3/7] scsi: storvsc: Untangle the storage protocol negotiation from the vmbus protocol negotiation.

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Currently we are making decisions based on vmbus protocol versions
that have been negotiated; use storage potocol versions instead.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |  109 +++-
 1 files changed, 87 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 5f9d133..f29871e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -56,14 +56,18 @@
  * V1 RC > 2008/1/31:  2.0
  * Win7: 4.2
  * Win8: 5.1
+ * Win8.1: 6.0
+ * Win10: 6.2
  */
 
 #define VMSTOR_PROTO_VERSION(MAJOR_, MINOR_)   MAJOR_) & 0xff) << 8) | \
(((MINOR_) & 0xff)))
 
+#define VMSTOR_PROTO_VERSION_WIN6  VMSTOR_PROTO_VERSION(2, 0)
 #define VMSTOR_PROTO_VERSION_WIN7  VMSTOR_PROTO_VERSION(4, 2)
 #define VMSTOR_PROTO_VERSION_WIN8  VMSTOR_PROTO_VERSION(5, 1)
-
+#define VMSTOR_PROTO_VERSION_WIN8_1VMSTOR_PROTO_VERSION(6, 0)
+#define VMSTOR_PROTO_VERSION_WIN10 VMSTOR_PROTO_VERSION(6, 2)
 
 /*  Packet structure describing virtual storage requests. */
 enum vstor_packet_operation {
@@ -205,6 +209,46 @@ struct vmscsi_request {
 
 
 /*
+ * The list of storage protocols in order of preference.
+ */
+struct vmstor_protocol {
+   int protocol_version;
+   int sense_buffer_size;
+   int vmscsi_size_delta;
+};
+
+#define VMSTOR_NUM_PROTOCOLS5
+
+const struct vmstor_protocol vmstor_protocols[VMSTOR_NUM_PROTOCOLS] = {
+   {
+   VMSTOR_PROTO_VERSION_WIN10,
+   POST_WIN7_STORVSC_SENSE_BUFFER_SIZE,
+   0
+   },
+   {
+   VMSTOR_PROTO_VERSION_WIN8_1,
+   POST_WIN7_STORVSC_SENSE_BUFFER_SIZE,
+   0
+   },
+   {
+   VMSTOR_PROTO_VERSION_WIN8,
+   POST_WIN7_STORVSC_SENSE_BUFFER_SIZE,
+   0
+   },
+   {
+   VMSTOR_PROTO_VERSION_WIN7,
+   PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE,
+   sizeof(struct vmscsi_win8_extension),
+   },
+   {
+   VMSTOR_PROTO_VERSION_WIN6,
+   PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE,
+   sizeof(struct vmscsi_win8_extension),
+   }
+};
+
+
+/*
  * This structure is sent during the intialization phase to get the different
  * properties of the channel.
  */
@@ -871,7 +915,7 @@ static int storvsc_channel_init(struct hv_device *device)
struct storvsc_device *stor_device;
struct storvsc_cmd_request *request;
struct vstor_packet *vstor_packet;
-   int ret, t;
+   int ret, t, i;
int max_chns;
bool process_sub_channels = false;
 
@@ -911,36 +955,59 @@ static int storvsc_channel_init(struct hv_device *device)
goto cleanup;
 
 
-   /* reuse the packet for version range supported */
-   memset(vstor_packet, 0, sizeof(struct vstor_packet));
-   vstor_packet->operation = VSTOR_OPERATION_QUERY_PROTOCOL_VERSION;
-   vstor_packet->flags = REQUEST_COMPLETION_FLAG;
+   for (i = 0; i < VMSTOR_NUM_PROTOCOLS; i++) {
+   /* reuse the packet for version range supported */
+   memset(vstor_packet, 0, sizeof(struct vstor_packet));
+   vstor_packet->operation =
+   VSTOR_OPERATION_QUERY_PROTOCOL_VERSION;
+   vstor_packet->flags = REQUEST_COMPLETION_FLAG;
 
-   vstor_packet->version.major_minor = vmstor_proto_version;
+   vstor_packet->version.major_minor =
+   vmstor_protocols[i].protocol_version;
 
-   /*
-* The revision number is only used in Windows; set it to 0.
-*/
-   vstor_packet->version.revision = 0;
+   /*
+* The revision number is only used in Windows; set it to 0.
+*/
+   vstor_packet->version.revision = 0;
 
-   ret = vmbus_sendpacket(device->channel, vstor_packet,
+   ret = vmbus_sendpacket(device->channel, vstor_packet,
   (sizeof(struct vstor_packet) -
vmscsi_size_delta),
   (unsigned long)request,
   VM_PKT_DATA_INBAND,
   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
-   if (ret != 0)
-   goto cleanup;
+   if (ret != 0)
+   goto cleanup;
 
-   t = wait_for_completion_timeout(&request->wait_event, 5*HZ);
-   if (t == 0) {
-   ret = -ETIMEDOUT;
-   goto cleanup;
+   t = wait_for_completion_timeout(&request->wait_event, 5*HZ);
+   if (t == 0) {
+   ret = -ETIMEDOUT;
+   goto cleanup;
+   }
+
+   if (vstor_packet->operation != VSTOR_OPERATION_COMPLETE_IO) {
+

[PATCH V2 1/7] scsi: storvsc: Rather than look for sets of specific protocol versions, make decisions based on ranges.

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Rather than look for sets of specific protocol versions,
make decisions based on ranges. This will be safer and require fewer changes
going forward as we add more storage protocol versions.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |   11 +++
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3c6584f..582f3b5 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -988,8 +988,7 @@ static int storvsc_channel_init(struct hv_device *device)
 * support multi-channel.
 */
max_chns = vstor_packet->storage_channel_properties.max_channel_cnt;
-   if ((vmbus_proto_version != VERSION_WIN7) &&
-  (vmbus_proto_version != VERSION_WS2008))  {
+   if (vmbus_proto_version >= VERSION_WIN8) {
if (vstor_packet->storage_channel_properties.flags &
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
process_sub_channels = true;
@@ -1758,9 +1757,7 @@ static int storvsc_probe(struct hv_device *device,
 * set state to properly communicate with the host.
 */
 
-   switch (vmbus_proto_version) {
-   case VERSION_WS2008:
-   case VERSION_WIN7:
+   if (vmbus_proto_version < VERSION_WIN8) {
sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
vmstor_current_major = VMSTOR_WIN7_MAJOR;
@@ -1768,8 +1765,7 @@ static int storvsc_probe(struct hv_device *device,
max_luns_per_target = STORVSC_IDE_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_IDE_MAX_TARGETS;
max_channels = STORVSC_IDE_MAX_CHANNELS;
-   break;
-   default:
+   } else {
sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = 0;
vmstor_current_major = VMSTOR_WIN8_MAJOR;
@@ -1783,7 +1779,6 @@ static int storvsc_probe(struct hv_device *device,
 * VCPUs in the guest.
 */
max_sub_channels = (num_cpus / storvsc_vcpus_per_sub_channel);
-   break;
}
 
scsi_driver.can_queue = (max_outstanding_req_per_channel *
-- 
1.7.4.1

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

[PATCH V2 7/7] scsi: storvsc: Set the error code correctly in failure conditions

2015-06-03 Thread K. Y. Srinivasan

In the function storvsc_channel_init(), error code was not getting
set correctly in some of the failure cases. Fix this issue.

Signed-off-by: K. Y. Srinivasan 
Reported-by: Dan Carpenter 
---
 drivers/scsi/storvsc_drv.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 021cbdf..aac8297 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -960,8 +960,10 @@ static int storvsc_channel_init(struct hv_device *device)
}
 
if (vstor_packet->operation != VSTOR_OPERATION_COMPLETE_IO ||
-   vstor_packet->status != 0)
+   vstor_packet->status != 0) {
+   ret = -EINVAL;
goto cleanup;
+   }
 
 
for (i = 0; i < VMSTOR_NUM_PROTOCOLS; i++) {
@@ -1040,8 +1042,10 @@ static int storvsc_channel_init(struct hv_device *device)
}
 
if (vstor_packet->operation != VSTOR_OPERATION_COMPLETE_IO ||
-   vstor_packet->status != 0)
+   vstor_packet->status != 0) {
+   ret = -EINVAL;
goto cleanup;
+   }
 
/*
 * Check to see if multi-channel support is there.
@@ -1078,8 +1082,10 @@ static int storvsc_channel_init(struct hv_device *device)
}
 
if (vstor_packet->operation != VSTOR_OPERATION_COMPLETE_IO ||
-   vstor_packet->status != 0)
+   vstor_packet->status != 0) {
+   ret = -EINVAL;
goto cleanup;
+   }
 
if (process_sub_channels)
handle_multichannel_storage(device, max_chns);
-- 
1.7.4.1

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

[PATCH V2 4/7] scsi: storvsc: use correct defaults for values determined by protocol negotiation

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Use correct defaults for values determined by protocol negotiation,
instead of resetting them with every scsi controller.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |   33 +++--
 1 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index f29871e..6f38cdf 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -151,19 +151,17 @@ struct hv_fc_wwn_packet {
 
 /*
  * Sense buffer size changed in win8; have a run-time
- * variable to track the size we should use.
+ * variable to track the size we should use.  This value will
+ * likely change during protocol negotiation but it is valid
+ * to start by assuming pre-Win8.
  */
-static int sense_buffer_size;
+static int sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
 
 /*
- * The size of the vmscsi_request has changed in win8. The
- * additional size is because of new elements added to the
- * structure. These elements are valid only when we are talking
- * to a win8 host.
- * Track the correction to size we need to apply.
- */
-
-static int vmscsi_size_delta;
+ * The storage protocol version is determined during the
+ * initial exchange with the host.  It will indicate which
+ * storage functionality is available in the host.
+*/
 static int vmstor_proto_version;
 
 struct vmscsi_win8_extension {
@@ -209,6 +207,17 @@ struct vmscsi_request {
 
 
 /*
+ * The size of the vmscsi_request has changed in win8. The
+ * additional size is because of new elements added to the
+ * structure. These elements are valid only when we are talking
+ * to a win8 host.
+ * Track the correction to size we need to apply. This value
+ * will likely change during protocol negotiation but it is
+ * valid to start by assuming pre-Win8.
+ */
+static int vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
+
+/*
  * The list of storage protocols in order of preference.
  */
 struct vmstor_protocol {
@@ -1810,14 +1819,10 @@ static int storvsc_probe(struct hv_device *device,
 */
 
if (vmbus_proto_version < VERSION_WIN8) {
-   sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
-   vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
max_luns_per_target = STORVSC_IDE_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_IDE_MAX_TARGETS;
max_channels = STORVSC_IDE_MAX_CHANNELS;
} else {
-   sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
-   vmscsi_size_delta = 0;
max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_MAX_TARGETS;
max_channels = STORVSC_MAX_CHANNELS;
-- 
1.7.4.1

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

[PATCH V2 2/7] scsi: storvsc: Use a single value to track protocol versions

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Use a single value to track protocol versions to simplify
comparisons and to be consistent with vmbus version tracking.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |   35 +--
 1 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 582f3b5..5f9d133 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -58,12 +58,11 @@
  * Win8: 5.1
  */
 
+#define VMSTOR_PROTO_VERSION(MAJOR_, MINOR_)   MAJOR_) & 0xff) << 8) | \
+   (((MINOR_) & 0xff)))
 
-#define VMSTOR_WIN7_MAJOR 4
-#define VMSTOR_WIN7_MINOR 2
-
-#define VMSTOR_WIN8_MAJOR 5
-#define VMSTOR_WIN8_MINOR 1
+#define VMSTOR_PROTO_VERSION_WIN7  VMSTOR_PROTO_VERSION(4, 2)
+#define VMSTOR_PROTO_VERSION_WIN8  VMSTOR_PROTO_VERSION(5, 1)
 
 
 /*  Packet structure describing virtual storage requests. */
@@ -161,8 +160,7 @@ static int sense_buffer_size;
  */
 
 static int vmscsi_size_delta;
-static int vmstor_current_major;
-static int vmstor_current_minor;
+static int vmstor_proto_version;
 
 struct vmscsi_win8_extension {
/*
@@ -481,18 +479,6 @@ done:
kfree(wrk);
 }
 
-/*
- * Major/minor macros.  Minor version is in LSB, meaning that earlier flat
- * version numbers will be interpreted as "0.x" (i.e., 1 becomes 0.1).
- */
-
-static inline u16 storvsc_get_version(u8 major, u8 minor)
-{
-   u16 version;
-
-   version = ((major << 8) | minor);
-   return version;
-}
 
 /*
  * We can get incoming messages from the host that are not in response to
@@ -930,8 +916,7 @@ static int storvsc_channel_init(struct hv_device *device)
vstor_packet->operation = VSTOR_OPERATION_QUERY_PROTOCOL_VERSION;
vstor_packet->flags = REQUEST_COMPLETION_FLAG;
 
-   vstor_packet->version.major_minor =
-   storvsc_get_version(vmstor_current_major, vmstor_current_minor);
+   vstor_packet->version.major_minor = vmstor_proto_version;
 
/*
 * The revision number is only used in Windows; set it to 0.
@@ -1562,7 +1547,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
u32 payload_sz;
u32 length;
 
-   if (vmstor_current_major <= VMSTOR_WIN8_MAJOR) {
+   if (vmstor_proto_version <= VMSTOR_PROTO_VERSION_WIN8) {
/*
 * On legacy hosts filter unimplemented commands.
 * Future hosts are expected to correctly handle
@@ -1760,16 +1745,14 @@ static int storvsc_probe(struct hv_device *device,
if (vmbus_proto_version < VERSION_WIN8) {
sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
-   vmstor_current_major = VMSTOR_WIN7_MAJOR;
-   vmstor_current_minor = VMSTOR_WIN7_MINOR;
+   vmstor_proto_version = VMSTOR_PROTO_VERSION_WIN7;
max_luns_per_target = STORVSC_IDE_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_IDE_MAX_TARGETS;
max_channels = STORVSC_IDE_MAX_CHANNELS;
} else {
sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = 0;
-   vmstor_current_major = VMSTOR_WIN8_MAJOR;
-   vmstor_current_minor = VMSTOR_WIN8_MINOR;
+   vmstor_proto_version = VMSTOR_PROTO_VERSION_WIN8;
max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_MAX_TARGETS;
max_channels = STORVSC_MAX_CHANNELS;
-- 
1.7.4.1

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

[PATCH V2 6/7] scsi: storvsc: Allow write_same when host is windows 10

2015-06-03 Thread K. Y. Srinivasan

From: Keith Mange 

Allow WRITE_SAME for Windows10 and above hosts.

Tested-by: Alex Ng 
Signed-off-by: Keith Mange 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 58fa47a..021cbdf 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1488,7 +1488,8 @@ static int storvsc_device_configure(struct scsi_device 
*sdevice)
 
/*
 * If the host is WIN8 or WIN8 R2, claim conformance to SPC-3
-* if the device is a MSFT virtual device.
+* if the device is a MSFT virtual device.  If the host is
+* WIN10 or newer, allow write_same.
 */
if (!strncmp(sdevice->vendor, "Msft", 4)) {
switch (vmstor_proto_version) {
@@ -1497,6 +1498,9 @@ static int storvsc_device_configure(struct scsi_device 
*sdevice)
sdevice->scsi_level = SCSI_SPC_3;
break;
}
+
+   if (vmstor_proto_version >= VMSTOR_PROTO_VERSION_WIN10)
+   sdevice->no_write_same = 0;
}
 
return 0;
-- 
1.7.4.1

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

Re: linux-next: build failure after merge of the target-updates tree

2015-06-03 Thread Nicholas A. Bellinger

On Wed, 2015-06-03 at 13:00 -0700, James Bottomley wrote:
> On Wed, 2015-06-03 at 18:16 +1000, Stephen Rothwell wrote:
> > Hi Nicholas,
> > 
> > After merging the target-updates tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/target/target_core_fabric_lib.c: In function 
> > 'target_get_pr_transport_id_len':
> > drivers/target/target_core_fabric_lib.c:364:7: error: 'SCSI_PROTOCOL_FCP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_FCP:
> >^
> > drivers/target/target_core_fabric_lib.c:364:7: note: each undeclared 
> > identifier is reported only once for each function it appears in
> > drivers/target/target_core_fabric_lib.c:365:7: error: 'SCSI_PROTOCOL_SBP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SBP:
> >^
> > drivers/target/target_core_fabric_lib.c:366:7: error: 'SCSI_PROTOCOL_SRP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SRP:
> >^
> > drivers/target/target_core_fabric_lib.c:367:7: error: 'SCSI_PROTOCOL_SAS' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SAS:
> >^
> > drivers/target/target_core_fabric_lib.c:369:7: error: 'SCSI_PROTOCOL_ISCSI' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_ISCSI:
> >^
> > drivers/target/target_core_fabric_lib.c: In function 
> > 'target_get_pr_transport_id':
> > drivers/target/target_core_fabric_lib.c:388:7: error: 'SCSI_PROTOCOL_SAS' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SAS:
> >^
> > drivers/target/target_core_fabric_lib.c:390:7: error: 'SCSI_PROTOCOL_SBP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SBP:
> >^
> > drivers/target/target_core_fabric_lib.c:392:7: error: 'SCSI_PROTOCOL_SRP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SRP:
> >^
> > drivers/target/target_core_fabric_lib.c:394:7: error: 'SCSI_PROTOCOL_FCP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_FCP:
> >^
> > drivers/target/target_core_fabric_lib.c:396:7: error: 'SCSI_PROTOCOL_ISCSI' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_ISCSI:
> >^
> > drivers/target/target_core_fabric_lib.c: In function 
> > 'target_parse_pr_out_transport_id':
> > drivers/target/target_core_fabric_lib.c:411:7: error: 'SCSI_PROTOCOL_SAS' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SAS:
> >^
> > drivers/target/target_core_fabric_lib.c:418:7: error: 'SCSI_PROTOCOL_SBP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SBP:
> >^
> > drivers/target/target_core_fabric_lib.c:419:7: error: 'SCSI_PROTOCOL_SRP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_SRP:
> >^
> > drivers/target/target_core_fabric_lib.c:420:7: error: 'SCSI_PROTOCOL_FCP' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_FCP:
> >^
> > drivers/target/target_core_fabric_lib.c:423:7: error: 'SCSI_PROTOCOL_ISCSI' 
> > undeclared (first use in this function)
> >   case SCSI_PROTOCOL_ISCSI:
> >^
> > 
> > Caused by commit 2650d71e244f ("target: move transport ID handling to
> > the core") interacting with commit ba929992522b ("target: Minimize SCSI
> > header #include directives") from the scsi tree.
> > 
> > I have added this merge fix patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Wed, 3 Jun 2015 18:10:46 +1000
> > Subject: [PATCH] target: explicitly include scsi_proto.h in 
> > target_core_fabric_lib.c
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  drivers/target/target_core_fabric_lib.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/target/target_core_fabric_lib.c 
> > b/drivers/target/target_core_fabric_lib.c
> > index b05578b5b4a0..cb6497ce4b61 100644
> > --- a/drivers/target/target_core_fabric_lib.c
> > +++ b/drivers/target/target_core_fabric_lib.c
> > @@ -35,6 +35,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  #include 
> >  #include 
> 
> OK, this gives us a cross tree dependency on the SCSI header split
> patches.  Nic, if you base your tree off this commit in mine, I'll make
> sure to push early in the merge window.
> 
> commit ba929992522b6d1f866b7021bc50da66f8fdd743
> Author: Bart Van Assche 
> Date:   Fri May 8 10:11:12 2015 +0200
> 
> target: Minimize SCSI header #include directives
> 

Rebasing one subsystem's for-next atop another subsystem's for-next is a
sure fire way to cause Linus to become irate.

But it's not even necessary here anyways, just fold Stephen's patch to
add scsi_proto.h to target_core_fabric_configfs.c into the original
change, and be done with it.

--nab

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

Re: linux-next: build failure after merge of the target-updates tree

2015-06-03 Thread James Bottomley

On Wed, 2015-06-03 at 15:12 -0700, Nicholas A. Bellinger wrote:
> On Wed, 2015-06-03 at 13:00 -0700, James Bottomley wrote:
> > On Wed, 2015-06-03 at 18:16 +1000, Stephen Rothwell wrote:
> > > Hi Nicholas,
> > > 
> > > After merging the target-updates tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > drivers/target/target_core_fabric_lib.c: In function 
> > > 'target_get_pr_transport_id_len':
> > > drivers/target/target_core_fabric_lib.c:364:7: error: 'SCSI_PROTOCOL_FCP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_FCP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:364:7: note: each undeclared 
> > > identifier is reported only once for each function it appears in
> > > drivers/target/target_core_fabric_lib.c:365:7: error: 'SCSI_PROTOCOL_SBP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SBP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:366:7: error: 'SCSI_PROTOCOL_SRP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SRP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:367:7: error: 'SCSI_PROTOCOL_SAS' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SAS:
> > >^
> > > drivers/target/target_core_fabric_lib.c:369:7: error: 
> > > 'SCSI_PROTOCOL_ISCSI' undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_ISCSI:
> > >^
> > > drivers/target/target_core_fabric_lib.c: In function 
> > > 'target_get_pr_transport_id':
> > > drivers/target/target_core_fabric_lib.c:388:7: error: 'SCSI_PROTOCOL_SAS' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SAS:
> > >^
> > > drivers/target/target_core_fabric_lib.c:390:7: error: 'SCSI_PROTOCOL_SBP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SBP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:392:7: error: 'SCSI_PROTOCOL_SRP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SRP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:394:7: error: 'SCSI_PROTOCOL_FCP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_FCP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:396:7: error: 
> > > 'SCSI_PROTOCOL_ISCSI' undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_ISCSI:
> > >^
> > > drivers/target/target_core_fabric_lib.c: In function 
> > > 'target_parse_pr_out_transport_id':
> > > drivers/target/target_core_fabric_lib.c:411:7: error: 'SCSI_PROTOCOL_SAS' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SAS:
> > >^
> > > drivers/target/target_core_fabric_lib.c:418:7: error: 'SCSI_PROTOCOL_SBP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SBP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:419:7: error: 'SCSI_PROTOCOL_SRP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_SRP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:420:7: error: 'SCSI_PROTOCOL_FCP' 
> > > undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_FCP:
> > >^
> > > drivers/target/target_core_fabric_lib.c:423:7: error: 
> > > 'SCSI_PROTOCOL_ISCSI' undeclared (first use in this function)
> > >   case SCSI_PROTOCOL_ISCSI:
> > >^
> > > 
> > > Caused by commit 2650d71e244f ("target: move transport ID handling to
> > > the core") interacting with commit ba929992522b ("target: Minimize SCSI
> > > header #include directives") from the scsi tree.
> > > 
> > > I have added this merge fix patch for today:
> > > 
> > > From: Stephen Rothwell 
> > > Date: Wed, 3 Jun 2015 18:10:46 +1000
> > > Subject: [PATCH] target: explicitly include scsi_proto.h in 
> > > target_core_fabric_lib.c
> > > 
> > > Signed-off-by: Stephen Rothwell 
> > > ---
> > >  drivers/target/target_core_fabric_lib.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/target/target_core_fabric_lib.c 
> > > b/drivers/target/target_core_fabric_lib.c
> > > index b05578b5b4a0..cb6497ce4b61 100644
> > > --- a/drivers/target/target_core_fabric_lib.c
> > > +++ b/drivers/target/target_core_fabric_lib.c
> > > @@ -35,6 +35,8 @@
> > >  #include 
> > >  #include 
> > >  
> > > +#include 
> > > +
> > >  #include 
> > >  #include 
> > 
> > OK, this gives us a cross tree dependency on the SCSI header split
> > patches.  Nic, if you base your tree off this commit in mine, I'll make
> > sure to push early in the merge window.
> > 
> > commit ba929992522b6d1f866b7021bc50da66f8fdd743
> > Author: Bart Van Assche 
> > Date:   Fri May 8 10:11:12 2015 +0200
> > 
> > target: Minimize SCSI header #include directives
> > 
> 
> Rebasing one subsystem's for-next atop another subsystem's for-next is a
> sure fire way to cause Linus to become irate.

No, he's fine with it (as long as the trees aren't entangled when
submitted). We used t

Re: linux-next: build failure after merge of the target-updates tree

2015-06-03 Thread Nicholas A. Bellinger

On Wed, 2015-06-03 at 15:33 -0700, James Bottomley wrote:
> On Wed, 2015-06-03 at 15:12 -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2015-06-03 at 13:00 -0700, James Bottomley wrote:



> > > OK, this gives us a cross tree dependency on the SCSI header split
> > > patches.  Nic, if you base your tree off this commit in mine, I'll make
> > > sure to push early in the merge window.
> > > 
> > > commit ba929992522b6d1f866b7021bc50da66f8fdd743
> > > Author: Bart Van Assche 
> > > Date:   Fri May 8 10:11:12 2015 +0200
> > > 
> > > target: Minimize SCSI header #include directives
> > > 
> > 
> > Rebasing one subsystem's for-next atop another subsystem's for-next is a
> > sure fire way to cause Linus to become irate.
> 
> No, he's fine with it (as long as the trees aren't entangled when
> submitted). We used to do it all the time with the block and SCSI trees;
> it's why the scsi postmerge tree existed.
> 

...

> > But it's not even necessary here anyways, just fold Stephen's patch to
> > add scsi_proto.h to target_core_fabric_configfs.c into the original
> > change, and be done with it.
> 
> I can certainly do that, but other updates to the target tree could
> cause this problem to reoccur in different files.
> 

target_core_fabric_lib.c is the only place where SCSI_PROTOCOL_* is used
and I don't expect this to change before -rc1, so it should be OK to
just fold into the original.

--
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] fusion: remove dead MTRR code

2015-06-03 Thread Luis R. Rodriguez

On Fri, May 29, 2015 at 1:23 PM, Luis R. Rodriguez  wrote:
> On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez  wrote:
>> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
>>  wrote:
>>> From: "Luis R. Rodriguez" 
>>>
>>> If and when this gets enabled the driver could should split
>>> up IO memory space properly and that is quite a bit of work.
>>> Just remove the uncommented dead MTRR code then.
>>>
>>> There are a few motivations for this:
>>>
>>> a) Take advantage of PAT when available
>>>
>>> b) Help bury MTRR code away, MTRR is architecture specific and on
>>>x86 its replaced by PAT
>>>
>>> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>>>_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>>>de33c442e titled "x86 PAT: fix performance drop for glx,
>>>use UC minus for ioremap(), ioremap_nocache() and
>>>pci_mmap_page_range()")
>>
>> Hey folks, who's tree should this go through if agreeable?
>
> OK its been over 1 month without any replies on this patch which just
> removes commented out code.
>
> All the maintainers below bounce and the only e-mail not bouncing is
> for Sreekanth Reddy , he hasn't been
> seen active on linux-next since Jan 12 2015 when he did a driver bump
> for mpt2sas to 20.100.00.00.
>
> What's going on folks? And can this patch go in?
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aca2886..73dbc02 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6205,10 +6205,7 @@ S:   Maintained
>  F: arch/arm/mach-lpc32xx/
>
>  LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
> -M: Nagalakshmi Nandigama 
> -M: Praveen Krishnamoorthy 
>  M: Sreekanth Reddy 
> -M: Abhijit Mahajan 
>  L: mpt-fusionlinux@avagotech.com
>  L: linux-scsi@vger.kernel.org
>  W: http://www.lsilogic.com/support

OK so Avago bought Broadcom.

Does that impact how Avago will contribute to the Linux kernel? It has
been well over 1 month and I haven't seen any reply from Avago folks.

Andrew, is the silence sufficient enough reason for this patch to go
instead through your tree?

 Luis
--
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] fusion: remove dead MTRR code

2015-06-03 Thread Sreekanth Reddy

Hi Luis,

Sorry for delay in response. Actually I was looking for the history of
this section of code but I couldn't find it. Anyway this is dead code
and we are fine with removing this dead code.

James,

Please consider this patch as Acked-by: "Sreekanth Reddy"


Regards,
Sreekanth


On Wed, Apr 22, 2015 at 2:16 AM, Luis R. Rodriguez
 wrote:
> From: "Luis R. Rodriguez" 
>
> If and when this gets enabled the driver could should split
> up IO memory space properly and that is quite a bit of work.
> Just remove the uncommented dead MTRR code then.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
>x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>de33c442e titled "x86 PAT: fix performance drop for glx,
>use UC minus for ioremap(), ioremap_nocache() and
>pci_mmap_page_range()")
>
> Cc: Toshi Kani 
> Cc: Christoph Hellwig 
> Cc: Nagalakshmi Nandigama 
> Cc: Praveen Krishnamoorthy 
> Cc: Sreekanth Reddy 
> Cc: Abhijit Mahajan 
> Cc: linux-scsi@vger.kernel.org
> Cc: Andy Lutomirski 
> Cc: Suresh Siddha 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: Juergen Gross 
> Cc: Daniel Vetter 
> Cc: Juergen Gross 
> Cc: Dave Airlie 
> Cc: Antonino Daplas 
> Cc: Tomi Valkeinen 
> Cc: Ville Syrjälä 
> Cc: Mel Gorman 
> Cc: Vlastimil Babka 
> Cc: Borislav Petkov 
> Cc: Davidlohr Bueso 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: mpt-fusionlinux@avagotech.com
> Cc: linux-scsi@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 
> ---
>  drivers/message/fusion/mptbase.c | 24 
>  drivers/message/fusion/mptbase.h |  1 -
>  2 files changed, 25 deletions(-)
>
> diff --git a/drivers/message/fusion/mptbase.c 
> b/drivers/message/fusion/mptbase.c
> index 187f836..5dcc031 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -59,10 +59,6 @@
>  #include 
>  #include/* needed for in_interrupt() proto */
>  #include 
> -#include 
> -#ifdef CONFIG_MTRR
> -#include 
> -#endif
>  #include 
>  #include 
>
> @@ -2820,13 +2816,6 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
> pci_disable_device(ioc->pcidev);
> pci_release_selected_regions(ioc->pcidev, ioc->bars);
>
> -#if defined(CONFIG_MTRR) && 0
> -   if (ioc->mtrr_reg > 0) {
> -   mtrr_del(ioc->mtrr_reg, 0, 0);
> -   dprintk(ioc, printk(MYIOC_s_INFO_FMT "MTRR region 
> de-registered\n", ioc->name));
> -   }
> -#endif
> -
> /*  Zap the adapter lookup ptr!  */
> list_del(&ioc->list);
>
> @@ -4512,19 +4501,6 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
>
> ioc->req_frames_low_dma = (u32) (alloc_dma & 0x);
>
> -#if defined(CONFIG_MTRR) && 0
> -   /*
> -*  Enable Write Combining MTRR for IOC's memory region.
> -*  (at least as much as we can; "size and base must be
> -*  multiples of 4 kiB"
> -*/
> -   ioc->mtrr_reg = mtrr_add(ioc->req_frames_dma,
> -sz,
> -MTRR_TYPE_WRCOMB, 1);
> -   dprintk(ioc, printk(MYIOC_s_DEBUG_FMT "MTRR region registered 
> (base:size=%08x:%x)\n",
> -   ioc->name, ioc->req_frames_dma, sz));
> -#endif
> -
> for (i = 0; i < ioc->req_depth; i++) {
> alloc_dma += ioc->req_sz;
> mem += ioc->req_sz;
> diff --git a/drivers/message/fusion/mptbase.h 
> b/drivers/message/fusion/mptbase.h
> index 8f14090..813d463 100644
> --- a/drivers/message/fusion/mptbase.h
> +++ b/drivers/message/fusion/mptbase.h
> @@ -671,7 +671,6 @@ typedef struct _MPT_ADAPTER
> u8  *HostPageBuffer; /* SAS - host page buffer 
> support */
> u32 HostPageBuffer_sz;
> dma_addr_t  HostPageBuffer_dma;
> -   int  mtrr_reg;
> struct pci_dev  *pcidev;/* struct pci_dev pointer */
> int bars;   /* bitmask of BAR's that must 
> be configured */
> int msi_enable;
> --
> 2.3.2.209.gd67f9d5.dirty
>
--
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] advansys: fix compilation errors and warnings when CONFIG_PCI is not set

Re: bisected regression: qla2xxx endianness on sparc64

qla2xxx crash on sparc64 (bus error)

[PATCH v2 0/4] fixing building errors and warnings when components

[PATCH v2 1/4] phy: qcom-ufs: fix build error when the component is built as a module

[PATCH v2 3/4] scsi: ufs-qcom: update configuration option of SCSI_UFS_QCOM component

[PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device

[PATCH v2 2/4] scsi: ufs-qcom: fix compilation warning if compiled as a module

Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

Re: Patch "sd: Disable support for 256 byte/sector disks" has been added to the 4.0-stable tree

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

[PATCH v2] mptsas: fix depth param in scsi_track_queue_full

[PATCH] [trivial] scsi:fcoe: Fix typo "a ethernet" in fcoe_transport.c

RE: bisected regression: qla2xxx endianness on sparc64

Re: linux-next: build failure after merge of the target-updates tree

[PATCH V2 0/7] scsi: storvsc: Some miscellaneous cleanup

[PATCH V2 5/7] scsi: storvsc: use storage protocol version to determine storage capabilities

[PATCH V2 3/7] scsi: storvsc: Untangle the storage protocol negotiation from the vmbus protocol negotiation.

[PATCH V2 1/7] scsi: storvsc: Rather than look for sets of specific protocol versions, make decisions based on ranges.

[PATCH V2 7/7] scsi: storvsc: Set the error code correctly in failure conditions

[PATCH V2 4/7] scsi: storvsc: use correct defaults for values determined by protocol negotiation

[PATCH V2 2/7] scsi: storvsc: Use a single value to track protocol versions

[PATCH V2 6/7] scsi: storvsc: Allow write_same when host is windows 10

Re: linux-next: build failure after merge of the target-updates tree

Re: linux-next: build failure after merge of the target-updates tree

Re: linux-next: build failure after merge of the target-updates tree

Re: [PATCH v3] fusion: remove dead MTRR code

Re: [PATCH v3] fusion: remove dead MTRR code

31 matches

Site Navigation

Mail list logo

Footer information