[PATCH v5 2/2] add support for DWC UFS Host Controller
This patch has the goal to add support for DesignWare UFS Controller specific operations and to add specific platform and pci drivers. Signed-off-by: Joao Pinto--- Changes v4->v5 (Akinobu Mita): - All functions used only locally in ufshcd-dwc are now declared as static - ufshcd_dwc_configuration() was removed in ufshcd-dwc and a notify function (ufshcd_dwc_link_startup_notify) was created to deal with the DWC specific init routines - 20-bit RMMI option was removed from Kconfig. Now if MPHY TC is selected and 40-bit is not then it assumes a 20-bit config Changes v3->v4 (Arnd Bergmann and Mark Rutland): - SCSI_UFS_DWC_HOOKS is now silent and selected by the SCSI_UFS_DWC_PLAT or SCSI_UFS_DWC_PCI - Compatibility string has the ufs core version for info purposes since the driver is capable of getting the controller version from its registers - Created ufs-dwc-pci glue driver with specific DWC data - MPHY configuration remains in the ufshcd-dwc since it is unipro attribute writting only not following the a linux phy framework logic Changes v2->v3 (Julian Calaby): - Implement a common DWC code to be used by the platform and pci glue drivers - Synopsys ID & Class added to the existing pci driver and specific DWC was also added to the pci driver Changes v1->v2 (Akinobu Mita): - Implement a platform driver that uses the existing UFS core driver - Add DWC specific code to the existing UFS core driver Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 17 + MAINTAINERS | 6 + drivers/scsi/ufs/Kconfig | 41 ++ drivers/scsi/ufs/Makefile | 3 + drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++ drivers/scsi/ufs/ufs-dwc.c| 102 +++ drivers/scsi/ufs/ufshcd-dwc.c | 736 ++ drivers/scsi/ufs/ufshcd-dwc.h | 18 + drivers/scsi/ufs/ufshcd.c | 50 +- drivers/scsi/ufs/ufshcd.h | 13 + drivers/scsi/ufs/ufshci-dwc.h | 42 ++ drivers/scsi/ufs/ufshci.h | 1 + drivers/scsi/ufs/unipro.h | 39 ++ 13 files changed, 1231 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c create mode 100644 drivers/scsi/ufs/ufs-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h create mode 100644 drivers/scsi/ufs/ufshci-dwc.h diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt new file mode 100644 index 000..f38a3f5 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt @@ -0,0 +1,17 @@ +* Universal Flash Storage (UFS) DesignWare Host Controller + +DWC_UFSHC nodes are defined to describe on-chip UFS host controllers. +Each UFS controller instance should have its own node. + +Required properties: +- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1" + or "snps,ufshcd-2.0") +- reg : +- interrupts: + +Example: + dwc_ufshcd@0xD000 { + compatible = "snps,ufshcd-2.0"; + reg = < 0xD000 0x1 >; + interrupts = < 24 >; + }; diff --git a/MAINTAINERS b/MAINTAINERS index d2f94e2..3db3c4c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11006,6 +11006,12 @@ S: Supported F: Documentation/scsi/ufs.txt F: drivers/scsi/ufs/ +UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS +M: Joao Pinto +L: linux-scsi@vger.kernel.org +S: Supported +F: drivers/scsi/ufs/*dwc* + UNSORTED BLOCK IMAGES (UBI) M: Artem Bityutskiy M: Richard Weinberger diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index 5f45307..b4c353c 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -83,3 +83,44 @@ config SCSI_UFS_QCOM Select this if you have UFS controller on QCOM chipset. If unsure, say N. + +config SCSI_UFS_DWC_HOOKS + bool + +config SCSI_UFS_DWC_PLAT + tristate "DesignWare UFS controller platform glue driver" + depends on SCSI_UFSHCD_PLATFORM + select SCSI_UFS_DWC_HOOKS + help + This selects the DesignWare UFS host controller platform glue driver. + + Select this if you have a DesignWare UFS controller on Platform bus. + If unsure, say N. + +config SCSI_UFS_DWC_PCI + tristate "DesignWare UFS controller pci glue driver" + depends on SCSI_UFSHCD_PCI + select SCSI_UFS_DWC_HOOKS + help + This selects the DesignWare UFS host controller pci glue driver. + + Select this if you have a DesignWare UFS controller on pci bus. + If unsure, say N. +
[PATCH v5 0/2] add support for DWC UFS Controller
The work consisted of: - Fixed typo in ufshcd-pltfrm.c - Tweak ufshcd.c for UFS 2.0 support - Implement ufshcd-dwc which contains all DWC HW specific code - Unipro attributes were added and new registers were added to the driver - Implement a ufs-dwc glue platform driver - Implement a ufs-dwc-pci glue pci driver Joao Pinto (2): fixed typo in ufshcd-pltfrm add support for DWC UFS Host Controller Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 17 + MAINTAINERS | 6 + drivers/scsi/ufs/Kconfig | 41 ++ drivers/scsi/ufs/Makefile | 3 + drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++ drivers/scsi/ufs/ufs-dwc.c| 102 +++ drivers/scsi/ufs/ufshcd-dwc.c | 736 ++ drivers/scsi/ufs/ufshcd-dwc.h | 18 + drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +- drivers/scsi/ufs/ufshcd.c | 50 +- drivers/scsi/ufs/ufshcd.h | 13 + drivers/scsi/ufs/ufshci-dwc.h | 42 ++ drivers/scsi/ufs/ufshci.h | 1 + drivers/scsi/ufs/unipro.h | 39 ++ 14 files changed, 1232 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c create mode 100644 drivers/scsi/ufs/ufs-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h create mode 100644 drivers/scsi/ufs/ufshci-dwc.h -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] fixed typo in ufshcd-pltfrm
Fixed typo in ufshcd-pltfrm. Signed-off-by: Joao Pinto--- Changes v0->v5: - Nothing changed (just to keep up with patch set version). drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index d2a7b12..0522891 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init); MODULE_AUTHOR("Santosh Yaragnavi "); MODULE_AUTHOR("Vinayak Holikatti "); -MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver"); +MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver"); MODULE_LICENSE("GPL"); MODULE_VERSION(UFSHCD_DRIVER_VERSION); -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Separate target visibility from reaped state information
On Wed, 2016-02-10 at 15:05 +0100, Johannes Thumshirn wrote: > On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote: > > James Bottomley wrote: > > > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote: > > > > On 01/19/16 17:03, James Bottomley wrote: > > > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote: > > > > > > > > > > > "Bart" == Bart Van Assche < > > > > > > > > > > > bart.vanass...@sandisk.com> > > > > > > > > > > > writes: > > > > > > > > > > > > Bart> Instead of representing the states "visible in sysfs" > > > > > > and > > > > > > "has > > > > > > Bart> been removed from the target list" by a single state > > > > > > variable, > > > > > > use > > > > > > Bart> two variables to represent this information. > > > > > > > > > > > > James: Are you happy with the latest iteration of this? > > > > > > Should I > > > > > > queue > > > > > > it? > > > > > > > > > > Well, I'm OK with the patch: it's a simple transformation of > > > > > the > > > > > enumerated state to a two bit state. What I can't see is how > > > > > it > > > > > fixes > > > > > any soft lockup. > > > > > > > > > > The only change from the current workflow is that the DEL > > > > > transition > > > > > (now the reaped flag) is done before the spin lock is dropped > > > > > which > > > > > would fix a tiny window for two threads both trying to remove > > > > > the > > > > > same > > > > > target, but there's nothing that could possibly fix an > > > > > iterative > > > > > soft > > > > > lockup caused by restarting the loop, which is what the > > > > > changelog > > > > > says. > > > > > > > > Hello James, > > > > > > > > scsi_remove_target() doesn't lock the scan_mutex which means > > > > that > > > > concurrent SCSI scanning activity is not prohibited. Such > > > > scanning > > > > activity can postpone the transition of the state of a SCSI > > > > target > > > > into STARGET_DEL. I think if the scheduler decides to run the > > > > thread > > > > that executes scsi_remove_target() on the same CPU as the > > > > scanning > > > > code after the scanning code has obtained a reap ref and before > > > > the > > > > scanning code has released the reap ref again that the soft > > > > lockup > > > > can be triggered that has been reported by Sebastian Herbszt. > > > > > > OK, I finally understand the scenario; I'm not sure I understand > > > how > > > we're getting concurrent scanning and removal from a simple rmmod > > > ... I > > > take it this is insmod rmmod in a tight loop? > > > > I am able to trigger the soft lockup with this test case run once: > > > > modprobe lpfc > > run fio for 10 seconds > > rmmod lpfc > > > > My test setup involves running qla2xxx in target mode (SCST) and > > lpfc as initiator on the same system with one exported volume. > > > > Dick, how did you trigger the lockup? > > > > Sebastian > > Hi James, Bart, Martin > > Have you already decided, which of the two patches you favour and > when it'llbe included? > > I have several customer reports that hit this lockup and I don't want > to include one of the patches from the list just to find out the > other one's is used in mainline. Well, unless the target allocation bug gets fixed in Bart's, it will have to be the last_scan one. It's more a hack than a fix, but I suppose it will do as a bandaid in the meantime. If you have diagnosed this at customers, I'd still like to know what's holding the devices on removal. Thanks, 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] Separate target visibility from reaped state information
On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote: > James Bottomley wrote: > > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote: > > > On 01/19/16 17:03, James Bottomley wrote: > > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote: > > > > > > > > > > "Bart" == Bart Van Assche> > > > > > > > > > writes: > > > > > > > > > > Bart> Instead of representing the states "visible in sysfs" and > > > > > "has > > > > > Bart> been removed from the target list" by a single state > > > > > variable, > > > > > use > > > > > Bart> two variables to represent this information. > > > > > > > > > > James: Are you happy with the latest iteration of this? Should I > > > > > queue > > > > > it? > > > > > > > > Well, I'm OK with the patch: it's a simple transformation of the > > > > enumerated state to a two bit state. What I can't see is how it > > > > fixes > > > > any soft lockup. > > > > > > > > The only change from the current workflow is that the DEL > > > > transition > > > > (now the reaped flag) is done before the spin lock is dropped which > > > > would fix a tiny window for two threads both trying to remove the > > > > same > > > > target, but there's nothing that could possibly fix an iterative > > > > soft > > > > lockup caused by restarting the loop, which is what the changelog > > > > says. > > > > > > Hello James, > > > > > > scsi_remove_target() doesn't lock the scan_mutex which means that > > > concurrent SCSI scanning activity is not prohibited. Such scanning > > > activity can postpone the transition of the state of a SCSI target > > > into STARGET_DEL. I think if the scheduler decides to run the thread > > > that executes scsi_remove_target() on the same CPU as the scanning > > > code after the scanning code has obtained a reap ref and before the > > > scanning code has released the reap ref again that the soft lockup > > > can be triggered that has been reported by Sebastian Herbszt. > > > > OK, I finally understand the scenario; I'm not sure I understand how > > we're getting concurrent scanning and removal from a simple rmmod ... I > > take it this is insmod rmmod in a tight loop? > > I am able to trigger the soft lockup with this test case run once: > > modprobe lpfc > run fio for 10 seconds > rmmod lpfc > > My test setup involves running qla2xxx in target mode (SCST) and > lpfc as initiator on the same system with one exported volume. > > Dick, how did you trigger the lockup? > > Sebastian Hi James, Bart, Martin Have you already decided, which of the two patches you favour and when it'll be included? I have several customer reports that hit this lockup and I don't want to include one of the patches from the list just to find out the other one's is used in mainline. Thanks in advance, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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] scsi: fix soft lockup in scsi_remove_target() on module removal
This softlockup is currently happening: [ 444.088002] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/1:1:29] [ 444.088002] Modules linked in: lpfc(-) qla2x00tgt(O) qla2xxx_scst(O) scst_vdisk(O) scsi_transport_fc libcrc32c scst(O) dlm configfs nfsd lockd grace nfs_acl auth_rpcgss sunrpc ed d snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device dm_mod iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic gpio_ich iTCO_vendor_support ppdev snd_hda_intel snd_hda_codec snd_hda _core snd_hwdep tg3 snd_pcm snd_timer libphy lpc_ich parport_pc ptp acpi_cpufreq snd pps_core fjes parport i2c_i801 ehci_pci tpm_tis tpm sr_mod cdrom soundcore floppy hwmon sg 8250_ fintek pcspkr i915 drm_kms_helper uhci_hcd ehci_hcd drm fb_sys_fops sysimgblt sysfillrect syscopyarea i2c_algo_bit usbcore button video usb_common fan ata_generic ata_piix libata th ermal [ 444.088002] CPU: 1 PID: 29 Comm: kworker/1:1 Tainted: G O 4.4.0-rc5-2.g1e923a3-default #1 [ 444.088002] Hardware name: FUJITSU SIEMENS ESPRIMO E /D2164-A1, BIOS 5.00 R1.10.2164.A1 05/08/2006 [ 444.088002] Workqueue: fc_wq_4 fc_rport_final_delete [scsi_transport_fc] [ 444.088002] task: f6266ec0 ti: f6268000 task.ti: f6268000 [ 444.088002] EIP: 0060:[] EFLAGS: 0286 CPU: 1 [ 444.088002] EIP is at _raw_spin_unlock_irqrestore+0x14/0x20 [ 444.088002] EAX: 0286 EBX: f20d3800 ECX: 0002 EDX: 0286 [ 444.088002] ESI: f50ba800 EDI: f2146848 EBP: f6269ec8 ESP: f6269ec8 [ 444.088002] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 444.088002] CR0: 8005003b CR2: 08f96600 CR3: 363ae000 CR4: 06d0 [ 444.088002] Stack: [ 444.088002] f6269eec c066b0f7 0286 f2146848 f50ba808 f50ba800 f50ba800 f2146a90 [ 444.088002] f2146848 f6269f08 f8f0a4ed f3141000 f2146800 f2146a90 f619fa00 0040 [ 444.088002] f6269f40 c026cb25 0001 166c6392 0061 f6757140 f6136340 0004 [ 444.088002] Call Trace: [ 444.088002] [] scsi_remove_target+0x167/0x1c0 [ 444.088002] [] fc_rport_final_delete+0x9d/0x1e0 [scsi_transport_fc] [ 444.088002] [] process_one_work+0x155/0x3e0 [ 444.088002] [] worker_thread+0x37/0x490 [ 444.088002] [] kthread+0x9b/0xb0 [ 444.088002] [] ret_from_kernel_thread+0x21/0x40 What appears to be happening is that something has pinned the target so it can't go into STARGET_DEL via final release and the loop in scsi_remove_target spins endlessly until that happens. The fix for this soft lockup is to not keep looping over a device that we've called remove on but which hasn't gone into DEL state. This patch will retain a simplistic memory of the last target and not keep looping over it. Reported-by: Sebastian HerbsztTested-by: Sebastian Herbszt Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38 Cc: sta...@vger.kernel.org Signed-off-by: James Bottomley --- diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 4f18a85..00bc721 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1272,16 +1272,18 @@ static void __scsi_remove_target(struct scsi_target *starget) void scsi_remove_target(struct device *dev) { struct Scsi_Host *shost = dev_to_shost(dev->parent); - struct scsi_target *starget; + struct scsi_target *starget, *last_target = NULL; unsigned long flags; restart: spin_lock_irqsave(shost->host_lock, flags); list_for_each_entry(starget, >__targets, siblings) { - if (starget->state == STARGET_DEL) + if (starget->state == STARGET_DEL || + starget == last_target) continue; if (starget->dev.parent == dev || >dev == dev) { kref_get(>reap_ref); + last_target = starget; spin_unlock_irqrestore(shost->host_lock, flags); __scsi_remove_target(starget); scsi_target_reap(starget); -- 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] be2iscsi: Fix memory leak in beiscsi_alloc_mem()
> "Maurizio" == Maurizio Lombardiwrites: Jitendra, Please review. > In case of error, the memory allocated for phwi_ctrlr was not freed. > > Signed-off-by: Maurizio Lombardi > --- > drivers/scsi/be2iscsi/be_main.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c > index 7a6dbfb..360aa88 100644 > --- a/drivers/scsi/be2iscsi/be_main.c > +++ b/drivers/scsi/be2iscsi/be_main.c > @@ -2706,8 +2706,10 @@ static int beiscsi_alloc_mem(struct beiscsi_hba *phba) > phwi_ctrlr->wrb_context = kzalloc(sizeof(struct hwi_wrb_context) * > phba->params.cxns_per_ctrl, > GFP_KERNEL); > - if (!phwi_ctrlr->wrb_context) > + if (!phwi_ctrlr->wrb_context) { > + kfree(phba->phwi_ctrlr); > return -ENOMEM; > + } > > phba->init_mem = kcalloc(SE_MEM_MAX, sizeof(*mem_descr), >GFP_KERNEL); > -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] megaraid_sas: add an i/o barrier
> "Tomas" == Tomas Henzlwrites: Tomas> A barrier should be added to ensure proper ordering of memory Tomas> mapped writes. Tomas> V2: - added the barrier also to megasas_fire_cmd_skinny, as Tomas> suggested by Kashyap Desai Sumit, Kashyap: Please review this patch. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lpfc: Remove redundant code block in lpfc_scsi_cmd_iocb_cmpl
> "Johannes" == Johannes Thumshirnwrites: Johannes> This removes a redundant code block that will either be Johannes> executed if the ENABLE_FCP_RING_POLLING flag is set in Johannes> phba->cfg_poll or not. The code is just duplicated in both Johannes> cases, hence we unify it again. James and Dick: Ping! https://patchwork.kernel.org/patch/8072451/ -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Separate target visibility from reaped state information
On Wed, Feb 10, 2016 at 07:34:51AM -0800, James Bottomley wrote: > On Wed, 2016-02-10 at 15:05 +0100, Johannes Thumshirn wrote: > > On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote: > > > James Bottomley wrote: > > > > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote: > > > > > On 01/19/16 17:03, James Bottomley wrote: > > > > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote: > > > > > > > > > > > > "Bart" == Bart Van Assche < > > > > > > > > > > > > bart.vanass...@sandisk.com> [..] > > > > > > Sebastian > > > > Hi James, Bart, Martin > > > > Have you already decided, which of the two patches you favour and > > when it'llbe included? > > > > I have several customer reports that hit this lockup and I don't want > > to include one of the patches from the list just to find out the > > other one's is used in mainline. > > Well, unless the target allocation bug gets fixed in Bart's, it will > have to be the last_scan one. It's more a hack than a fix, but I > suppose it will do as a bandaid in the meantime. > > If you have diagnosed this at customers, I'd still like to know what's > holding the devices on removal. > > Thanks, > > James I'll setup a test environment tomorrow and try to get some crash dumps with the current HEAD. -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [mpt3sas driver patches 00/10] mpt3sas driver enhancements and
> "Suganath" == Suganath prabu Subaramani >writes: Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/2] add support for DWC UFS Controller
The work consisted of: - Fixed typo in ufshcd-pltfrm.c - Tweak ufshcd.c for UFS 2.0 support - Implement ufshcd-dwc which contains all DWC HW specific code - Unipro attributes were added and new registers were added to the driver - Implement a ufs-dwc glue platform driver - Implement a ufs-dwc-pci glue pci driver Joao Pinto (2): fixed typo in ufshcd-pltfrm add support for DWC UFS Host Controller Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 17 + MAINTAINERS | 6 + drivers/scsi/ufs/Kconfig | 41 ++ drivers/scsi/ufs/Makefile | 3 + drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++ drivers/scsi/ufs/ufs-dwc.c| 102 +++ drivers/scsi/ufs/ufshcd-dwc.c | 736 ++ drivers/scsi/ufs/ufshcd-dwc.h | 18 + drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +- drivers/scsi/ufs/ufshcd.c | 50 +- drivers/scsi/ufs/ufshcd.h | 13 + drivers/scsi/ufs/ufshci-dwc.h | 42 ++ drivers/scsi/ufs/ufshci.h | 1 + drivers/scsi/ufs/unipro.h | 39 ++ 14 files changed, 1232 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c create mode 100644 drivers/scsi/ufs/ufs-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h create mode 100644 drivers/scsi/ufs/ufshci-dwc.h -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] bfa: deinline __bfa_trc() and __bfa_trc32()
> "Denys" == Denys Vlasenkowrites: Denys> __bfa_trc32() is very similar, so it is uninlined too. However, Denys> it appears to be unused, therefore this patch ifdefs it out. Why don't we just drop it? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/2] add support for DWC UFS Host Controller
This patch has the goal to add support for DesignWare UFS Controller specific operations and to add specific platform and pci drivers. Signed-off-by: Joao Pinto--- Changes v5->v6: - Patch bad format fixed Changes v4->v5 (Akinobu Mita): - All functions used only locally in ufshcd-dwc are now declared as static - ufshcd_dwc_configuration() was removed in ufshcd-dwc and a notify function (ufshcd_dwc_link_startup_notify) was created to deal with the DWC specific init routines - 20-bit RMMI option was removed from Kconfig. Now if MPHY TC is selected and 40-bit is not then it assumes a 20-bit config Changes v3->v4 (Arnd Bergmann and Mark Rutland): - SCSI_UFS_DWC_HOOKS is now silent and selected by the SCSI_UFS_DWC_PLAT or SCSI_UFS_DWC_PCI - Compatibility string has the ufs core version for info purposes since the driver is capable of getting the controller version from its registers - Created ufs-dwc-pci glue driver with specific DWC data - MPHY configuration remains in the ufshcd-dwc since it is unipro attribute writting only not following the a linux phy framework logic Changes v2->v3 (Julian Calaby): - Implement a common DWC code to be used by the platform and pci glue drivers - Synopsys ID & Class added to the existing pci driver and specific DWC was also added to the pci driver Changes v1->v2 (Akinobu Mita): - Implement a platform driver that uses the existing UFS core driver - Add DWC specific code to the existing UFS core driver Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 17 + MAINTAINERS | 6 + drivers/scsi/ufs/Kconfig | 41 ++ drivers/scsi/ufs/Makefile | 3 + drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++ drivers/scsi/ufs/ufs-dwc.c| 102 +++ drivers/scsi/ufs/ufshcd-dwc.c | 736 ++ drivers/scsi/ufs/ufshcd-dwc.h | 18 + drivers/scsi/ufs/ufshcd.c | 50 +- drivers/scsi/ufs/ufshcd.h | 13 + drivers/scsi/ufs/ufshci-dwc.h | 42 ++ drivers/scsi/ufs/ufshci.h | 1 + drivers/scsi/ufs/unipro.h | 39 ++ 13 files changed, 1231 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c create mode 100644 drivers/scsi/ufs/ufs-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h create mode 100644 drivers/scsi/ufs/ufshci-dwc.h diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt new file mode 100644 index 000..f38a3f5 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt @@ -0,0 +1,17 @@ +* Universal Flash Storage (UFS) DesignWare Host Controller + +DWC_UFSHC nodes are defined to describe on-chip UFS host controllers. +Each UFS controller instance should have its own node. + +Required properties: +- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1" + or "snps,ufshcd-2.0") +- reg : +- interrupts: + +Example: + dwc_ufshcd@0xD000 { + compatible = "snps,ufshcd-2.0"; + reg = < 0xD000 0x1 >; + interrupts = < 24 >; + }; diff --git a/MAINTAINERS b/MAINTAINERS index d2f94e2..3db3c4c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11006,6 +11006,12 @@ S: Supported F: Documentation/scsi/ufs.txt F: drivers/scsi/ufs/ +UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS +M: Joao Pinto +L: linux-scsi@vger.kernel.org +S: Supported +F: drivers/scsi/ufs/*dwc* + UNSORTED BLOCK IMAGES (UBI) M: Artem Bityutskiy M: Richard Weinberger diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index 5f45307..b4c353c 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -83,3 +83,44 @@ config SCSI_UFS_QCOM Select this if you have UFS controller on QCOM chipset. If unsure, say N. + +config SCSI_UFS_DWC_HOOKS + bool + +config SCSI_UFS_DWC_PLAT + tristate "DesignWare UFS controller platform glue driver" + depends on SCSI_UFSHCD_PLATFORM + select SCSI_UFS_DWC_HOOKS + help + This selects the DesignWare UFS host controller platform glue driver. + + Select this if you have a DesignWare UFS controller on Platform bus. + If unsure, say N. + +config SCSI_UFS_DWC_PCI + tristate "DesignWare UFS controller pci glue driver" + depends on SCSI_UFSHCD_PCI + select SCSI_UFS_DWC_HOOKS + help + This selects the DesignWare UFS host controller pci glue driver. + + Select this if you have a DesignWare UFS controller on
[PATCH v6 1/2] fixed typo in ufshcd-pltfrm
Fixed typo in ufshcd-pltfrm. Signed-off-by: Joao Pinto--- Changes v0->v6: - Nothing changed (just to keep up with patch set version). drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index d2a7b12..0522891 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init); MODULE_AUTHOR("Santosh Yaragnavi "); MODULE_AUTHOR("Vinayak Holikatti "); -MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver"); +MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver"); MODULE_LICENSE("GPL"); MODULE_VERSION(UFSHCD_DRIVER_VERSION); -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice
On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote: > On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote: > > > Recently Johannes sent a patch to enable scsi-mq per driver, see > > > http://marc.info/?l=linux-scsi=145347009631192=2 > > > > > > Probably that is a good solution (at least in the short term) to allow > > > users to switch to blk-mq for some host adapters (with fast storage > > > attached) but to stick to legacy stuff on other host adapters with > > > rotary devices. > > > > I don't think that Johannes' patch is a good solution. > > Why? Because it's not per device? Yes. Like Christoph said in his reply to the patch: »The host is simply the wrong place to decide these things.« > > The best solution for the user would be if blk-mq could be toggled > > per drive (or even automatically enabled if queue/rotational == 0). > > Yes, I aggree, but ... > > > Is there a fundamental reason why this is not feasible? > > ... it's not possible (*) with the current implementation. > > Tag handling/command allocation differs. Respective functions are set > per host. > > (*) Or maybe it's possible but just hard to achieve and I didn't look > long enough into relevant code to get an idea how to do it. > > > Your solution is better than nothing, but it requires that the user > > finds out the drive <=> host mapping by hand and then runs something > > like: > > echo "250" > > > /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us > > during boot for spinning rust drives... > > Or it could automatically be set in case of rotational device. > (Once we know for sure that it doesn't cause performance degradation.) Yes, this sound like a good idea. But, if I understand things correctly, your patch is only an interim solution until proper I/O scheduler support gets implemented for blk-mq, no? -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice
On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote: > On 2016.02.09 at 18:12 +0100, Andreas Herrmann wrote: > > [CC-ing linux-block and linux-scsi and adding some comments] > > > > On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote: > > > This introduces a new blk_mq hw attribute time_slice_us which allows > > > to specify a time slice in usecs. > > > > > > Fio test results are sent in a separate mail to this. > > > > See http://marc.info/?l=linux-kernel=145436682607949=2 > > > > In short it shows significant performance gains in some tests, > > e.g. sequential read iops up by >40% with 8 jobs. But it's never on > > par with CFQ when more than 1 job was used during the test. > > > > > Results for fio improved to some extent with this patch. But in > > > reality the picture is quite mixed. Performance is highly dependend on > > > task scheduling. There is no guarantee that the requests originated > > > from one CPU belong to the same process. > > > > > > I think for rotary devices CFQ is by far the best choice. A simple > > > illustration is: > > > > > > Copying two files (750MB in this case) in parallel on a rotary > > > device. The elapsed wall clock time (seconds) for this is > > >meanstdev > > >cfq, slice_idle=8 16.18 4.95 > > >cfq, slice_idle=0 23.74 2.82 > > >blk-mq, time_slice_usec=0 24.37 2.05 > > >blk-mq, time_slice_usec=250 25.58 3.16 > > > > This illustrates that although their was performance gain with fio > > tests, the patch can cause higher variance and lower performance in > > comparison to unmodified blk-mq with other tests. And it underscores > > superiority of CFQ for rotary disks. > > > > Meanwhile my opinion is that it's not really worth to look further > > into introduction of I/O scheduling support in blk-mq. I don't see the > > need for scheduling support (deadline or something else) for fast > > storage devices. And rotary devices should really avoid usage of blk-mq > > and stick to CFQ. > > > > Thus I think that introducing some coexistence of blk-mq and the > > legacy block with CFQ is the best option. > > > > Recently Johannes sent a patch to enable scsi-mq per driver, see > > http://marc.info/?l=linux-scsi=145347009631192=2 > > > > Probably that is a good solution (at least in the short term) to allow > > users to switch to blk-mq for some host adapters (with fast storage > > attached) but to stick to legacy stuff on other host adapters with > > rotary devices. > > I don't think that Johannes' patch is a good solution. Why? Because it's not per device? > The best solution for the user would be if blk-mq could be toggled > per drive (or even automatically enabled if queue/rotational == 0). Yes, I aggree, but ... > Is there a fundamental reason why this is not feasible? ... it's not possible (*) with the current implementation. Tag handling/command allocation differs. Respective functions are set per host. (*) Or maybe it's possible but just hard to achieve and I didn't look long enough into relevant code to get an idea how to do it. > Your solution is better than nothing, but it requires that the user > finds out the drive <=> host mapping by hand and then runs something > like: > echo "250" > > /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us > during boot for spinning rust drives... Or it could automatically be set in case of rotational device. (Once we know for sure that it doesn't cause performance degradation.) > -- > Markus Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] megaraid_sas: add an i/o barrier
> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, February 10, 2016 10:55 PM > To: Tomas Henzl > Cc: 'linux-scsi@vger.kernel.org'; sumit.sax...@avagotech.com; Desai, > Kashyap; Uday Lingala; sta...@vger.kernel.org > Subject: Re: [PATCH v2] megaraid_sas: add an i/o barrier > > > "Tomas" == Tomas Henzlwrites: > > Tomas> A barrier should be added to ensure proper ordering of memory > Tomas> mapped writes. > > Tomas> V2: - added the barrier also to megasas_fire_cmd_skinny, as > Tomas> suggested by Kashyap Desai Reviewed-by: Kashyap Desai Acked-by: Kashyap Desai > > Sumit, Kashyap: Please review this patch. > > -- > Martin K. PetersenOracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] add support for DWC UFS Host Controller
On Wednesday 10 February 2016 16:06:13 Joao Pinto wrote: > This patch has the goal to add support for DesignWare UFS Controller > specific operations and to add specific platform and pci drivers. > > Signed-off-by: Joao Pinto> Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 17 + > MAINTAINERS | 6 + > drivers/scsi/ufs/Kconfig | 41 ++ > drivers/scsi/ufs/Makefile | 3 + > drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++ > drivers/scsi/ufs/ufs-dwc.c| 102 +++ > drivers/scsi/ufs/ufshcd-dwc.c | 736 > ++ > drivers/scsi/ufs/ufshcd-dwc.h | 18 + > drivers/scsi/ufs/ufshcd.c | 50 +- > drivers/scsi/ufs/ufshcd.h | 13 + > drivers/scsi/ufs/ufshci-dwc.h | 42 ++ > drivers/scsi/ufs/ufshci.h | 1 + > drivers/scsi/ufs/unipro.h | 39 ++ Can you split this into separate patches for changes to the common code, the addition of the PCI driver and the addition of the platform driver? > diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt > b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt > new file mode 100644 > index 000..f38a3f5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt > @@ -0,0 +1,17 @@ > +* Universal Flash Storage (UFS) DesignWare Host Controller > + > +DWC_UFSHC nodes are defined to describe on-chip UFS host controllers. > +Each UFS controller instance should have its own node. > + > +Required properties: > +- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1" > + or "snps,ufshcd-2.0") > +- reg : > +- interrupts: > + > +Example: > + dwc_ufshcd@0xD000 { Please fix the node name and address in the example. I think you want "ufs@d000". > +config SCSI_UFS_DWC_MPHY_TC > + bool "Support for the Synopsys MPHY Test Chip" > + depends on SCSI_UFS_DWC_HOOKS && (SCSI_UFSHCD_PCI || SCSI_UFS_DWC_PLAT) > + ---help--- > + This selects the support for the Synopsys MPHY Test Chip. > + > + Select this if you have a Synopsys MPHY Test Chip. > + If unsure, say N. > + > +config SCSI_UFS_DWC_40BIT_RMMI > + bool "40-bit RMMI MPHY" > + depends on SCSI_UFS_DWC_MPHY_TC > + ---help--- > + This specifies that the Synopsys MPHY supports 40-bit RMMI operations. > + > + Select this if you are using a 40-bit RMMI Synopsys MPHY. I don't think I understood you explanation why this has to be here, rather than using a proper PHY driver. Please try again. > + > +#ifdef CONFIG_PM > +/** > + * ufs_dw_pci_suspend - suspend power management function > + * @pdev: pointer to PCI device handle > + * @state: power state > + * > + * Returns 0 if successful > + * Returns non-zero otherwise > + */ > +static int ufs_dw_pci_suspend(struct device *dev) > +{ > + return ufshcd_system_suspend(dev_get_drvdata(dev)); > +} Please remove the #ifdef here. > + > +static const struct dev_pm_ops ufs_dw_pci_pm_ops = { > + .suspend= ufs_dw_pci_suspend, > + .resume = ufs_dw_pci_resume, > + .runtime_suspend = ufs_dw_pci_runtime_suspend, > + .runtime_resume = ufs_dw_pci_runtime_resume, > + .runtime_idle= ufs_dw_pci_runtime_idle, > +}; Instead, use the macros from include/linux/pm.h > +#ifdef CONFIG_SCSI_UFS_DWC_40BIT_RMMI > +/** > + * ufshcd_dwc_setup_40bit_rmmi() > + * This function configures Synopsys MPHY specific atributes (40-bit RMMI) > + * @hba: Pointer to drivers structure > + * > + * Returns 0 on success or non-zero value on failure > + */ > +static int ufshcd_dwc_setup_40bit_rmmi(struct ufs_hba *hba) > +{ > + int ret = 0; This looks like it should go into the external driver > + > +#ifdef CONFIG_SCSI_UFS_DWC_40BIT_RMMI > + dev_info(hba->dev, "Configuring MPHY 40-bit RMMI"); > + ret = ufshcd_dwc_setup_40bit_rmmi(hba); > + if (ret) { > + dev_err(hba->dev, "40-bit RMMI configuration failed"); > + goto out; > + } > +#else > + dev_info(hba->dev, "Configuring MPHY 20-bit RMMI"); > + ret = ufshcd_dwc_setup_20bit_rmmi(hba); > + if (ret) { > + dev_err(hba->dev, "20-bit RMMI configuration failed"); > + goto out; > + } > +#endif In particular, the part above cannot possibly work: When a distro ships a kernel with CONFIG_SCSI_UFS_DWC_40BIT_RMMI set, it won't ever call the ufshcd_dwc_setup_20bit_rmmi() function, regardless of what the hardware is. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice
On Wed, Feb 10, 2016 at 08:47:15PM +0100, Markus Trippelsdorf wrote: > On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote: > > On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote: > > > > Recently Johannes sent a patch to enable scsi-mq per driver, see > > > > http://marc.info/?l=linux-scsi=145347009631192=2 > > > > > > > > Probably that is a good solution (at least in the short term) to allow > > > > users to switch to blk-mq for some host adapters (with fast storage > > > > attached) but to stick to legacy stuff on other host adapters with > > > > rotary devices. > > > > > > I don't think that Johannes' patch is a good solution. > > > > Why? Because it's not per device? > > Yes. Like Christoph said in his reply to the patch: »The host is simply > the wrong place to decide these things.« > > > > The best solution for the user would be if blk-mq could be toggled > > > per drive (or even automatically enabled if queue/rotational == 0). > > > > Yes, I aggree, but ... > > > > > Is there a fundamental reason why this is not feasible? > > > > ... it's not possible (*) with the current implementation. > > > > Tag handling/command allocation differs. Respective functions are set > > per host. > > > > (*) Or maybe it's possible but just hard to achieve and I didn't look > > long enough into relevant code to get an idea how to do it. > > > > > Your solution is better than nothing, but it requires that the user > > > finds out the drive <=> host mapping by hand and then runs something > > > like: > > > echo "250" > > > > /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us > > > during boot for spinning rust drives... > > > > Or it could automatically be set in case of rotational device. > > (Once we know for sure that it doesn't cause performance degradation.) > > Yes, this sound like a good idea. > > But, if I understand things correctly, your patch is only an interim > solution until proper I/O scheduler support gets implemented for blk-mq, no? That's to be discussed. (Hence the RFC) My (potentially wrong) claims are - I don't think that fast storage (e.g. SSDs) requires I/O scheduler support with blk-mq. blk-mq is very good at pushing a large number of requests from per CPU sw queues to hw queue(s). Why then introduce any overhead for I/O scheduler support? - Slow storage (e.g. spinning drives) is fine with the old code which provides scheduler support and I doubt that there is any benefit for those devices when switching to blk-mq. - The big hammer (scsi_mod.use_blk_mq) for the entire scsi stack to decide what to use is suboptimal. You can't have optimal performance when you have both slow and fast storage devices in your system. I doubt that it is possible to add I/O scheduling support to blk-mq which can be on par with what CFQ is able to achieve for slow devices at the moment. Requests are scattered among per-CPU software queues (and almost instantly passed to hardware queue(s)). Due to CPU scheduling, requests initiated from one process might come down via different software queues. What is an efficient way to sort/merge requests from all the software queues in such a way that the result is comparable to what CFQ does (assuming that CFQ provides optimal performance)? So far I didn't find a solution to this problem. (I just have this patch which adds not too much overhead and improves the situation a little bit.) Maybe the solution is to avoid per-CPU queues for slow storage and fall back to a set of queues comparable to what CFQ uses. One way to do this is by falling back to non-blk-mq code and direct use of CFQ. Code that allows to select blk-mq per host would help to some extent. But when you have both device types connected to the same host adapter it doesn't help either. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity
From: Quinn TranSigned-off-by: Quinn Tran Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Fixes: fb3269b ("qla2xxx: Add selective command queuing") Signed-off-by: Himanshu Madhani --- drivers/scsi/qla2xxx/qla_target.c |4 ++-- drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_target.c b/drivers/scsi/qla2xxx/qla_target.c index 49a421a..9852319 100644 --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -4013,7 +4013,8 @@ static int qlt_handle_cmd_for_atio(struct scsi_qla_host *vha, cmd->cmd_in_wq = 1; cmd->cmd_flags |= BIT_0; - cmd->se_cmd.cpuid = -1; + cmd->se_cmd.cpuid = ha->msix_count ? + ha->tgt.rspq_vector_cpuid : WORK_CPU_UNBOUND; spin_lock(>cmd_list_lock); list_add_tail(>cmd_list, >qla_cmd_list); @@ -4021,7 +4022,6 @@ static int qlt_handle_cmd_for_atio(struct scsi_qla_host *vha, INIT_WORK(>work, qlt_do_work); if (ha->msix_count) { - cmd->se_cmd.cpuid = ha->tgt.rspq_vector_cpuid; if (cmd->atio.u.isp24.fcp_cmnd.rddata) queue_work_on(smp_processor_id(), qla_tgt_wq, >work); diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c b/drivers/scsi/qla2xxx/tcm_qla2xxx.c index 7c8e255..c1461d2 100644 --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c +++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c @@ -462,6 +462,9 @@ static int tcm_qla2xxx_handle_cmd(scsi_qla_host_t *vha, struct qla_tgt_cmd *cmd, if (bidi) flags |= TARGET_SCF_BIDI_OP; + if (se_cmd->cpuid != WORK_CPU_UNBOUND) + flags |= TARGET_SCF_USE_CPUID; + sess = cmd->sess; if (!sess) { pr_err("Unable to locate struct qla_tgt_sess from qla_tgt_cmd\n"); -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] qla2xxx: Fixes for target-pending
Hi Nic, Here are the patches that addresses review comments from Bart and Christoph. See email threads http://www.spinics.net/lists/target-devel/msg11418.html http://www.spinics.net/lists/target-devel/msg11419.html Please apply these patches to target-pending. Thanks, Himanshu Quinn Tran (2): target/transport: add flag to indicate CPU Affinity is observed qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity drivers/scsi/qla2xxx/qla_target.c |4 ++-- drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++ drivers/target/target_core_transport.c | 12 +--- include/target/target_core_base.h |2 ++ 4 files changed, 16 insertions(+), 5 deletions(-) -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] target/transport: add flag to indicate CPU Affinity is observed
From: Quinn TranSigned-off-by: Quinn Tran Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Fixes: fb3269b ("qla2xxx: Add selective command queuing") Signed-off-by: Himanshu Madhani --- drivers/target/target_core_transport.c | 12 +--- include/target/target_core_base.h |2 ++ 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 3e6a98b..6348ae0 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -776,10 +776,10 @@ void target_complete_cmd(struct se_cmd *cmd, u8 scsi_status) cmd->transport_state |= (CMD_T_COMPLETE | CMD_T_ACTIVE); spin_unlock_irqrestore(>t_state_lock, flags); - if (cmd->cpuid == -1) - queue_work(target_completion_wq, >work); - else + if (cmd->se_cmd_flags & SCF_USE_CPUID) queue_work_on(cmd->cpuid, target_completion_wq, >work); + else + queue_work(target_completion_wq, >work); } EXPORT_SYMBOL(target_complete_cmd); @@ -1491,6 +1491,12 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd, struct se_session *se_sess */ transport_init_se_cmd(se_cmd, se_tpg->se_tpg_tfo, se_sess, data_length, data_dir, task_attr, sense); + + if (flags & TARGET_SCF_USE_CPUID) + se_cmd->se_cmd_flags |= SCF_USE_CPUID; + else + se_cmd->cpuid = WORK_CPU_UNBOUND; + if (flags & TARGET_SCF_UNKNOWN_SIZE) se_cmd->unknown_data_length = 1; /* diff --git a/include/target/target_core_base.h b/include/target/target_core_base.h index d71a3ea..e8c8c08 100644 --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -141,6 +141,7 @@ enum se_cmd_flags_table { SCF_COMPARE_AND_WRITE_POST = 0x0010, SCF_PASSTHROUGH_PROT_SG_TO_MEM_NOALLOC = 0x0020, SCF_ACK_KREF= 0x0040, + SCF_USE_CPUID = 0x0080, }; /* struct se_dev_entry->lun_flags and struct se_lun->lun_access */ @@ -188,6 +189,7 @@ enum target_sc_flags_table { TARGET_SCF_BIDI_OP = 0x01, TARGET_SCF_ACK_KREF = 0x02, TARGET_SCF_UNKNOWN_SIZE = 0x04, + TARGET_SCF_USE_CPUID= 0x08, }; /* fabric independent task management function values */ -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] qla2xxx: Fixes for target-pending
On Wed, 2016-02-10 at 18:59 -0500, Himanshu Madhani wrote: > Hi Nic, > > Here are the patches that addresses review comments from Bart > and Christoph. See email threads > > http://www.spinics.net/lists/target-devel/msg11418.html > http://www.spinics.net/lists/target-devel/msg11419.html > > Please apply these patches to target-pending. > > Thanks, > Himanshu > > Quinn Tran (2): > target/transport: add flag to indicate CPU Affinity is observed > qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity > > drivers/scsi/qla2xxx/qla_target.c |4 ++-- > drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++ > drivers/target/target_core_transport.c | 12 +--- > include/target/target_core_base.h |2 ++ > 4 files changed, 16 insertions(+), 5 deletions(-) > Applied to target-pending/master. Thanks Himanshu & Quinn! -- 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
Business Partnership
Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data
[PATCH RESEND] scsi: sim710: fix build warning
We are getting build warning about: "Section mismatch in reference from the variable sim710_eisa_driver to the function .init.text:sim710_eisa_probe() The variable sim710_eisa_driver references the function __init sim710_eisa_probe()" sim710_eisa_probe() was having __init but that was being referenced from sim710_eisa_driver. Signed-off-by: Sudip Mukherjee--- patch first sent on 4th Sept.2015. There is no review or ACK yet. warning is still there with next-20160209, build log is at: https://travis-ci.org/sudipm-mukherjee/parport/jobs/107948115 drivers/scsi/sim710.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/sim710.c b/drivers/scsi/sim710.c index 3b3b56f..82ed998 100644 --- a/drivers/scsi/sim710.c +++ b/drivers/scsi/sim710.c @@ -176,8 +176,7 @@ static struct eisa_device_id sim710_eisa_ids[] = { }; MODULE_DEVICE_TABLE(eisa, sim710_eisa_ids); -static __init int -sim710_eisa_probe(struct device *dev) +static int sim710_eisa_probe(struct device *dev) { struct eisa_device *edev = to_eisa_device(dev); unsigned long io_addr = edev->base_addr; -- 1.9.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] target: Fix incorrect unmap_zeroes_data_store return
From: Nicholas BellingerThis patch fixes an incorrect return of zero from the new unmap_zeroes_data_store() configfs store attribute handler introduced in v4.5-rc1, to use the correct 'count' bytes return value. Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_configfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c index 3327c49..713c63d9 100644 --- a/drivers/target/target_core_configfs.c +++ b/drivers/target/target_core_configfs.c @@ -898,7 +898,7 @@ static ssize_t unmap_zeroes_data_store(struct config_item *item, da->unmap_zeroes_data = flag; pr_debug("dev[%p]: SE Device Thin Provisioning LBPRZ bit: %d\n", da->da_dev, flag); - return 0; + return count; } /* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v4 0/5] Fix LUN_RESET active I/O + TMR handling
Hi Himanshu & Co, On Tue, 2016-02-09 at 18:03 +, Himanshu Madhani wrote: > Hi Nic, > > > On 2/8/16, 9:25 PM, "Nicholas A. Bellinger"wrote: > > >Hi Himanshu, > > > >On Mon, 2016-02-08 at 23:27 +, Himanshu Madhani wrote: > >> > >> I am testing this series with with 4.5.0-rc2+ kernel and I am seeing > >>issue > >> where trying to trigger > >> sg_reset with option of host/device/bus in loop at 120second interval > >> causes call stack. At this point > >> removing configuration hangs indefinitely. See attached dmesg output > >>from > >> my setup. > >> > > > >Thanks alot for testing this. > > > >So It looks like we're still hitting a indefinite schedule() on > >se_cmd->cmd_wait_comp once tcm_qla2xxx session disconnect/reconnect > >occurs, after repeated explicit active I/O remote-port sg_resets. > > > >Does this trigger on the first tcm_qla2xxx session reconnect after > >explicit remote-port sg_reset..? Are session reconnects actively being > >triggered during the test..? > > > >To verify the latter for iscsi-target, I've been using a small patch to > >trigger session reset from TMR kthread context in order to simulate the > >I_T disconnects. Something like that would be useful for verifying with > >tcm_qla2xxx too. > > > >That said, I'll be reproducing with tcm_qla2xxx ports this week, and > >will enable various debug in a WIP branch for testing. Following up here.. So far using my test setup with ISP2532 ports in P2P + RAMDISK_MCP and v4.5-rc1, repeated remote-port active I/O LUN_RESET (sg_reset -d) has been functioning as expected with a blocksize_range=4k-256k + iodepth=32 fio write-verify style workload. No ->cmd_kref -1 OOPsen or qla2xxx initiator generated ABORT_TASKs from outstanding target TAS responses, nor fio write-verify failures to report after 800x remote-port active I/O LUN_RESETS. Next step will be to verify explicit tcm_qla2xxx port + module shutdown after 1K test iterations, and then IBLOCK async completions <-> NVMe backends with the same case. > Let me know if I can help in any way for testing/validating this series. > Thanks. :) So based on your original log, it's still unclear clear if the session reset resulting in se_cmd->cmd_wait_comp indefinite sleep + ->cmd_kref leak is happen concurrently with repeated remote port LUN_RESET, or the session reset -> target_wait_for_sess_cmds() occurs after active I/O has already completed..? Please confirm. To that end, target-pending/debug-for-himanshu has been pushed to enable extra debug for test, please update. Also, you'll want to enable microsecond ring buffer timestamps in your kernel build too, as it's very useful for type this debugging. Thank you, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] scsi: ppa: use new parport device model
Modify ppa driver to use the new parallel port device model. Signed-off-by: Sudip Mukherjee--- Resending as there was no review or ACK for this change. This has exactly same changes as done in scsi/imm.c which has already been accepted. drivers/scsi/ppa.c | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/ppa.c b/drivers/scsi/ppa.c index ee00e27..f6ad579 100644 --- a/drivers/scsi/ppa.c +++ b/drivers/scsi/ppa.c @@ -37,6 +37,7 @@ typedef struct { unsigned long recon_tmo;/* How many usecs to wait for reconnection (6th bit) */ unsigned int failed:1; /* Failure flag */ unsigned wanted:1; /* Parport sharing busy flag*/ + unsigned int dev_no;/* Device number*/ wait_queue_head_t *waiting; struct Scsi_Host *host; struct list_head list; @@ -985,15 +986,40 @@ static struct scsi_host_template ppa_template = { static LIST_HEAD(ppa_hosts); +/* + * Finds the first available device number that can be alloted to the + * new ppa device and returns the address of the previous node so that + * we can add to the tail and have a list in the ascending order. + */ + +static inline ppa_struct *find_parent(void) +{ + ppa_struct *dev, *par = NULL; + unsigned int cnt = 0; + + if (list_empty(_hosts)) + return NULL; + + list_for_each_entry(dev, _hosts, list) { + if (dev->dev_no != cnt) + return par; + cnt++; + par = dev; + } + + return par; +} + static int __ppa_attach(struct parport *pb) { struct Scsi_Host *host; DECLARE_WAIT_QUEUE_HEAD_ONSTACK(waiting); DEFINE_WAIT(wait); - ppa_struct *dev; + ppa_struct *dev, *temp; int ports; int modes, ppb, ppb_hi; int err = -ENOMEM; + struct pardev_cb ppa_cb; dev = kzalloc(sizeof(ppa_struct), GFP_KERNEL); if (!dev) @@ -1002,8 +1028,15 @@ static int __ppa_attach(struct parport *pb) dev->mode = PPA_AUTODETECT; dev->recon_tmo = PPA_RECON_TMO; init_waitqueue_head(); - dev->dev = parport_register_device(pb, "ppa", NULL, ppa_wakeup, - NULL, 0, dev); + temp = find_parent(); + if (temp) + dev->dev_no = temp->dev_no + 1; + + memset(_cb, 0, sizeof(ppa_cb)); + ppa_cb.private = dev; + ppa_cb.wakeup = ppa_wakeup; + + dev->dev = parport_register_dev_model(pb, "ppa", _cb, dev->dev_no); if (!dev->dev) goto out; @@ -1110,9 +1143,10 @@ static void ppa_detach(struct parport *pb) } static struct parport_driver ppa_driver = { - .name = "ppa", - .attach = ppa_attach, - .detach = ppa_detach, + .name = "ppa", + .match_port = ppa_attach, + .detach = ppa_detach, + .devmodel = true, }; static int __init ppa_driver_init(void) -- 1.9.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
Business Partnership
Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data
Re: [PATCH] lpfc: Remove redundant code block in lpfc_scsi_cmd_iocb_cmpl
> "Johannes" == Johannes Thumshirnwrites: Johannes> This removes a redundant code block that will either be Johannes> executed if the ENABLE_FCP_RING_POLLING flag is set in Johannes> phba->cfg_poll or not. The code is just duplicated in both Johannes> cases, hence we unify it again. Johannes> This probably is a left over from some sort of refactoring. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] megaraid_sas: add an i/o barrier
> "Tomas" == Tomas Henzlwrites: Tomas> A barrier should be added to ensure proper ordering of memory Tomas> mapped writes. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] SCSI bug fixes for 4.6
> "Arnd" == Arnd Bergmannwrites: Arnd> Here are a bunch of fixes for harmless bugs I found during ARM Arnd> randconfig testing. It would be nice to get them mered in 4.6, but Arnd> there is no need to have them in 4.5 as no incorrect behavior Arnd> results from the current code, and the warnings are all hard to Arnd> trigger. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] ibmvscsi code cleanup
Fixed up a couple spots that were out of line with the PAPR in regards to its defined VSCSI protocol. Did away with some magic numbers directly in the code. Fixed a minor endian issue. -- v2 changes: -Renamed CRQ header enums and added enums for INIT formats -Check that crq->valid != VIOSRP_CRQ_FREE before handling in place of hacky bitwise & to check for first bit being set. -Added define for AIX os_type -Left sysfs config attribute to prevent breaking userspace Tyrel Datwyler (7): ibmvscsi: Correct values for several viosrp_crq_format enums ibmvscsi: Add and use enums for valid CRQ header values ibmvscsi: Replace magic values in set_adpater_info() with defines ibmvscsi: Use of_root to access OF device tree root node ibmvscsi: Remove unsupported host config MAD ibmvscsi: Add endian conversions to sysfs attribute show functions ibmvscsi: use H_CLOSED instead of magic number drivers/scsi/ibmvscsi/ibmvscsi.c | 128 ++- drivers/scsi/ibmvscsi/viosrp.h | 26 +--- 2 files changed, 49 insertions(+), 105 deletions(-) -- 2.5.0 -- 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] ibmvscsi: Use of_root to access OF device tree root node
The root node of the OF device tree is exported as of_root. No need to look up the root by path name. Instead just get a reference directly via of_root. Signed-off-by: Tyrel DatwylerReviewed-by: Johannes Thumshirn --- drivers/scsi/ibmvscsi/ibmvscsi.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index 4b09a9b..c208295 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -248,25 +248,23 @@ static void ibmvscsi_task(void *data) static void gather_partition_info(void) { - struct device_node *rootdn; - const char *ppartition_name; const __be32 *p_number_ptr; /* Retrieve information about this partition */ - rootdn = of_find_node_by_path("/"); - if (!rootdn) { + if (!of_root) return; - } - ppartition_name = of_get_property(rootdn, "ibm,partition-name", NULL); + of_node_get(of_root); + + ppartition_name = of_get_property(of_root, "ibm,partition-name", NULL); if (ppartition_name) strncpy(partition_name, ppartition_name, sizeof(partition_name)); - p_number_ptr = of_get_property(rootdn, "ibm,partition-no", NULL); + p_number_ptr = of_get_property(of_root, "ibm,partition-no", NULL); if (p_number_ptr) partition_number = of_read_number(p_number_ptr, 1); - of_node_put(rootdn); + of_node_put(of_root); } static void set_adapter_info(struct ibmvscsi_host_data *hostdata) -- 2.5.0 -- 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] ibmvscsi: Add endian conversions to sysfs attribute show functions
The values returned by the show functions for the host os_type, mad_version, and partition_number attributes get their values directly from the madapter_info struct whose associated fields are __be32 typed. Added endian conversion to ensure these values are sane on LE platforms. Signed-off-by: Tyrel DatwylerReviewed-by: Johannes Thumshirn --- drivers/scsi/ibmvscsi/ibmvscsi.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index e8d4af5..6025481 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1983,7 +1983,7 @@ static ssize_t show_host_partition_number(struct device *dev, int len; len = snprintf(buf, PAGE_SIZE, "%d\n", - hostdata->madapter_info.partition_number); + be32_to_cpu(hostdata->madapter_info.partition_number)); return len; } @@ -2003,7 +2003,7 @@ static ssize_t show_host_mad_version(struct device *dev, int len; len = snprintf(buf, PAGE_SIZE, "%d\n", - hostdata->madapter_info.mad_version); + be32_to_cpu(hostdata->madapter_info.mad_version)); return len; } @@ -2022,7 +2022,8 @@ static ssize_t show_host_os_type(struct device *dev, struct ibmvscsi_host_data *hostdata = shost_priv(shost); int len; - len = snprintf(buf, PAGE_SIZE, "%d\n", hostdata->madapter_info.os_type); + len = snprintf(buf, PAGE_SIZE, "%d\n", + be32_to_cpu(hostdata->madapter_info.os_type)); return len; } -- 2.5.0 -- 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] ibmvscsi: use H_CLOSED instead of magic number
In a couple places the magic value of 2 is used to check the return code of hypercalls. This translates to H_CLOSED. Signed-off-by: Tyrel Datwyler--- drivers/scsi/ibmvscsi/ibmvscsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index 6025481..d9534ee 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -314,7 +314,7 @@ static int ibmvscsi_reset_crq_queue(struct crq_queue *queue, rc = plpar_hcall_norets(H_REG_CRQ, vdev->unit_address, queue->msg_token, PAGE_SIZE); - if (rc == 2) { + if (rc == H_CLOSED) { /* Adapter is good, but other end is not ready */ dev_warn(hostdata->dev, "Partner adapter not ready\n"); } else if (rc != 0) { @@ -364,7 +364,7 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue, rc = ibmvscsi_reset_crq_queue(queue, hostdata); - if (rc == 2) { + if (rc == H_CLOSED) { /* Adapter is good, but other end is not ready */ dev_warn(hostdata->dev, "Partner adapter not ready\n"); retrc = 0; -- 2.5.0 -- 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 v7 00/14] Big fixes, retries, handle a race condition
> "Yaniv" == Yaniv Gardiwrites: Yaniv> V7: updated patch 0001 according to a comment also, removed patch Yaniv> 07/15 from V6, so now there are only 14 patches Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend PATCH 1/3] scsi:stex.c Support to Pegasus series.
> "Charles" == Charles Chiouwrites: Charles, Charles> Pegasus is a high performace hardware RAID solution designed to Charles> unleash the raw power of Thunderbolt technology. Please address Oliver's concerns about power management. Also, I was going to merge the first two patches in the series but your mailer mangled them and they did not apply. Please use git send-email to submit patches. Thank you! -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] ibmvscsi: Replace magic values in set_adpater_info() with defines
Add defines for mad version and mad os_type, and replace the magic numbers in set_adapter_info() accordingly. Signed-off-by: Tyrel Datwyler--- drivers/scsi/ibmvscsi/ibmvscsi.c | 8 drivers/scsi/ibmvscsi/viosrp.h | 3 +++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index c888ea1..4b09a9b 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -283,8 +283,8 @@ static void set_adapter_info(struct ibmvscsi_host_data *hostdata) hostdata->madapter_info.partition_number = cpu_to_be32(partition_number); - hostdata->madapter_info.mad_version = cpu_to_be32(1); - hostdata->madapter_info.os_type = cpu_to_be32(2); + hostdata->madapter_info.mad_version = cpu_to_be32(SRP_MAD_VERSION_1); + hostdata->madapter_info.os_type = cpu_to_be32(SRP_MAD_OS_LINUX); } /** @@ -1398,7 +1398,7 @@ static void adapter_info_rsp(struct srp_event_struct *evt_struct) hostdata->host->max_sectors = be32_to_cpu(hostdata->madapter_info.port_max_txu[0]) >> 9; - if (be32_to_cpu(hostdata->madapter_info.os_type) == 3 && + if (be32_to_cpu(hostdata->madapter_info.os_type) == SRP_MAD_OS_AIX && strcmp(hostdata->madapter_info.srp_version, "1.6a") <= 0) { dev_err(hostdata->dev, "host (Ver. %s) doesn't support large transfers\n", hostdata->madapter_info.srp_version); @@ -1407,7 +1407,7 @@ static void adapter_info_rsp(struct srp_event_struct *evt_struct) hostdata->host->sg_tablesize = MAX_INDIRECT_BUFS; } - if (be32_to_cpu(hostdata->madapter_info.os_type) == 3) { + if (be32_to_cpu(hostdata->madapter_info.os_type) == SRP_MAD_OS_AIX) { enable_fast_fail(hostdata); return; } diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h index 3d20851..d0f689b 100644 --- a/drivers/scsi/ibmvscsi/viosrp.h +++ b/drivers/scsi/ibmvscsi/viosrp.h @@ -221,7 +221,10 @@ struct mad_adapter_info_data { char srp_version[8]; char partition_name[96]; __be32 partition_number; +#define SRP_MAD_VERSION_1 1 __be32 mad_version; +#define SRP_MAD_OS_LINUX 2 +#define SRP_MAD_OS_AIX 3 __be32 os_type; __be32 port_max_txu[8]; /* per-port maximum transfer */ }; -- 2.5.0 -- 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] ibmvscsi: Remove unsupported host config MAD
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in the code for some time. From what information I've gathered from Brian King this was likely implemented on the host side in a SLES 9 based VIOS, which is no longer supported anywhere. Further, it is not defined in PAPR or supported by any AIX based VIOS. Treating as bit rot and removing the associated host config code. The config attribute and its show function are left as not to break userspace. The behavior remains the same returning nothing. Signed-off-by: Tyrel Datwyler--- drivers/scsi/ibmvscsi/ibmvscsi.c | 71 +++- drivers/scsi/ibmvscsi/viosrp.h | 7 2 files changed, 4 insertions(+), 74 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index c208295..e8d4af5 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1853,62 +1853,6 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, } /** - * ibmvscsi_get_host_config: Send the command to the server to get host - * configuration data. The data is opaque to us. - */ -static int ibmvscsi_do_host_config(struct ibmvscsi_host_data *hostdata, - unsigned char *buffer, int length) -{ - struct viosrp_host_config *host_config; - struct srp_event_struct *evt_struct; - unsigned long flags; - dma_addr_t addr; - int rc; - - evt_struct = get_event_struct(>pool); - if (!evt_struct) { - dev_err(hostdata->dev, "couldn't allocate event for HOST_CONFIG!\n"); - return -1; - } - - init_event_struct(evt_struct, - sync_completion, - VIOSRP_MAD_FORMAT, - info_timeout); - - host_config = _struct->iu.mad.host_config; - - /* The transport length field is only 16-bit */ - length = min(0x, length); - - /* Set up a lun reset SRP command */ - memset(host_config, 0x00, sizeof(*host_config)); - host_config->common.type = cpu_to_be32(VIOSRP_HOST_CONFIG_TYPE); - host_config->common.length = cpu_to_be16(length); - addr = dma_map_single(hostdata->dev, buffer, length, DMA_BIDIRECTIONAL); - - if (dma_mapping_error(hostdata->dev, addr)) { - if (!firmware_has_feature(FW_FEATURE_CMO)) - dev_err(hostdata->dev, - "dma_mapping error getting host config\n"); - free_event_struct(>pool, evt_struct); - return -1; - } - - host_config->buffer = cpu_to_be64(addr); - - init_completion(_struct->comp); - spin_lock_irqsave(hostdata->host->host_lock, flags); - rc = ibmvscsi_send_srp_event(evt_struct, hostdata, info_timeout * 2); - spin_unlock_irqrestore(hostdata->host->host_lock, flags); - if (rc == 0) - wait_for_completion(_struct->comp); - dma_unmap_single(hostdata->dev, addr, length, DMA_BIDIRECTIONAL); - - return rc; -} - -/** * ibmvscsi_slave_configure: Set the "allow_restart" flag for each disk. * @sdev: struct scsi_device device to configure * @@ -2093,21 +2037,14 @@ static struct device_attribute ibmvscsi_host_os_type = { static ssize_t show_host_config(struct device *dev, struct device_attribute *attr, char *buf) { - struct Scsi_Host *shost = class_to_shost(dev); - struct ibmvscsi_host_data *hostdata = shost_priv(shost); - - /* returns null-terminated host config data */ - if (ibmvscsi_do_host_config(hostdata, buf, PAGE_SIZE) == 0) - return strlen(buf); - else - return 0; + return 0; } static struct device_attribute ibmvscsi_host_config = { .attr = { -.name = "config", -.mode = S_IRUGO, -}, + .name = "config", + .mode = S_IRUGO, + }, .show = show_host_config, }; diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h index d0f689b..c1ab8a4 100644 --- a/drivers/scsi/ibmvscsi/viosrp.h +++ b/drivers/scsi/ibmvscsi/viosrp.h @@ -99,7 +99,6 @@ enum viosrp_mad_types { VIOSRP_EMPTY_IU_TYPE = 0x01, VIOSRP_ERROR_LOG_TYPE = 0x02, VIOSRP_ADAPTER_INFO_TYPE = 0x03, - VIOSRP_HOST_CONFIG_TYPE = 0x04, VIOSRP_CAPABILITIES_TYPE = 0x05, VIOSRP_ENABLE_FAST_FAIL = 0x08, }; @@ -165,11 +164,6 @@ struct viosrp_adapter_info { __be64 buffer; }; -struct viosrp_host_config { - struct mad_common common; - __be64 buffer; -}; - struct viosrp_fast_fail { struct mad_common common; }; @@ -207,7 +201,6 @@ union mad_iu { struct viosrp_empty_iu empty_iu; struct viosrp_error_log error_log; struct viosrp_adapter_info adapter_info; - struct viosrp_host_config
[PATCH v2 2/7] ibmvscsi: Add and use enums for valid CRQ header values
The PAPR defines four valid header values for the first byte of a CRQ message. Namely, an unused/empty message (0x00), a valid command/response entry (0x80), a valid initialization entry (0xC0), and a valid transport event (0xFF). Further, initialization responses have two formats namely initialize (0x01) and initialize complete (0x02). Define these values as enums and use them in the code in place of their magic number equivalents. Signed-off-by: Tyrel Datwyler--- drivers/scsi/ibmvscsi/ibmvscsi.c | 18 +- drivers/scsi/ibmvscsi/viosrp.h | 12 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index adfef9d..c888ea1 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -182,7 +182,7 @@ static struct viosrp_crq *crq_queue_next_crq(struct crq_queue *queue) spin_lock_irqsave(>lock, flags); crq = >msgs[queue->cur]; - if (crq->valid & 0x80) { + if (crq->valid != VIOSRP_CRQ_FREE) { if (++queue->cur == queue->size) queue->cur = 0; @@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data) /* Pull all the valid messages off the CRQ */ while ((crq = crq_queue_next_crq(>queue)) != NULL) { ibmvscsi_handle_crq(crq, hostdata); - crq->valid = 0x00; + crq->valid = VIOSRP_CRQ_FREE; } vio_enable_interrupts(vdev); @@ -239,7 +239,7 @@ static void ibmvscsi_task(void *data) if (crq != NULL) { vio_disable_interrupts(vdev); ibmvscsi_handle_crq(crq, hostdata); - crq->valid = 0x00; + crq->valid = VIOSRP_CRQ_FREE; } else { done = 1; } @@ -474,7 +474,7 @@ static int initialize_event_pool(struct event_pool *pool, struct srp_event_struct *evt = >events[i]; memset(>crq, 0x00, sizeof(evt->crq)); atomic_set(>free, 1); - evt->crq.valid = 0x80; + evt->crq.valid = VIOSRP_CRQ_CMD_RSP; evt->crq.IU_length = cpu_to_be16(sizeof(*evt->xfer_iu)); evt->crq.IU_data_ptr = cpu_to_be64(pool->iu_token + sizeof(*evt->xfer_iu) * i); @@ -1767,9 +1767,9 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, struct srp_event_struct *evt_struct = (__force struct srp_event_struct *)crq->IU_data_ptr; switch (crq->valid) { - case 0xC0: /* initialization */ + case VIOSRP_CRQ_INIT_RSP: /* initialization */ switch (crq->format) { - case 0x01: /* Initialization message */ + case VIOSRP_CRQ_INIT: /* Initialization message */ dev_info(hostdata->dev, "partner initialized\n"); /* Send back a response */ rc = ibmvscsi_send_crq(hostdata, 0xC002LL, 0); @@ -1781,7 +1781,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, } break; - case 0x02: /* Initialization response */ + case VIOSRP_CRQ_INIT_COMPLETE: /* Initialization response */ dev_info(hostdata->dev, "partner initialization complete\n"); /* Now login */ @@ -1791,7 +1791,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, dev_err(hostdata->dev, "unknown crq message type: %d\n", crq->format); } return; - case 0xFF: /* Hypervisor telling us the connection is closed */ + case VIOSRP_CRQ_XPORT_EVENT:/* Hypervisor telling us the connection is closed */ scsi_block_requests(hostdata->host); atomic_set(>request_limit, 0); if (crq->format == 0x06) { @@ -1807,7 +1807,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, ibmvscsi_reset_host(hostdata); } return; - case 0x80: /* real payload */ + case VIOSRP_CRQ_CMD_RSP:/* real payload */ break; default: dev_err(hostdata->dev, "got an invalid message type 0x%02x\n", diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h index d1044e9..3d20851 100644 --- a/drivers/scsi/ibmvscsi/viosrp.h +++ b/drivers/scsi/ibmvscsi/viosrp.h @@ -51,6 +51,18 @@ union srp_iu { u8 reserved[SRP_MAX_IU_LEN]; }; +enum viosrp_crq_headers { + VIOSRP_CRQ_FREE = 0x00, + VIOSRP_CRQ_CMD_RSP = 0x80, + VIOSRP_CRQ_INIT_RSP = 0xC0, + VIOSRP_CRQ_XPORT_EVENT = 0xFF
[PATCH v2 1/7] ibmvscsi: Correct values for several viosrp_crq_format enums
The enum values for VIOSRP_LINUX_FORMAT and VIOSRP_INLINE_FORMAT are off by one. They are currently defined as 0x06 and 0x07 respetively. These values are defined in PAPR correctly as 0x05 and 0x06. This inconsistency has gone unnoticed as neither enum is currently used. The possible future support of PING messages between the VIOS and client adapter relies on VIOSRP_INLINE_FORMAT crq messages. Corrected these enum values to match PAPR definitions. Signed-off-by: Tyrel DatwylerReviewed-by: Johannes Thumshirn --- drivers/scsi/ibmvscsi/viosrp.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h index 1162430..d1044e9 100644 --- a/drivers/scsi/ibmvscsi/viosrp.h +++ b/drivers/scsi/ibmvscsi/viosrp.h @@ -56,8 +56,8 @@ enum viosrp_crq_formats { VIOSRP_MAD_FORMAT = 0x02, VIOSRP_OS400_FORMAT = 0x03, VIOSRP_AIX_FORMAT = 0x04, - VIOSRP_LINUX_FORMAT = 0x06, - VIOSRP_INLINE_FORMAT = 0x07 + VIOSRP_LINUX_FORMAT = 0x05, + VIOSRP_INLINE_FORMAT = 0x06 }; enum viosrp_crq_status { -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] ALUA device handler update, part II
> "Bart" == Bart Van Asschewrites: Bart, Bart> I will try to free up some time to help with reviewing and testing Bart> this patch series. But before I can do that the v4.5-rc multipath Bart> code needs to be stabilized first. See also Bart> https://www.redhat.com/archives/dm-devel/2016-February/msg00066.html. Have you had time to take a look? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Business Partnership
Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data