[PATCH] advansys: fix compilation errors and warnings when CONFIG_PCI is not set
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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