summaryrefslogtreecommitdiff
path: root/drivers/s390/scsi/zfcp_def.h
AgeCommit message (Collapse)AuthorFilesLines
2023-02-21scsi: zfcp: Change the type of all fsf request id fields and variables to u64Benjamin Block1-3/+3
We use different integer types throughout zfcp to store the FSF request ID and related values; some places use 'unsigned long' and others 'u64'. On s390x these are effectively the same type, but this might cause confusions and is generally inconsistent. The specification for the used hardware specifies this value as a 64-bit number, and ultimately we use this value to communicate with the hardware, so it makes sense to change the type of all these variables to 'u64' where we can. The only exception being when we store it in the 'host_scribble' field of a 'struct scsi_cmnd'; for this case we add a build time check to make sure they are compatible. Link: https://lore.kernel.org/r/9c9cbe5acc2b419a22dce2fed847e3db91b60201.1677000450.git.bblock@linux.ibm.com Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-04-15scsi: zfcp: Fix indentation coding style issueYevhen Viktorov1-3/+3
Code indentation should use tabs where possible. Link: https://lore.kernel.org/r/e8a15a2f3d64e2e76a214647cfd4fe23d370b165.1618417667.git.bblock@linux.ibm.com Signed-off-by: Yevhen Viktorov <yevhen.viktorov@virginmedia.com> Signed-off-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-16Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds1-0/+1
Pull SCSI updates from James Bottomley: "This consists of the usual driver updates (ufs, qla2xxx, smartpqi, target, zfcp, fnic, mpt3sas, ibmvfc) plus a load of cleanups, a major power management rework and a load of assorted minor updates. There are a few core updates (formatting fixes being the big one) but nothing major this cycle" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (279 commits) scsi: mpt3sas: Update driver version to 36.100.00.00 scsi: mpt3sas: Handle trigger page after firmware update scsi: mpt3sas: Add persistent MPI trigger page scsi: mpt3sas: Add persistent SCSI sense trigger page scsi: mpt3sas: Add persistent Event trigger page scsi: mpt3sas: Add persistent Master trigger page scsi: mpt3sas: Add persistent trigger pages support scsi: mpt3sas: Sync time periodically between driver and firmware scsi: qla2xxx: Update version to 10.02.00.104-k scsi: qla2xxx: Fix device loss on 4G and older HBAs scsi: qla2xxx: If fcport is undergoing deletion complete I/O with retry scsi: qla2xxx: Fix the call trace for flush workqueue scsi: qla2xxx: Fix flash update in 28XX adapters on big endian machines scsi: qla2xxx: Handle aborts correctly for port undergoing deletion scsi: qla2xxx: Fix N2N and NVMe connect retry failure scsi: qla2xxx: Fix FW initialization error on big endian machines scsi: qla2xxx: Fix crash during driver load on big endian machines scsi: qla2xxx: Fix compilation issue in PPC systems scsi: qla2xxx: Don't check for fw_started while posting NVMe command scsi: qla2xxx: Tear down session if FW say it is down ...
2020-12-02s390/zfcp: remove pm support from zfcp driverVineeth Vijayan1-1/+0
As part of removing the power management support from s390 arch, remove PM callbacks from the scsi/zfcp driver. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-10-29scsi: zfcp: Handle event-lost notification for Version Change eventsJulian Wiedmann1-0/+1
As recovery for a lost Version Change event, trigger an Exchange Config Data cmd to retrieve the current FW version. Doing so requires process context (as eg. zfcp_qdio_sbal_get() might need to sleep), so defer from tasklet context into a work item. Link: https://lore.kernel.org/r/297c7be2944c3714863fcd22d531d910312d29f0.1603908167.git.bblock@linux.ibm.com Suggested-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-03-17scsi: zfcp: trace FC Endpoint Security of FCP devices and connectionsJens Remus1-0/+1
Trace changes in Fibre Channel Endpoint Security capabilities of FCP devices as well as changes in Fibre Channel Endpoint Security state of their connections to FC remote ports as FC Endpoint Security changes with trace level 3 in HBA DBF. A change in FC Endpoint Security capabilities of FCP devices is traced as response to FSF command FSF_QTCB_EXCHANGE_PORT_DATA with a trace tag of "fsfcesa" and a WWPN of ZFCP_DBF_INVALID_WWPN = 0x0000000000000000 (see FC-FS-4 §18 "Name_Identifier Formats", NAA field). A change in FC Endpoint Security state of connections between FCP devices and FC remote ports is traced as response to FSF command FSF_QTCB_OPEN_PORT_WITH_DID with a trace tag of "fsfcesp". Example trace record of FC Endpoint Security capability change of FCP device formatted with zfcpdbf from s390-tools: Timestamp : ... Area : HBA Subarea : 00 Level : 3 Exception : - CPU ID : ... Caller : 0x... Record ID : 5 ZFCP_DBF_HBA_FCES Tag : fsfcesa FSF FC Endpoint Security adapter Request ID : 0x... Request status : 0x00000010 FSF cmnd : 0x0000000e FSF_QTCB_EXCHANGE_PORT_DATA FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000000 FSF_GOOD FSF stat qual : n/a Prot stat : n/a Prot stat qual : n/a Port handle : 0x00000000 none (invalid) LUN handle : n/a WWPN : 0x0000000000000000 ZFCP_DBF_INVALID_WWPN FCES old : 0x00000000 old FC Endpoint Security FCES new : 0x00000007 new FC Endpoint Security Example trace record of FC Endpoint Security change of connection to FC remote port formatted with zfcpdbf from s390-tools: Timestamp : ... Area : HBA Subarea : 00 Level : 3 Exception : - CPU ID : ... Caller : 0x... Record ID : 5 ZFCP_DBF_HBA_FCES Tag : fsfcesp FSF FC Endpoint Security port Request ID : 0x... Request status : 0x00000010 FSF cmnd : 0x00000005 FSF_QTCB_OPEN_PORT_WITH_DID FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000000 FSF_GOOD FSF stat qual : n/a Prot stat : n/a Prot stat qual : n/a Port handle : 0x... WWPN : 0x500507630401120c WWPN FCES old : 0x00000000 old FC Endpoint Security FCES new : 0x00000004 new FC Endpoint Security Link: https://lore.kernel.org/r/20200312174505.51294-9-maier@linux.ibm.com Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-03-17scsi: zfcp: log FC Endpoint Security of connectionsJens Remus1-0/+1
Log the usage of and subsequent changes in FC Endpoint Security of connections between FCP devices and FC remote ports to the kernel ring buffer. Activation of FC Endpoint Security is logged as informational. Change and deactivation are logged as warning. No logging takes place, if FC Endpoint Security is not used (i.e. never activated) on a connection or if it does not change during reopen of a port (e.g. due to adapter or port recovery). Link: https://lore.kernel.org/r/20200312174505.51294-8-maier@linux.ibm.com Reviewed-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-03-17scsi: zfcp: report FC Endpoint Security in sysfsJens Remus1-1/+3
Add an interface to read Fibre Channel Endpoint Security information of FCP channels and their connections to FC remote ports. It comes in the form of new sysfs attributes that are attached to the CCW device representing the FCP device and its zfcp port objects. The read-only sysfs attribute "fc_security" of a CCW device representing a FCP device shows the FC Endpoint Security capabilities of the device. Possible values are: "unknown", "unsupported", "none", or a comma- separated list of one or more mnemonics and/or one hexadecimal value representing the supported FC Endpoint Security: Authentication: Authentication supported Encryption : Encryption supported The read-only sysfs attribute "fc_security" of a zfcp port object shows the FC Endpoint Security used on the connection between its parent FCP device and the FC remote port. Possible values are: "unknown", "unsupported", "none", or a mnemonic or hexadecimal value representing the FC Endpoint Security used: Authentication: Connection has been authenticated Encryption : Connection is encrypted Both sysfs attributes may return hexadecimal values instead of mnemonics, if the mnemonic lookup table does not contain an entry for the FC Endpoint Security reported by the FCP device. Link: https://lore.kernel.org/r/20200312174505.51294-7-maier@linux.ibm.com Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-10-28scsi: zfcp: diagnostics buffer caching and use for exchange port dataBenjamin Block1-1/+2
The FCP channel exposes two central interfaces to receive information about the local FCP-Adapter/-Port: Exchange Port and Exchange Config Data. Using these commands can negatively impact the adapter if we allow them to be sent at a very high rate. The later parts of this patchset will introduce new user-interfaces to receive more diagnostics from the adapter. To prevent any negative impact from using those, this patch adds a simple caching-mechanism that will prevent a malicious/faulty userspace-application from generating an abnormal high amount of Exchange Port/Config Data traffic. Relevant diagnostic data that is received via Exchange Config/Port Data is cached in buffers associated with the corresponding adapter-struct. Each buffer is associated with a timestamp that signals how old the data is, and, added via a following patch in this series, lets userspace-interfaces determine when the data is too old and needs to be updated. Buffer-updates are made during the normal response path of the corresponding command. With this patch only the output of the Exchange Port Data command is captured. Link: https://lore.kernel.org/r/054ca020ce0a53dc0d9176428bea373898944e6a.1572018130.git.bblock@linux.ibm.com Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-10-28scsi: zfcp: signal incomplete or error for sync exchange config/port dataBenjamin Block1-0/+1
Adds a new FSF-Request status flag (ZFCP_STATUS_FSFREQ_XDATAINCOMPLETE) that signal that the data received using Exchange Config Data or Exchange Port Data was incomplete. This new flags is set in the respective handlers during the response path. With this patch, only the synchronous FSF-functions for each command got support for the new flag, otherwise it is transparent. Together with this new flag and already existing status flags the synchronous FSF-functions are extended to now detect whether the received data is complete, incomplete or completely invalid (this includes cases where a command ran into a timeout). This is now signaled back to the caller, where previously only failures on the request path would result in a bad return-code. For complete data the return-code remains 0. For incomplete data a new return-code -EAGAIN is added to the function-interface. For completely invalid data the already existing return-code -EIO is reused - formerly this was used to signal failures on the request path. Existing callers of the FSF-functions are adjusted so that they behave as before for return-code 0 and -EAGAIN, to not change the user-interface. As -EIO existed all along, it was already exposed to the user - and needed handling - and will now also be exposed in this new special case. Link: https://lore.kernel.org/r/e14f0702fa2b00a4d1f37c7981a13f2dd1ea2c83.1572018130.git.bblock@linux.ibm.com Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: use enum zfcp_erp_steps for struct zfcp_erp_action.stepSteffen Maier1-1/+15
Use the already defined enum for this purpose to get at least some build checking (even though an enum is type equivalent to an int in C). v2.6.27 commit 287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c") introduced the enum which was cpp defines previously. Since struct zfcp_erp_action type is embedded into other structures living in zfcp_def.h, we have to move enum zfcp_erp_act_type from its private definition in zfcp_erp.c to the zfcp-global zfcp_def.h Silence some false -Wswitch compiler warning cases with individual NOP cases. When adding more enum values and building with W=1 we would get compiler warnings about missed new cases. Add missing break statements in some of the above switch cases. No functional change, but making it future-proof. I think all of these should have had a break statement ever since, even if these switch cases happened to be the last ones in the switch statement body. "Fall through" in the context of switch case usually means not to have a break and fall through to the subsequent switch case. However, I think this old comment meant that here we do not have an _early return_ in the switch case but the code path continues after the switch case body. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: the action field of zfcp_erp_action is actually the typeSteffen Maier1-1/+19
&zfcp_erp_action.action ==> &zfcp_erp_action.type While at it, make use of the already defined enum for this purpose to get at least some build checking (even though an enum is type equivalent to an int in C). v2.6.27 commit 287ac01acf22 ("[SCSI] zfcp: Cleanup code in zfcp_erp.c") introduced the enum which was cpp defines previously. To prevent compiler warnings with the switch(act->type), we have to separate the recently added eyecatchers from enum zfcp_erp_act_type. Since struct zfcp_erp_action type is embedded into other structures living in zfcp_def.h, we have to move enum zfcp_erp_act_type from its private definition in zfcp_erp.c to the zfcp-global zfcp_def.h. Silence one false -Wswitch compiler warning case: LUNs as the leaves in our object tree do not have any follow-up success recovery. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: drop duplicate seq_no from zfcp_fsf_req which is also in QTCB headerSteffen Maier1-2/+0
There is no point for double bookkeeping especially just for tracing. The trace can take it from the QTCB which always exists for non-SRB responses traced with zfcp_dbf_hba_fsf_res(). As a side effect, this removes an alignment hole and reduces the size of struct zfcp_fsf_req, and thus of each pending request, by 8 bytes. Before: $ pahole -C zfcp_fsf_req drivers/s390/scsi/zfcp.ko ... struct fsf_qtcb * qtcb; /* 144 8 */ u32 seq_no; /* 152 4 */ /* XXX 4 bytes hole, try to pack */ void * data; /* 160 8 */ ... /* size: 296, cachelines: 2, members: 14 */ /* sum members: 288, holes: 2, sum holes: 8 */ /* last cacheline: 40 bytes */ After: $ pahole -C zfcp_fsf_req drivers/s390/scsi/zfcp.ko ... struct fsf_qtcb * qtcb; /* 144 8 */ void * data; /* 152 8 */ ... /* size: 288, cachelines: 2, members: 13 */ /* sum members: 284, holes: 1, sum holes: 4 */ Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: drop duplicate fsf_command from zfcp_fsf_req which is also in ↵Steffen Maier1-2/+5
QTCB header Status read buffers (SRBs, unsolicited notifications) never use a QTCB [zfcp_fsf_req_create()]. zfcp_fsf_req_send() already uses this to distinguish SRBs from other FSF request types. We can re-use this method in zfcp_fsf_req_complete(). Introduce a helper function to make the check for req->qtcb less magic. SRBs always are FSF_QTCB_UNSOLICITED_STATUS, so we can hard-code this for the two trace functions dealing with SRBs. All other FSF request types have a QTCB and we can get the fsf_command from there. zfcp_dbf_hba_fsf_response() and thus zfcp_dbf_hba_fsf_res() are only called for non-SRB requests so it's safe to dereference the QTCB [zfcp_fsf_req_complete() returns early on SRB, else calls zfcp_fsf_protstatus_eval() which calls zfcp_dbf_hba_fsf_response()]. In zfcp_scsi_forget_cmnd() we guard the QTCB dereference with a preceding NULL check and rely on boolean shortcut evaluation. As a side effect, this causes an alignment hole which we can close in a later patch after having cleaned up all fields of struct zfcp_fsf_req. Before: $ pahole -C zfcp_fsf_req drivers/s390/scsi/zfcp.ko ... u32 status; /* 136 4 */ u32 fsf_command; /* 140 4 */ struct fsf_qtcb * qtcb; /* 144 8 */ ... After: $ pahole -C zfcp_fsf_req drivers/s390/scsi/zfcp.ko ... u32 status; /* 136 4 */ /* XXX 4 bytes hole, try to pack */ struct fsf_qtcb * qtcb; /* 144 8 */ ... Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: drop unnecessary forward prototype for struct zfcp_fsf_reqSteffen Maier1-2/+0
Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: group sort internal structure definitions for proximitySteffen Maier1-29/+29
Have structures just before the structures that use them (without disrupting sequences of using structures such as zfcp_unit and zfcp_scsi_dev): - zfcp_adapter_mempool embedded in zfcp_adapter, - zfcp_latenc... embedded in zfcp_scsi_dev. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: namespace prefix for internal latency data structuresSteffen Maier1-7/+7
In contrast to struct fsf_qual_latency_info, the ones here are not FSF but software defined zfcp-internal. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: update width in comment for ZFCP_COMMON_FLAGS maskSteffen Maier1-2/+2
v2.6.10 history commit 4062e12b2ba2 ("[PATCH] s390: zfcp act enhancements") extended this mask by one nibble with the introduction of ZFCP_STATUS_COMMON_ACCESS_DENIED == 0x00800000 for ACT (access control table). Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: move scsi_eh & non-ERP timeout defines owned by and local to ↵Steffen Maier1-6/+0
zfcp_fsf.c Also clarify namespace prefix for the timeout used for FSF requests on behalf of SCSI error recovery: It is zfcp_fsf_ not zfcp_scsi_. Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-15scsi: zfcp: drop unnecessary forward prototype for struct zfcp_reqlistSteffen Maier1-3/+1
While struct zfcp_adapter contains a pointer to zfcp_reqlist, the pointer field does not need to know the structure or even a prototype. The prototype was introduced with v2.6.34 commit b6bd2fb92a7b ("[SCSI] zfcp: Move FSF request tracking code to new file"). Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-20zfcp: auto port scan resiliencyMartin Peschke1-1/+2
This patch improves the Fibre Channel port scan behaviour of the zfcp lldd. Without it the zfcp device driver may churn up the storage area network by excessive scanning and scan bursts, particularly in big virtual server environments, potentially resulting in interference of virtual servers and reduced availability of storage connectivity. The two main issues as to the zfcp device drivers automatic port scan in virtual server environments are frequency and simultaneity. On the one hand, there is no point in allowing lots of ports scans in a row. It makes sense, though, to make sure that a scan is conducted eventually if there has been any indication for potential SAN changes. On the other hand, lots of virtual servers receiving the same indication for a SAN change had better not attempt to conduct a scan instantly, that is, at the same time. Hence this patch has a two-fold approach for better port scanning: the introduction of a rate limit to amend frequency issues, and the introduction of a short random backoff to amend simultaneity issues. Both approaches boil down to deferred port scans, with delays comprising parts for both approaches. The new port scan behaviour is summarised best by: NEW: NEW: no_auto_port_rescan random rate flush backoff limit =wait adapter resume/thaw yes yes no yes* adapter online (user) no yes no yes* port rescan (user) no no no yes adapter recovery (user) yes yes yes no adapter recovery (other) yes yes yes no incoming ELS yes yes yes no incoming ELS lost yes yes yes no Implementation is straight-forward by converting an existing worker to a delayed worker. But care is needed whenever that worker is going to be flushed (in order to make sure work has been completed), since a flush operation cancels the timer set up for deferred execution (see * above). There is a small race window whenever a port scan work starts running up to the point in time of storing the time stamp for that port scan. The impact is negligible. Closing that gap isn't trivial, though, and would the destroy the beauty of a simple work-to-delayed-work conversion. Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2013-05-31[SCSI] zfcp: remove access control tables interfaceMartin Peschke1-4/+0
This patch removes an interface that was used to manage access control tables within the HBA. The patch consequently removes the handling for conditions related to those access control tables, too. That initiator-based access control feature was only needed until the introduction of NPIV and was withdrawn with z10 years ago. It's time to cleanup the corresponding device driver code. Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-24[SCSI] zfcp: restore refcount check on port_removeSteffen Maier1-0/+1
Upstream commit f3450c7b917201bb49d67032e9f60d5125675d6a "[SCSI] zfcp: Replace local reference counting with common kref" accidentally dropped a reference count check before tearing down zfcp_ports that are potentially in use by zfcp_units. Even remote ports in use can be removed causing unreachable garbage objects zfcp_ports with zfcp_units. Thus units won't come back even after a manual port_rescan. The kref of zfcp_port->dev.kobj is already used by the driver core. We cannot re-use it to track the number of zfcp_units. Re-introduce our own counter for units per port and check on port_remove. Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: <stable@vger.kernel.org> #2.6.33+ Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-09-24[SCSI] zfcp: Do not wakeup while suspendedSteffen Maier1-0/+1
If the mapping of FCP device bus ID and corresponding subchannel is modified while the Linux image is suspended, the resume of FCP devices can fail. During resume, zfcp gets callbacks from cio regarding the modified subchannels but they can be arbitrarily mixed with the restore/resume callback. Since the cio callbacks would trigger adapter recovery, zfcp could wakeup before the resume callback. Therefore, ignore the cio callbacks regarding subchannels while being suspended. We can safely do so, since zfcp does not deal itself with subchannels. For problem determination purposes, we still trace the ignored callback events. The following kernel messages could be seen on resume: kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping As part of adapter reopen recovery, zfcp performs auto port scanning which can erroneously try to register new remote ports with scsi_transport_fc and the device core code complains about the parent (adapter) still sleeping. kernel: zfcp.3dff9c: <FCP device bus ID>:\ Setting up the QDIO connection to the FCP adapter failed <last kernel message repeated 3 more times> kernel: zfcp.574d43: <FCP device bus ID>:\ ERP cannot recover an error on the FCP device In such cases, the adapter gave up recovery and remained blocked along with its child objects: remote ports and LUNs/scsi devices. Even the adapter shutdown as part of giving up recovery failed because the ccw device state remained disconnected. Later, the corresponding remote ports ran into dev_loss_tmo. As a result, the LUNs were erroneously not available again after resume. Even a manually triggered adapter recovery (e.g. sysfs attribute failed, or device offline/online via sysfs) could not recover the adapter due to the remaining disconnected state of the corresponding ccw device. Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> #2.6.32+ Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2012-07-20s390/comments: unify copyright messages and remove file namesHeiko Carstens1-1/+1
Remove the file name from the comment at top of many files. In most cases the file name was wrong anyway, so it's rather pointless. Also unify the IBM copyright statement. We did have a lot of sightly different statements and wanted to change them one after another whenever a file gets touched. However that never happened. Instead people start to take the old/"wrong" statements to use as a template for new files. So unify all of them in one go. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2011-08-27[SCSI] zfcp: support for hardware data routerSwen Schillig1-0/+7
FICON Express8S supports hardware data router, which requires an adapted qdio request format. This part 2/2 exploits the functionality in zfcp. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2011-02-25[SCSI] zfcp: Add information to symbolic port name when running in NPIV modeChristof Schmitt1-0/+1
Query the FC symbolic port name for reporting in the fc_host sysfs and enable the symbolic_name attribute in the fc_host sysfs. When running in NPIV mode, extend the symbolic port name with the devno and the hostname. This allows better identification of Linux systems for SAN and storage administrators. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Move SCSI host and transport templates out of struct zfcp_dataChristof Schmitt1-6/+0
The SCSI host and transport templates are the only members left in the global zfcp_data struct. Move them out of zfcp_data and remove the now unused zfcp_data struct. Also update the names of the register and unregister functions to use the zfcp_scsi prefix. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Move qtcb kmem_cache to zfcp_fsf.cChristof Schmitt1-1/+0
Move the kmem_cache for allocating the qtcb to zfcp_fsf.c and rename it accordingly. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Use common FC kmem_cache for GPN_FT requestChristof Schmitt1-1/+0
Switch the allocation of the GPN_FT request data to the FC kmem_cache and remove the zfcp_gpn kmem_cache. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Allocate GID_PN data through new FC kmem_cacheChristof Schmitt1-1/+0
Allocate the data for the GID_PN request through the new FC kmem_cache. While updating the GID_PN code, also introduce a helper function for initializing the CT header for FC nameserver requests. Remove the "paranoia" check as well, the GID_PN request data does not suddenly change. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Introduce new kmem_cache for FC request and response dataChristof Schmitt1-1/+0
A data buffer that is passed to the hardware must not cross a page boundary. zfcp uses a series of kmem_caches to align the data to not cross a page boundary. Introduce a new kmem_cache for the FC requests sent from the zfcp driver and use it for the ELS ADISC data. The goal is to migrate to the FC kmem_cache in later patches and remove the request specific kmem_caches. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Replace kmem_cache for "status read" dataChristof Schmitt1-2/+1
zfcp requires a mempool for the status read data blocks to resubmit the "status read" requests at any time. Each status read data block has the size of a page (4096 bytes) and needs to be placed in one page. Instead of having a kmem_cache for allocating page sized chunks, use mempool_create_page_pool to create a mempool returning pages and remove the zfcp kmem_cache. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-25[SCSI] zfcp: Remove unused flag ZFCP_STATUS_FSFREQ_TASK_MANAGEMENTChristof Schmitt1-1/+0
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-09-16[SCSI] zfcp: Replace status modifier functions.Swen Schillig1-5/+0
Replace the zfcp_modify_<xxx>_status functions and its accompanying wrappers with dedicated status modifier functions. This eases code readability and maintenance. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-09-16[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unitChristof Schmitt1-15/+19
This is the large change to switch from using the data in zfcp_unit to zfcp_scsi_dev. Keeping everything working requires doing the switch in one piece. To ensure that no code keeps using the data in zfcp_unit, this patch also removes the data from zfcp_unit that is now being replaced with zfcp_scsi_dev. For zfcp, the scsi_device together with zfcp_scsi_dev exist from the call of slave_alloc to the call of slave_destroy. The data in zfcp_scsi_dev is initialized in zfcp_scsi_slave_alloc and the LUN is opened; the final shutdown for the LUN is run from slave_destroy. Where the scsi_device or zfcp_scsi_dev is needed, the pointer to the scsi_device is passed as function argument and inside the function converted to the pointer to zfcp_scsi_dev; this avoids back and forth conversion betweeen scsi_device and zfcp_scsi_dev. While changing the function arguments from zfcp_unit to scsi_device, the functions names are renamed form "unit" to "lun". This is to have a seperation between zfcp_scsi_dev/LUN and the zfcp_unit; only code referring to the remaining configuration information in zfcp_unit struct uses "unit". Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-09-16[SCSI] zfcp: Add zfcp private struct as SCSI device driver dataChristof Schmitt1-0/+39
Add a new data structure zfcp_scsi_dev that holds zfcp private data for each SCSI device. Use scsi_transport_reserve_device to let the SCSI midlayer automatically allocate this with each SCSI device. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] zfcp: Trigger logging in the FCP channel on qdio error conditionsChristof Schmitt1-0/+1
Exploit the cio siosl function to trigger logging in the FCP channel on qdio error conditions. Add a helper function in zfcp_qdio to ensure that tracing is only triggered once before calling qdio_shutdown. Trigger in zfcp for hardware logs are: - timeout for FSF requests to the FCP channel - "no recommendation" status from FCP channel - invalid FSF protocol status - stalled outbound queue - unknown request id on inbound queue - QDIO_ERROR_SLSB_STATE All of the above triggers run from the Linux qdio softirq context, so no additional synchronization is necessary for the handling of the ZFCP_STATUS_ADAPTER_SIOSL_ISSUED flag. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] zfcp: Enable data division support for FCP devicesChristof Schmitt1-0/+1
Try to enable data division support for FCP devices and indicate in the adapter status flag if it succeeded. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] zfcp: Post events through FC transport classSven Schuetz1-0/+2
Post FC transport class netlink events for usage in the userspace, e.g. for HBAAPI. Supported events are those required for the polled events in HBAAPI. - link up - link down - incoming RSCN (events related to FC-AL are not supported, as zfcp has no support for FC-AL) Signed-off-by: Sven Schuetz <sven@linux.vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] zfcp: Remove SCSI device when removing unitChristof Schmitt1-0/+1
Configuring a LUN in zfcp, also creates a SCSI device. For consistency, it makes sense to remove the SCSI device when the LUN is deconfigured. Replace the flush_work with the call to scsi_remove_device: scsi_remove_device also takes the scan_mutex that synchronizes itself with any long running device discovery. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-02[SCSI] zfcp: Use status_read_buf_num provided by FCP channelChristof Schmitt1-0/+1
The FCP channel provides the number of status read buffers to issue. Use the provided number instead of the hardcoded number in zfcp. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-02[SCSI] zfcp: Move sbale handling to zfcp_qdio filesChristof Schmitt1-17/+0
Move the code accessing the qdio sbales and zfcp_qdio_req struct to the zfcp_qdio files and provide helper functions for accessing the qdio related parts. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-02[SCSI] zfcp: Report scatter-gather limits to SCSI and block layerChristof Schmitt1-0/+1
Instead of dealing with large segments in the scatter-gather lists in zfcp_qdio.c, report the limits to the upper layers. With these limits in place, the code for mapping large data blocks to multiple sbales can be removed. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-02-17[SCSI] zfcp: Introduce header file for qdio structs and inline functionsChristof Schmitt1-54/+3
Move the qdio related structs and some helper functions to a new zfcp_qdio.h header file. While doing this, rename the struct zfcp_queue_req to zfcp_qdio_req to adhere to the naming scheme used in zfcp. This allows a better seperation of the qdio code and inlining the helper functions will save some function calls. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-02-17[SCSI] zfcp: Rename sysfs_device attribute to dev in zfcp_unit and zfcp_portChristof Schmitt1-3/+3
Kernel code uses dev as short name for the struct device. Rename the sysfs_device in zfcp_unit and zfcp_port to match this convention. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-02-17[SCSI] zfcp: Move FSF request tracking code to new fileChristof Schmitt1-32/+2
Move the code for tracking FSF requests to new file to have this code in one place. The functions for adding and removing requests on the I/O path are already inline. The alloc and free functions are only called once, so it does not hurt to inline them and add them to the same file. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-02-17[SCSI] zfcp: Remove function zfcp_reqlist_find_safeChristof Schmitt1-16/+1
Always use the FSF request id as a reference to the FSF request. With this change the function zfcp_reqlist_find_safe is no longer needed and can be removed. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Remove flag ZFCP_STATUS_FSFREQ_TMFUNCNOTSUPPChristof Schmitt1-1/+0
The flag ZFCP_STATUS_FSFREQ_TMFUNCNOTSUPP is never set and hence can be removed. This is a leftover from the time when zfcp had to decide whether the target supports a "logical unit reset" or not. Nowadays, the SCSI midlayer calls the eh_device_reset_handler or the eh_target_reset_handler and zfcp simply maps this to a "logical unit reset" or a "target reset". Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 07:33:40 +0000