Failing to register with devfreq leaves hba->devfreq assigned, which
causes the error path to dereference the ERR_PTR(). Rather than bolting
on more conditionals, move the call of devm_devfreq_add_device() into
it's own function and only update hba->devfreq once it's successfully
registered.
The s
With the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max
frequency") the UFS host controller driver (UFSHCD) stopped probing for
platforms that supports frequency scaling, e.g. all modern Qualcomm platforms.
The cause of this was UFSHCD's reliance of not registering any freq
devfreq requires that the client operates on actual frequencies, not
only 0 and UMAX_INT and as such UFS brok with the introduction of
f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency").
This patch registers the frequencies of the first clock with devfreq and
use these to determine
On Thu, 17 May 2018 14:07:40 -0700
Michael Kelley wrote:
> Current code allocates 240 Kbytes (in typical configs) for
> each synthetic SCSI controller to use as temp cpumask variables.
> Recode to avoid needing the temp cpumask variables and remove the
> memory allocation.
>
> Signed-off-by: Mic
Current code allocates 240 Kbytes (in typical configs) for
each synthetic SCSI controller to use as temp cpumask variables.
Recode to avoid needing the temp cpumask variables and remove the
memory allocation.
Signed-off-by: Michael Kelley
---
This patch is for the 4.18/scsi-queue branch and impr
Christoph Hellwig writes:
> On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote:
>> > struct pid_namespace *proc_pid_namespace(struct inode *inode)
>> > {
>> >// maybe warn on for s_magic not on procfs??
>> >return inode->i_sb->s_fs_info;
>> > }
>>
>> That should work. Ide
The SCSI command pointer passed to scsi_eh callbacks is just one arbitrary
command of potentially many that are in the eh queue to be processed.
The command is only used to indirectly pass the TMF scope in terms of
SCSI ID/target and SCSI LUN for LUN reset.
Hence, zfcp had filled in SCSI trace rec
From: Jens Remus
The comment on fsf_qtcb_bottom_port.supported_speed did read as if the
field can only assume one of two possible values (i.e. 0x1 for 1 GBit/s or
0x2 for 2 GBit/s). This is not true for two reasons: first it is a flag
field and can thus assume any combination and second there are
From: Jens Remus
Otherwise iterating with list_for_each() over the adapter->erp_ready_head
and adapter->erp_running_head lists can lead to an infinite loop. See
commit "zfcp: fix infinite iteration on erp_ready_head list".
The run-time check is only performed for debug kernels which have the
ker
I just happened to see the function header indentation of
zfcp_fc_enqueue_event() and I picked some more from checkpatch:
$ checkpatch.pl --strict -f drivers/s390/scsi/zfcp_fc.c
...
CHECK: Alignment should match open parenthesis
#113: FILE: drivers/s390/scsi/zfcp_fc.c:113:
+ fc_host
Make use of feature introduced with v3.2 commit 294436914454
("[SCSI] scsi: Added support for adapter and firmware reset").
The common code interface was introduced for commit 95d31262b3c1
("[SCSI] qla4xxx: Added support for adapter and firmware reset").
$ echo adapter > /sys/class/scsi_host/host/
From: Jens Remus
Add port speed capabilities as defined in FC-LS RPSC ELS that have a
counterpart FC_PORTSPEED_* defined in scsi/scsi_transport_fc.h.
Suggested-by: Steffen Maier
Signed-off-by: Jens Remus
Reviewed-by: Steffen Maier
Reviewed-by: Fedor Loshakov
Acked-by: Hendrik Brueckner
Acke
Simplify its signature to return boolean and rename it to
zfcp_erp_action_is_running() to indicate its actual unmodified semantics.
It has always been used like this since v2.6.0 history commit ea127f975424
("[PATCH] s390 (7/7): zfcp host adapter.").
Signed-off-by: Steffen Maier
Reviewed-by: Benj
Originally, I planned for TMF handling to have different context data in
fsf_req->data depending on the TMF scope in fcp_cmnd->fc_tm_flags:
* scsi_device if FCP_TMF_LUN_RESET,
* zfcp_port if FCP_TMF_TGT_RESET.
However, the FCP channel requires a valid LUN handle so we now use
scsi_device as context
I've been mixing up
zfcp_task_mgmt_function() [SCSI] and
zfcp_fsf_fcp_task_mgmt() [FSF]
so often lately that I wanted to fix this.
SCSI changes complement v2.6.27 commit f76af7d7e363
("[SCSI] zfcp: Cleanup of code in zfcp_scsi.c").
While at it, also fixup the other inconsistencies elsewhere.
ER
For problem determination we always want to see when we were invoked
on the terminate_rport_io callback whether we perform something or not.
Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec:
loose remote port
t workqueue
[s] zfcp_q_ IRQ zfcperp
=
Note: zfcp_scsi_eh_host_reset_handler() will be converted in a later patch.
zfcp_scsi_eh_device_reset_handler() now only depends on scsi_device.
zfcp_scsi_eh_target_reset_handler() now only depends on scsi_target.
All derive other objects from these intended callback arguments.
zfcp_scsi_eh_targe
All constant defines were introduced with v2.6.0 history commit
ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.") and refactored into
enums with commit 287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c").
ZFCP_STATUS_ERP_DISMISSING and ZFCP_ERP_STEP_FSF_XCONFIG were never used.
v2.6.27
Since v2.6.27 commit 553448f6c483 ("[SCSI] zfcp: Message cleanup"),
none of the callers has been interested any more.
Values were not returned consistently in all ERP trigger functions.
Signed-off-by: Steffen Maier
Reviewed-by: Benjamin Block
---
drivers/s390/scsi/zfcp_erp.c | 34 +-
While the default did already correctly print "Initiator"
let's make it explicit and convert zfcp to the feature.
$ cat /sys/class/scsi_host/host0/supported_mode
Initiator
$ cat /sys/class/scsi_host/host0/active_mode
Initiator
The default worked, because not setting the field has it initialized
Intentionally retrieve the rport by walking SCSI common code objects
rather than zfcp_sdev->port->rport.
The latter is used for pairing the calls to fc_remote_port_add() and
fc_remote_port_delete(). [see v2.6.31 commit 379d6bf6573e ("[SCSI] zfcp:
Add port only once to FC transport class")]
zfcp_s
That other commit introduced an inconsistency because it would trace
on ERP_FAILED for all callers of port forced reopen triggers
(not just terminate_rport_io), but it would not trace on ERP_FAILED
for all callers of other ERP triggers such as adapter, port regular, LUN.
Therefore, generalize that
If a SCSI device is deleted during scsi_eh host reset, we cannot get a
reference to the SCSI device anymore since scsi_device_get returns !=0
by design. Assuming the recovery of adapter and port(s) was successful,
zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for
the half-gon
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : REC
Subarea: 00
Level : 1
Exception : -
CPU ID : ..
Caller : 0x...
Record ID : 1 ZFCP_DBF_REC_TRIG
Tag: ...
LUN
As a prerequisite, complement commit 3d1cb2059d93 ("workqueue: include
workqueue info when printing debug dump of a worker task") to be usable
with kernel modules by exporting the symbol set_worker_desc().
Current built-in user was introduced with commit ef3b101925f2 ("writeback:
set worker desc to
Actually change the signature of zfcp_fsf_fcp_task_mgmt().
Since it was prepared in the previous patch, we only need to delete
a local auto variable which is now the intended argument.
Prepare zfcp_fsf_fcp_task_mgmt's caller zfcp_task_mgmt_function()
to have its function body only depend on a scsi
In zfcp_fsf_fcp_task_mgmt() resolve the still old argument scsi_cmnd
into scsi_device very early and only depend on scsi_device and derived
objects in the function body.
This prepares to later change the function signature replacing the
scsi_cmnd argument with scsi_device.
Signed-off-by: Steffen
This reverts commit 2443c8b23aea ("[SCSI] zfcp: Merge FCP task management
setup with regular FCP command setup"), because this introduced a
dependency on the unsuitable SCSI command for scsi_eh / TMF.
Signed-off-by: Steffen Maier
Reviewed-by: Hannes Reinecke
Reviewed-by: Benjamin Block
---
dri
We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to
zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the
start of our eh callback and an actual send/recv of an abort / TMF request.
In order to see the temporal sequence including any abort / TMF send
retries, add a
get_device() and its internally used kobject_get() only return NULL
if they get passed NULL as argument. zfcp_get_port_by_wwpn() loops over
adapter->port_list so the iteration variable port is always non-NULL.
Struct device is embedded in struct zfcp_port so &port->dev is always
non-NULL. This is t
For problem determination we need to see whether and why we were
successful or not. This allows deduction of scsi_eh escalation.
Example trace record formatted with zfcpdbf from s390-tools:
Timestamp : ...
Area : SCSI
Subarea: 00
Level : 1
Exception : -
CPU ID
James, Martin,
this is the zfcp patch set for the v4.18 merge window.
The patches apply to Martin's 4.18/scsi-queue.
The patches eventually go on top of the bug fix commit
fa89adba1941e4f3b213399b81732a5c12fd9131
("scsi: zfcp: fix infinite iteration on ERP ready list")
in Martin's 4.17/scsi-fixes
From: Colin Ian King
Trivial fix to spelling mistakes/typos:
"SNIC_IOREQ_ABTS_COMPELTE" -> "SNIC_IOREQ_ABTS_COMPLETE"
"SNIC_IOREQ_LR_COMPELTE" -> "SNIC_IOREQ_LR_COMPLETE"
"SNIC_IOREQ_CMD_COMPELTE" -> "SNIC_IOREQ_CMD_COMPLETE"
Signed-off-by: Colin Ian King
---
drivers/scsi/snic/snic_scsi.c |
On Wed, May 16, 2018 at 08:54:11PM -0700, Himanshu Madhani wrote:
> when ql2xmqsupport=1, use that value to selectively
> enable SCSI-MQ
NAK. This is not something that we should grow driver parameters for.
Btw, should we look into enabling blk-mq by default again now that
all the performance fi
34 matches
Mail list logo
