Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62 |
|
#
a60bffe5 |
| 30-Aug-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: split do_QDIO()
The callers know what type of queue they want to work with. Introduce type-specific variants to add buffers on an {Input,Output} queue, so that we can avoid some function
s390/qdio: split do_QDIO()
The callers know what type of queue they want to work with. Introduce type-specific variants to add buffers on an {Input,Output} queue, so that we can avoid some function parameters and the de-muxing into type-specific hot paths.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.14, v5.10.61, v5.10.60, v5.10.53 |
|
#
b44995e5 |
| 23-Jul-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: split qdio_inspect_queue()
The callers know what type of queue they want to inspect. Introduce type-specific variants to inspect an {Input,Output} queue, so that we can avoid one function
s390/qdio: split qdio_inspect_queue()
The callers know what type of queue they want to inspect. Introduce type-specific variants to inspect an {Input,Output} queue, so that we can avoid one function parameter and some conditional branches in the hot paths.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
f6beebb1 |
| 06-Sep-2021 |
Heiko Carstens <hca@linux.ibm.com> |
scsi: zfcp: fix kernel doc comments
A couple of function names don't match what the kernel doc comments indicate.
Acked-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@
scsi: zfcp: fix kernel doc comments
A couple of function names don't match what the kernel doc comments indicate.
Acked-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.10.52, v5.10.51 |
|
#
bdfd740c |
| 14-Jul-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: clarify reporting of errors to the drivers
Now that all drivers use qdio_inspect_queue() and qdio's internal queue tasklets are gone, the driver-specified queue handlers are only called f
s390/qdio: clarify reporting of errors to the drivers
Now that all drivers use qdio_inspect_queue() and qdio's internal queue tasklets are gone, the driver-specified queue handlers are only called for async error reporting (eg. for an error condition in the QEBSM code).
So take a moment to clean up the Output Queue handlers (they are _always_ called with qdio_error != 0), and clarify which error types can be reported through what interface. As Benjamin already suggested a while ago, we should turn these into distinct enums at some point.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31 |
|
#
b3f0a1ee |
| 14-Apr-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
scsi: zfcp: Lift Request Queue tasklet & timer from qdio
The qdio layer currently provides its own infrastructure to scan for Request Queue completions & to report them to the device driver. This c
scsi: zfcp: Lift Request Queue tasklet & timer from qdio
The qdio layer currently provides its own infrastructure to scan for Request Queue completions & to report them to the device driver. This comes with several drawbacks - having an async tasklet & timer construct in qdio introduces additional lifetime complexity, and makes it harder to integrate them with the rest of the device driver. The timeouts are also currently hard-coded, and can't be tweaked without affecting other qdio drivers (ie. qeth).
But due to recent enhancements to the qdio layer, zfcp can actually take full control of the Request Queue completion processing. It merely needs to opt-out from the qdio layer mechanisms by setting the scan_threshold to 0, and then use qdio_inspect_queue() to scan for completions.
So re-implement the tasklet & timer mechanism in zfcp, while initially copying the scan conditions from qdio's handle_outbound() and qdio_outbound_tasklet(). One minor behavioural change is that zfcp_qdio_send() will unconditionally reduce the timeout to 1 HZ, rather than leaving it at 10 Hz if it was last armed by the tasklet. This just makes things more consistent. Also note that we can drop a lot of the accumulated cruft in qdio_outbound_tasklet(), as zfcp doesn't even use PCI interrupt requests any longer.
This also slightly touches the Response Queue processing, as qdio_get_next_buffers() will no longer implicitly scan for Request Queue completions. So complete the migration to qdio_inspect_queue() here as well and make the tasklet_schedule() visible.
Link: https://lore.kernel.org/r/018d3ddd029f8d6ac00cf4184880288c637c4fd1.1618417667.git.bblock@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>
show more ...
|
Revision tags: v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
396c1004 |
| 30-Jan-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: let driver manage the QAOB
We are spending way too much effort on qdio-internal bookkeeping for QAOB management & caching, and it's still not robust. Once qdio's TX path has detached the
s390/qdio: let driver manage the QAOB
We are spending way too much effort on qdio-internal bookkeeping for QAOB management & caching, and it's still not robust. Once qdio's TX path has detached the QAOB from a PENDING buffer, we lost all track of it until it shows up in a CQ notification again. So if the device is torn down before that notification arrives, we leak the QAOB.
Just have the driver take care of it, and simply pass down a QAOB if they want a TX with async-completion capability. For a buffer in PENDING state that requires the QAOB for final completion, qeth can now also try to recycle the buffer's QAOB rather than unconditionally freeing it.
This also eliminates the qdio_outbuf_state array, which was only needed to transfer the aob->user1 tag from the driver to the qdio layer.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.10, v5.8.17 |
|
#
efd32176 |
| 28-Oct-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
scsi: zfcp: Clarify & assert the stat_lock locking in zfcp_qdio_send()
Explain why the plain spin_lock() suffices in current code, even when the stat_lock is also used by zfcp_qdio_int_req() in task
scsi: zfcp: Clarify & assert the stat_lock locking in zfcp_qdio_send()
Explain why the plain spin_lock() suffices in current code, even when the stat_lock is also used by zfcp_qdio_int_req() in tasklet context.
We could also promote the spin_lock() to a spin_lock_irqsave(), but that would just obfuscate the locking even further.
Link: https://lore.kernel.org/r/b023b1472630f4bf9fce580577d7bb49de89ccbf.1603908167.git.bblock@linux.ibm.com Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Steffen Maier <maier@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>
show more ...
|
#
0b524abc |
| 28-Oct-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
scsi: zfcp: Lift Input Queue tasklet from qdio
Shift the IRQ tasklet processing from the qdio layer into zfcp. This will allow for a good amount of cleanups in qdio, and provides future opportunity
scsi: zfcp: Lift Input Queue tasklet from qdio
Shift the IRQ tasklet processing from the qdio layer into zfcp. This will allow for a good amount of cleanups in qdio, and provides future opportunity to improve the IRQ processing inside zfcp.
We continue to use the qdio layer's internal tasklet/timer mechanism (ie. scan_threshold etc) to check for Request Queue completions. Initially we planned to check for such completions after inspecting the Response Queue - this should typically work, but there's a theoretical race where the device only presents the Request Queue completions _after_ all Response Queue processing has finished. If the Request Queue is then also _completely_ full, we could send no further IOs and thus get no interrupt that would trigger an inspection of the Request Queue. So for now stick to the old model, where we can trust that such a race would be recovered by qdio's internal timer.
Code-flow wise, this establishes two levels of control:
1. The qdio layer will only deliver IRQs to the device driver if the QDIO_IRQ_DISABLED flag is cleared. zfcp manages this through qdio_start_irq() / qdio_stop_irq(). The initial state is DISABLED, and zfcp_qdio_open() schedules zfcp's IRQ tasklet once during startup to explicitly enable IRQ delivery.
2. The zfcp tasklet is initialized with tasklet_disable(), and only gets enabled once we open the qdio device. When closing the qdio device, we must disable the tasklet _before_ disabling IRQ delivery (otherwise a concurrently running tasklet could re-enable IRQ delivery after we disabled it).
A final tasklet_kill() during teardown ensures that no lingering tasklet_schedule() is still accessing the tasklet structure.
Link: https://lore.kernel.org/r/94a765211c48b74a7b91c5e60b158de01db98d43.1603908167.git.bblock@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>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
180a4c42 |
| 24-Aug-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: always use dev_name() for device name in QIB
Passing a custom name from the device driver is nice - but in practice it's only zfcp who has been using this. So we might as well hard-code a
s390/qdio: always use dev_name() for device name in QIB
Passing a custom name from the device driver is nice - but in practice it's only zfcp who has been using this. So we might as well hard-code a naming scheme in the qdio layer, so that qeth also benefits from it.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51 |
|
#
c3bfffa5 |
| 03-Jul-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
scsi: zfcp: Avoid benign overflow of the Request Queue's free-level
zfcp_qdio_send() and zfcp_qdio_int_req() run concurrently, adding and completing SBALs on the Request Queue. There's a theoretical
scsi: zfcp: Avoid benign overflow of the Request Queue's free-level
zfcp_qdio_send() and zfcp_qdio_int_req() run concurrently, adding and completing SBALs on the Request Queue. There's a theoretical race where zfcp_qdio_int_req() completes a number of SBALs & increments the queue's free-level _before_ zfcp_qdio_send() was able to decrement it.
This can cause ->req_q_free to momentarily hold a value larger than QDIO_MAX_BUFFERS_PER_Q. Luckily zfcp_qdio_send() is always called under ->req_q_lock, and all readers of the free-level also take this lock. So we can trust that zfcp_qdio_send() will clean up such a temporary overflow before anyone can actually observe it.
But it's still confusing and annoying to worry about. So adjust the code to avoid this race.
Link: https://lore.kernel.org/r/7f61f59a1f8db270312e64644f9173b8f1ac895f.1593780621.git.bblock@linux.ibm.com Reviewed-by: Steffen Maier <maier@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>
show more ...
|
#
459ad085 |
| 03-Jul-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
scsi: zfcp: Fix an outdated comment for zfcp_qdio_send()
zfcp no longer uses the qdio PCI flag, update the comment.
Link: https://lore.kernel.org/r/6717c26fc986bff8776d110e27c199b523684c63.15937806
scsi: zfcp: Fix an outdated comment for zfcp_qdio_send()
zfcp no longer uses the qdio PCI flag, update the comment.
Link: https://lore.kernel.org/r/6717c26fc986bff8776d110e27c199b523684c63.1593780621.git.bblock@linux.ibm.com Fixes: 21ddaa53f92d ("[SCSI] zfcp: Remove PCI flag") Reviewed-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Fedor Loshakov <loshakov@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>
show more ...
|
Revision tags: v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40 |
|
#
978857c7 |
| 08-May-2020 |
Benjamin Block <bblock@linux.ibm.com> |
scsi: zfcp: Move shost modification after QDIO (re-)open into fenced function
When establishing and activating the QDIO queue pair for a FCP device for the first time, or after an adapter recovery,
scsi: zfcp: Move shost modification after QDIO (re-)open into fenced function
When establishing and activating the QDIO queue pair for a FCP device for the first time, or after an adapter recovery, we publish some of its characteristics to the scsi host object representing that FCP device.
When moving the scsi host object allocation and registration to after the first exchange config and exchange port data, this is not possible for the former case - QDIO open for the first time - because that happens before exchange config and exchange port data.
Move the scsi host object update into a fenced function that checks whether the object already exists or not. This way we can repeat that step later, once we are past the allocation.
Once the first recovery succeeds we don't release the scsi host object anymore, so further recoveries do work as before.
Link: https://lore.kernel.org/r/a214ebf508f71e3690113e3e90edab1cea0e24e3.1588956679.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>
show more ...
|
Revision tags: v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27 |
|
#
1da1092d |
| 20-Mar-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: remove cdev from init_data
It's no longer needed.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@
s390/qdio: remove cdev from init_data
It's no longer needed.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
d8564e19 |
| 20-Mar-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: allow for non-contiguous SBAL array in init_data
Upper-layer drivers allocate their SBALs by calling qdio_alloc_buffers() for each individual queue. But when later passing the SBAL addres
s390/qdio: allow for non-contiguous SBAL array in init_data
Upper-layer drivers allocate their SBALs by calling qdio_alloc_buffers() for each individual queue. But when later passing the SBAL addresses to qdio_establish(), they need to be in a single array of pointers. So if the driver uses multiple Input or Output queues, it needs to allocate a temporary array just to present all its SBAL pointers in this layout.
This patch slightly changes the format of the QDIO initialization data, so that drivers can pass a per-queue array where each element points to a queue's SBAL array. zfcp doesn't use multiple queues, so the impact there is trivial. For qeth this brings a nice reduction in complexity, and removes a page-sized allocation.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
ad96401c |
| 20-Mar-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
zfcp: inline zfcp_qdio_setup_init_data()
In preparation for a subsequent patch, move the setup of init_data into the only caller.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Ben
zfcp: inline zfcp_qdio_setup_init_data()
In preparation for a subsequent patch, move the setup of init_data into the only caller.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
3db1db93 |
| 20-Mar-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: cleanly split alloc and establish
All that qdio_allocate() actually uses from the init_data is the cdev, and the number of Input and Output Queues. Have the driver pass those as parameter
s390/qdio: cleanly split alloc and establish
All that qdio_allocate() actually uses from the init_data is the cdev, and the number of Input and Output Queues. Have the driver pass those as parameters, and defer the init_data processing into qdio_establish(). This includes writing per-device(!) trace entries, and most of the sanity checks.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19 |
|
#
2db01da8 |
| 11-Feb-2020 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: fill SBALEs with absolute addresses
sbale->addr holds an absolute address (or for some FCP usage, an opaque request ID), and should only be used with proper virt/phys translation.
Signed
s390/qdio: fill SBALEs with absolute addresses
sbale->addr holds an absolute address (or for some FCP usage, an opaque request ID), and should only be used with proper virt/phys translation.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19 |
|
#
bdf11767 |
| 28-Jan-2019 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/qdio: make SBAL address array type-safe
There is no need to use void pointers, all drivers are in agreement about the underlying data structure of the SBAL arrays.
Signed-off-by: Julian Wiedma
s390/qdio: make SBAL address array type-safe
There is no need to use void pointers, all drivers are in agreement about the underlying data structure of the SBAL arrays.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18 |
|
#
8684d614 |
| 08-Nov-2018 |
Steffen Maier <maier@linux.ibm.com> |
scsi: zfcp: silence all W=1 build warnings for existing kdoc
While at it also improve some copy & paste kdoc mistakes.
Signed-off-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: Benjamin Block
scsi: zfcp: silence all W=1 build warnings for existing kdoc
While at it also improve some copy & paste kdoc mistakes.
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>
show more ...
|
#
208d0961 |
| 08-Nov-2018 |
Steffen Maier <maier@linux.ibm.com> |
scsi: zfcp: clarify function argument name for trace tag string
v2.6.30 commit 5ffd51a5e495 ("[SCSI] zfcp: replace current ERP logging with a more convenient version") changed trace record distingui
scsi: zfcp: clarify function argument name for trace tag string
v2.6.30 commit 5ffd51a5e495 ("[SCSI] zfcp: replace current ERP logging with a more convenient version") changed trace record distinguishing from a numerical ID to a 7 character string called "trace tag". While starting to use function arguments with different type and semantics, it did not change the argument name accordingly.
v2.6.38 commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") renamed variable names "id" into "tag" but only within zfcp_dbf.*, not within zfcp_erp.c.
This was a bit confusing since the remainder of zfcp does use the term "trace tag". Also "id" is quite generic and it's not obvious for what. Just unify it consistently and use the "dbf" prefix to relate the arguments to the code in zfcp_dbf.*.
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>
show more ...
|
Revision tags: v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
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>
show more ...
|
Revision tags: v4.13.5, v4.13 |
|
#
5156934b |
| 28-Jul-2017 |
Benjamin Block <bblock@linux.vnet.ibm.com> |
scsi: zfcp: convert bool-definitions to use 'true' instead of '1'
Better form and cleans remaining warnings.
Found with scripts/coccinelle/misc/boolinit.cocci.
Signed-off-by: Benjamin Block <bbloc
scsi: zfcp: convert bool-definitions to use 'true' instead of '1'
Better form and cleans remaining warnings.
Found with scripts/coccinelle/misc/boolinit.cocci.
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1 |
|
#
805de8f4 |
| 23-Apr-2015 |
Peter Zijlstra <peterz@infradead.org> |
atomic: Replace atomic_{set,clear}_mask() usage
Replace the deprecated atomic_{set,clear}_mask() usage with the now ubiquous atomic_{or,andnot}() functions.
Signed-off-by: Peter Zijlstra (Intel) <p
atomic: Replace atomic_{set,clear}_mask() usage
Replace the deprecated atomic_{set,clear}_mask() usage with the now ubiquous atomic_{or,andnot}() functions.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
show more ...
|
Revision tags: v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3 |
|
#
852eb1aa |
| 27-Jun-2014 |
Sebastian Ott <sebott@linux.vnet.ibm.com> |
s390/zfcp: use qdio buffer helpers
Use qdio buffer helpers to manage the buffers used for the request and response queues.
No functional change.
Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.co
s390/zfcp: use qdio buffer helpers
Use qdio buffer helpers to manage the buffers used for the request and response queues.
No functional change.
Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7 |
|
#
909ee499 |
| 22-Aug-2013 |
Steffen Maier <maier@linux.vnet.ibm.com> |
[SCSI] zfcp: enable FCP hardware data router by default
Enabling the data router support by default can increase performance in certain situations. It is safe to do so and tolerated in LPAR and unde
[SCSI] zfcp: enable FCP hardware data router by default
Enabling the data router support by default can increase performance in certain situations. It is safe to do so and tolerated in LPAR and under z/VM in case there is no data router support in that environment.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com> Reviewed-by: Martin Peschke <mpeschke@linux.vnet.ibm.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
show more ...
|