- Aug 05, 2020
-
-
Dick Kennedy authored
There are a couple of code areas which validate sufficient reply buffer length, but the checks are using the request elements rather than the reply elements. Rework to validate using the reply structures. Link: https://lore.kernel.org/r/20200803210229.23063-7-jsmart2021@gmail.com Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Dick Kennedy authored
With port bounce/address swaps and timing between initiator GID queries vs remote port FC4 support registrations, the driver may be in a situation where it sends PRLIs for both FCP and NVME even though the target may not support one of the protocols. In this case, the remote port will reject the PRLI and usually indicate it does not support the request. However, the driver currently ignores the status of the failure and immediately retries the PRLI, which is pointless. In the case of this one remote port, the reception of the PRLI retry caused it to decide to send a LOGO. The LOGO restarted the process and the same results happened. It made the remote port undiscoverable to either protocol. Add logic to detect the non-support status and not attempt the retry of the PRLI. Link: https://lore.kernel.org/r/20200803210229.23063-6-jsmart2021@gmail.com Signed-off-by:
-
Dick Kennedy authored
While mds diagnostic tests are running, if the driver is requested to be unloaded, oops or hangs are observed. The driver doesn't terminate the processing of diag frames when the unload is started. As such: oops may be seen for __lpfc_sli_release_iocbq_s4 because ring memory is referenced that was already freed; or hangs see in lpfc_nvme_wait_for_io_drain as ios no longer complete. If unloading, don't process diag frames. Just clean them up. Link: https://lore.kernel.org/r/20200803210229.23063-5-jsmart2021@gmail.com Signed-off-by:
-
Dick Kennedy authored
In configs with a large number of initiators in the same zone (>250), RSCN timeouts are seen when creating or deleting vports: lpfc 0000:07:00.1: 5:(0):0231 RSCN timeout Data: x0 x3 During RSCN processing driver issues GID_FT command to nameserver. A counter for number of simultaneous GID_FT commands is maintained (an unsigned value). The counter is incremented when the GID_FT is issued. If the GID_FT command fails for some reason the driver retries the GID_FT from the completion call back. But the counter was decremented before the retry was issued. When the second GID_FT completes, the callback again tries to decrement the counter, possibly wrapping to a very large non-zero value, which causes the RSCN cleanup code to not execute. Thus the RSCN timeout failure. Do not decrement the counter on a retry. Also add defensive checks to ensure the counter is not decremented if already zero. Link: https://lore.kernel.org/r/20200803210229.23063-4-jsmart2021@gmail.com Signed-off-by:
-
Dick Kennedy authored
If module parameters override the default configuration settings for hardware queues or irqs, the driver was not notifying the change from defaults. Revise such that any changes will result in a kernel log message. Link: https://lore.kernel.org/r/20200803210229.23063-3-jsmart2021@gmail.com Signed-off-by:
-
Dick Kennedy authored
Current Link speed was shown as "unknown" in sysfs for FCoE ports. In this scenario, the port was working in 20G speed, which happens to not be a speed handled by the driver. Add support for all possible link speeds that could get reported from port_speed field in link state ACQE. Additionally, as supported_speeds can't be manipulated via the FCoE driver on a converged ethernet port (it must be managed by the nic function), don't fill out the supported_speeds field for the fc host object in sysfs. Revise debug logging to report Link speed mgmt valuess. Link: https://lore.kernel.org/r/20200803210229.23063-2-jsmart2021@gmail.com Signed-off-by:
-
Jing Xiangfeng authored
lpfc_init() misses a call misc_deregister() in an error path. Add a label 'unregister' to fix it. Link: https://lore.kernel.org/r/20200731065639.190646-1-jingxiangfeng@huawei.com Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by:
-
Ewan D. Milne authored
We cannot wait on a completion object in the lpfc_nvme_targetport structure in the _destroy_targetport() code path because the NVMe/fc transport will free that structure immediately after the .targetport_delete() callback. This results in a use-after-free, and a crash if slub_debug=FZPU is enabled. An earlier fix put put the completion on the stack, but commit 2a0fb340 ("scsi: lpfc: Correct localport timeout duration error") subsequently changed the code to reference the completion through a pointer in the object rather than the local stack variable. Fix this by using the stack variable directly. Link: https://lore.kernel.org/r/20200729231011.13240-1-emilne@redhat.com Fixes: 2a0fb340 ("scsi: lpfc: Correct localport timeout duration error") Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Xiang Chen authored
According to the kernel coding style, use one space around the binary "|" operator. Add spaces around it. Link: https://lore.kernel.org/r/1596454442-220565-1-git-send-email-chenxiang66@hisilicon.com Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
Damien Le Moal authored
Currently, for zoned disks, since blk_revalidate_disk_zones() requires the disk capacity to be set already to operate correctly, zones revalidation can only be done on the second revalidate scan once the gendisk capacity is set at the end of the first scan. As a result, if zone revalidation fails, there is no second chance to recover from the failure and the disk capacity is changed to 0, with the disk left unusable. This can be improved by shuffling around code, specifically, by moving the call to sd_zbc_revalidate_zones() from sd_zbc_read_zones() to the end of sd_revalidate_disk(), after set_capacity_revalidate_and_notify() is called to set the gendisk capacity. With this change, if sd_zbc_revalidate_zones() fails on the first scan, the second scan will call it again to recover, if possible. Using the new struct scsi_disk fields rev_nr_zones and rev_zone_blocks, sd_zbc_revalidate_zones() does actual work only if it detects a change with the disk zone configuration. This means that for a successful zones revalidation on the first scan, the second scan will not cause another heavy full check. While at it, remove the unecesary "extern" declaration of sd_zbc_read_zones(). Link: https://lore.kernel.org/r/20200731054928.668547-1-damien.lemoal@wdc.com Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Javed Hasan authored
In fc_disc_gpn_id_resp(), skb is supposed to get freed in all cases except for PTR_ERR. However, in some cases it didn't. This fix is to call fc_frame_free(fp) before function returns. Link: https://lore.kernel.org/r/20200729081824.30996-2-jhasan@marvell.com Reviewed-by:
Girish Basrur <gbasrur@marvell.com> Reviewed-by:
Santosh Vernekar <svernekar@marvell.com> Reviewed-by:
Saurav Kashyap <skashyap@marvell.com> Reviewed-by:
Shyam Sundar <ssundar@marvell.com> Signed-off-by:
Javed Hasan <jhasan@marvell.com> Signed-off-by:
-
Javed Hasan authored
In fcoe_sysfs_fcf_del(), we first deleted the fcf from the list and then freed it if ctlr_dev was not NULL. This was causing a memory leak. Free the fcf even if ctlr_dev is NULL. Link: https://lore.kernel.org/r/20200729081824.30996-3-jhasan@marvell.com Reviewed-by:
-
Max Gurtovoy authored
This function always returns 0. We can make it return void to simplify the code. Also, no caller ever checks the return value of this function. Link: https://lore.kernel.org/r/20200803150008.83920-1-maxg@mellanox.com Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
-
- Jul 31, 2020
-
-
Hannes Reinecke authored
The SCSI midlayer does not allow state transitions from SDEV_BLOCK to SDEV_BLOCK so calling scsi_target_block() from __rport_fast_io_fail() is wrong as the port is already blocked. Similarly, we don't need to call scsi_target_unblock() afterwards as the function has already done this. Link: https://lore.kernel.org/r/20200728134833.42547-1-hare@suse.de Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Stanley Chu authored
Micron UFS devices require DELAY_AFTER_LPM device quirk in MediaTek platforms. Link: https://lore.kernel.org/r/20200729051840.31318-3-stanley.chu@mediatek.com Acked-by:
Avri Altman <Avri.Altman@wdc.com> Reviewed-by:
Andy Teng <andy.teng@mediatek.com> Reviewed-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Stanley Chu authored
Some UFS devices require delay after VCC power rail is turned off. Introduce a device quirk "DELAY_AFTER_LPM" to add 5ms delay after VCC power-off during suspend flow. Link: https://lore.kernel.org/r/20200729051840.31318-2-stanley.chu@mediatek.com Reviewed-by:
Can Guo <cang@codeaurora.org> Acked-by:
-
Maxim Levitsky authored
Commit 5ff84372 ("scsi: virtio_scsi: unplug LUNs when events missed") missed a corner case in which all the LUNs are unplugged at the same time. In this case INQUIRY returns DID_BAD_TARGET. Detect this and unplug the LUN. Link: https://lore.kernel.org/r/20200729194806.4933-2-mlevitsk@redhat.com Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by:
-
- Jul 29, 2020
-
-
Douglas Gilbert authored
The current driver responds to TEST UNIT READY (TUR) with a GOOD status immediately after a scsi_debug device (LU) is created. This is unrealistic as even SSDs take some time after power-on before accepting media access commands. Add the tur_ms_to_ready parameter whose unit is milliseconds (default 0) and is the period before which a TUR (or any media access command) will set the CHECK CONDITION status with a sense key of NOT READY and an additional sense of "Logical unit is in process of becoming ready". The period starts when each scsi_debug device is created. This patch was prompted by T10 proposal 20-061r2 which was accepted on 2020716. It adds that a TUR in the situation described in the previous paragraph may set the INFO field (or descriptor) in the sense data to the estimated number in milliseconds before a subsequent TUR will yield a GOOD status. This patch follows that advice. Link: https://lore.kernel.org/r/20200724155531.668144-1-dgilbert@interlog.com Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Douglas Gilbert authored
The SCSI REQUEST SENSE command emulation was found to be broken. It is a quite complex command so try and make it do a subset of what it should do. Remove the attempt to mimic SCSI-1 REQUEST SENSE (i.e. return the sense data for the previous failed command). Add some reporting of "pollable" sense data [see spc6r02: 5.12.2]. Keep the IEC mode page MRIE=6 TEST=1 predictive failure reporting. Link: https://lore.kernel.org/r/20200723194819.545573-1-dgilbert@interlog.com Signed-off-by:
-
Ferruh Yigit authored
UPL -> ULP for "Upper Layer Protocol" Link: https://lore.kernel.org/r/20200728145606.1601726-1-ferruh.yigit@intel.com Signed-off-by:
Ferruh Yigit <ferruh.yigit@intel.com> Signed-off-by:
-
Stanley Chu authored
In some platforms, VCC regulator may not be declared in device tree to keep itself "always-on". In this case, hba->vreg_info.vcc is NULL and shall not be operated during any flow. Prevent possible NULL hba->vreg_info.vcc access in LPM mode by checking if it is valid first. Link: https://lore.kernel.org/r/20200724141627.20094-1-stanley.chu@mediatek.com Reviewed-by:
-
Jing Xiangfeng authored
If scsi_host_lookup() fails we will jump to put_host which may cause a panic. Jump to exit_set_fnode instead. Link: https://lore.kernel.org/r/20200615081226.183068-1-jingxiangfeng@huawei.com Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Don Brace authored
Need to set queue depth for controller devices. Link: https://lore.kernel.org/r/159562590819.17915.12766718094041027754.stgit@brunhilda Fixes: 30bda784 ("scsi: hpsa: Increase controller error handling timeout") Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Bodo Stroesser authored
Add "tmr_notification" configfs attribute to tcmu devices. If the default value 0 is used, tcmu only removes aborted commands from qfull_queue. If user changes tmr_notification to 1, additionally TMR notifications will be written to the cmd ring. Link: https://lore.kernel.org/r/20200726153510.13077-9-bstroesser@ts.fujitsu.com Reviewed-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
-
Bodo Stroesser authored
This patch implements the tmr_notify callback for tcmu. When the callback is called, tcmu checks the list of aborted commands it received as parameter: - aborted commands in the qfull_queue are removed from the queue and target_complete_command is called - from the cmd_ids of aborted commands currently uncompleted in cmd ring it creates a list of aborted cmd_ids. Finally a TMR notification is written to cmd ring containing TMR type and cmd_id list. If there is no space in ring, the TMR notification is queued on a TMR specific queue. The TMR specific queue 'tmr_queue' can be seen as a extension of the cmd ring. At the end of each iexecution of tcmu_complete_commands() we check whether tmr_queue contains TMRs and try to move them onto the ring. If tmr_queue is not empty after that, we don't call run_qfull_queue() because commands must not overtake TMRs. This way we guarantee that cmd_ids in TMR notification received by userspace either match an active, not yet completed command or are no longer valid due to userspace having complete some cmd_ids meanwhile. New commands that were assigned to an aborted cmd_id will always appear on the cmd ring _after_ the TMR. Link: https://lore.kernel.org/r/20200726153510.13077-8-bstroesser@ts.fujitsu.com Reviewed-by:
-
Bodo Stroesser authored
During cmd timeout handling in check_timedout_devices(), due to a race, it can happen that tcmu_set_next_deadline() does not start a timer as expected: 1) Either tcmu_check_expired_ring_cmd() checks the inflight_queue or tcmu_check_expired_queue_cmd() checks the qfull_queue while jiffies has the value X 2) At the end of the check the queue contains one remaining command with deadline X (time_after(X, X) is false and thus the command is not handled as being timed out). 3) After tcmu_check_expired_xxxxx_cmd() a timer interrupt happens and jiffies is incremented to X+1. 4) Now tcmu_set_next_deadline() is called, but it skips the command, since time_after(X+1, X) is true. Therefore tcmu_set_next_deadline() finds no new deadline and stops the timer, which it shouldn't. Since commands that time out are removed from inflight_queue or qfull_queue, we don't need the check with time_after() in tcmu_set_next_deadline() but can use the deadline from the first cmd in the queue. Additionally, replace the remaining time_after() calls in tcmu_check_expired_xxxxx_cmd() with time_after_eq(), because it is not useful to set the timeout to deadline but then check for jiffies being greater than deadline. Simplify the end of tcmu_handle_completions() and change the check for no more pending commands from mb->cmd_tail == mb->cmd_head to idr_is_empty(&udev->commands) because the old check doesn't work correctly if paddings or in the future TMRs are in the ring. Finally tcmu_set_next_deadline() was shifted in the source as preparation for later implementation of tmr_notify callback. Link: https://lore.kernel.org/r/20200726153510.13077-7-bstroesser@ts.fujitsu.com Reviewed-by: -
Bodo Stroesser authored
The new helper ring_insert_padding is split off from and then called by queue_cmd_ring. It inserts a padding if necessary. The new helper will in a subsequent patch be used during writing of TMR notifications to command ring. Link: https://lore.kernel.org/r/20200726153510.13077-6-bstroesser@ts.fujitsu.com Reviewed-by:
-
Bodo Stroesser authored
If tcmu receives an already aborted command, tcmu_queue_cmd() should reject it. Link: https://lore.kernel.org/r/20200726153510.13077-5-bstroesser@ts.fujitsu.com Reviewed-by:
-
Bodo Stroesser authored
We initialize and clean up the se_cmd's priv pointer under cmd_ring_lock to point to the corresponding tcmu_cmd. In the patch that implements tmr_notify callback in tcmu we will use the priv pointer. Link: https://lore.kernel.org/r/20200726153510.13077-4-bstroesser@ts.fujitsu.com Reviewed-by:
-
Bodo Stroesser authored
Target core is modified to call an optional backend callback function if a TMR is received or commands are aborted implicitly after a PR command was received. The backend function takes as parameters the se_dev, the type of the TMR, and the list of aborted commands. If no commands were aborted, an empty list is supplied. Link: https://lore.kernel.org/r/20200726153510.13077-3-bstroesser@ts.fujitsu.com Reviewed-by:
-
Bodo Stroesser authored
This patch modifies core_tmr_abort_task() to use same looping and locking scheme as core_tmr_drain_state_list() does. This frees the state_list element in se_cmd for later use by tmr notification handling. Note: __target_check_io_state() now is called with param 0 instead of dev->dev_attrib.emulate_tas, because tas is not relevant since we always get ABRT on same session like the aborted command. Link: https://lore.kernel.org/r/20200726153510.13077-2-bstroesser@ts.fujitsu.com Reviewed-by:
-
Hou Pu authored
Commit 25cdda95 ("iscsi-target: Fix initial login PDU asynchronous socket close OOPs") changed the return value of __iscsi_target_sk_check_close(). However, pr_debug is still printing FALSE when returning TRUE which is a little confusing. Link: https://lore.kernel.org/r/20200716100212.4237-3-houpu@bytedance.com Reviewed-by:
Hou Pu <houpu@bytedance.com> Signed-off-by:
-
Hou Pu authored
iscsi_target_sk_data_ready() could be invoked indirectly by iscsi_target_do_login_rx() from the workqueue like this: iscsi_target_do_login_rx() iscsi_target_do_login() iscsi_target_do_tx_login_io() iscsit_put_login_tx() iscsi_login_tx_data() tx_data() sock_sendmsg_nosec() tcp_sendmsg() release_sock() sk_backlog_rcv() tcp_v4_do_rcv() tcp_data_ready() iscsi_target_sk_data_ready() At that time LOGIN_FLAGS_READ_ACTIVE is not cleared and iscsi_target_sk_data_ready will not read data from the socket. Some iscsi initiators (libiscsi) will wait forever for a reply. LOGIN_FLAGS_READ_ACTIVE should be cleared early just after doing the receive and before writing to the socket in iscsi_target_do_login_rx. Unfortunately, LOGIN_FLAGS_READ_ACTIVE is also used by sk_state_change to do login cleanup if a socket was closed at login time. It is supposed to be cleared after the login PDU is successfully processed and replied. Introduce another flag, LOGIN_FLAGS_WRITE_ACTIVE, to cover the transmit part. Link: https://lore.kernel.org/r/20200716100212.4237-2-houpu@bytedance.com Reviewed-by:
-
- Jul 25, 2020
-
-
Lee Jones authored
Only declare 'core_nr' if its conditions for use are met. Fixes the following W=1 kernel build warning(s): drivers/scsi/mvsas/mv_init.c: In function ‘mvs_interrupt’: drivers/scsi/mvsas/mv_init.c:180:6: warning: variable ‘core_nr’ set but not used [-Wunused-but-set-variable] drivers/scsi/mvsas/mv_init.c: In function ‘mvs_ioremap’: drivers/scsi/mvsas/mv_init.c:302:36: warning: variable ‘res_flag’ set but not used [-Wunused-but-set-variable] [mkp: applied follow-up fixup patch] Link: https://lore.kernel.org/r/20200721164148.2617584-40-lee.jones@linaro.org Cc: Jason Yan <yanaijie@huawei.com> Cc: Marvell <kewei@marvell.com> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/esas2r/esas2r_log.c:86: warning: Function parameter or member 'level' not described in 'translate_esas2r_event_level_to_kernel' drivers/scsi/esas2r/esas2r_log.c:120: warning: Function parameter or member 'level' not described in 'esas2r_log_master' drivers/scsi/esas2r/esas2r_log.c:120: warning: Function parameter or member 'dev' not described in 'esas2r_log_master' drivers/scsi/esas2r/esas2r_log.c:120: warning: Function parameter or member 'format' not described in 'esas2r_log_master' drivers/scsi/esas2r/esas2r_log.c:120: warning: Function parameter or member 'args' not described in 'esas2r_log_master' drivers/scsi/esas2r/esas2r_log.c:183: warning: Function parameter or member 'level' not described in 'esas2r_log' drivers/scsi/esas2r/esas2r_log.c:183: warning: Function parameter or member 'format' not described in 'esas2r_log' drivers/scsi/esas2r/esas2r_log.c:211: warning: Function parameter or member 'level' not described in 'esas2r_log_dev' drivers/scsi/esas2r/esas2r_log.c:211: warning: Function parameter or member 'dev' not described in 'esas2r_log_dev' drivers/scsi/esas2r/esas2r_log.c:211: warning: Function parameter or member 'format' not described in 'esas2r_log_dev' drivers/scsi/esas2r/esas2r_log.c:237: warning: Function parameter or member 'level' not described in 'esas2r_log_hexdump' drivers/scsi/esas2r/esas2r_log.c:237: warning: Function parameter or member 'buf' not described in 'esas2r_log_hexdump' drivers/scsi/esas2r/esas2r_log.c:237: warning: Function parameter or member 'len' not described in 'esas2r_log_hexdump' Link: https://lore.kernel.org/r/20200723122446.1329773-41-lee.jones@linaro.org Cc: Bradley Grove <linuxdrivers@attotech.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/bnx2i/bnx2i_iscsi.c:1288: warning: Function parameter or member 'cmds_max' not described in 'bnx2i_session_create' drivers/scsi/bnx2i/bnx2i_iscsi.c:2176: warning: Function parameter or member 'params' not described in 'bnx2i_nl_set_path' drivers/scsi/bnx2i/bnx2i_iscsi.c:2176: warning: Excess function parameter 'buf' description in 'bnx2i_nl_set_path' Link: https://lore.kernel.org/r/20200723122446.1329773-40-lee.jones@linaro.org Cc: QLogic-Storage-Upstream@qlogic.com Cc: Anil Veerabhadrappa <anilgv@broadcom.com> Cc: Eddie Wai <eddie.wai@broadcom.com> Signed-off-by:
-
Lee Jones authored
Fixes the following checkpatch warning: CHECK: Please use a blank line after function/struct/union/enum declarations #129: FILE: drivers/scsi/bfa/bfa_ioc.c:6913: } +/* Link: https://lore.kernel.org/r/20200723122446.1329773-39-lee.jones@linaro.org Cc: Anil Gurumurthy <anil.gurumurthy@qlogic.com> Cc: Sudarsana Kalluru <sudarsana.kalluru@qlogic.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/qedi/qedi_iscsi.c:1549:7: warning: no previous prototype for ‘qedi_get_iscsi_error’ [-Wmissing-prototypes] Link: https://lore.kernel.org/r/20200723122446.1329773-38-lee.jones@linaro.org Cc: QLogic-Storage-Upstream@cavium.com Signed-off-by:
-
Lee Jones authored
This is the only use of kerneldoc in the source file and no descriptions are provided. Fixes the following W=1 kernel build warning(s): drivers/scsi/qedi/qedi_main.c:1969: warning: Function parameter or member 'qedi' not described in 'qedi_get_nvram_block' Link: https://lore.kernel.org/r/20200723122446.1329773-37-lee.jones@linaro.org Cc: QLogic-Storage-Upstream@cavium.com Signed-off-by:
-
Lee Jones authored
This is the only use of kerneldoc in the source file and no descriptions are provided. Also demote standard comment. Fixes the following W=1 kernel build warning(s): drivers/scsi/bfa/bfa_svc.c:3847: warning: Function parameter or member 'bfa' not described in 'bfa_fcport_get_cfg_topology' Link: https://lore.kernel.org/r/20200723122446.1329773-36-lee.jones@linaro.org Cc: Anil Gurumurthy <anil.gurumurthy@qlogic.com> Cc: Sudarsana Kalluru <sudarsana.kalluru@qlogic.com> Signed-off-by:
-
