wireguard-linux/drivers/s390, branch jd/unified-crypt-queue

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2020-04-10T19:21:11Z

Pull more SCSI updates from James Bottomley: "This is a batch of changes that didn't make it in the initial pull request because the lpfc series had to be rebased to redo an incorrect split. It's basically driver updates to lpfc, target, bnx2fc and ufs with the rest being minor updates except the sr_block_release one which fixes a use after free introduced by the removal of the global mutex in the first patch set" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (35 commits) scsi: core: Add DID_ALLOC_FAILURE and DID_MEDIUM_ERROR to hostbyte_table scsi: ufs: Use ufshcd_config_pwr_mode() when scaling gear scsi: bnx2fc: fix boolreturn.cocci warnings scsi: zfcp: use fallthrough; scsi: aacraid: do not overwrite retval in aac_reset_adapter() scsi: sr: Fix sr_block_release() scsi: aic7xxx: Remove more FreeBSD-specific code scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug scsi: ufs: set device as active power mode after resetting device scsi: iscsi: Report unbind session event when the target has been removed scsi: lpfc: Change default SCSI LUN QD to 64 scsi: libfc: rport state move to PLOGI if all PRLI retry exhausted scsi: libfc: If PRLI rejected, move rport to PLOGI state scsi: bnx2fc: Update the driver version to 2.12.13 scsi: bnx2fc: Fix SCSI command completion after cleanup is posted scsi: bnx2fc: Process the RQE with CQE in interrupt context scsi: target: use the stack for XCOPY passthrough cmds scsi: target: increase XCOPY I/O size scsi: target: avoid per-loop XCOPY buffer allocations scsi: target: drop xcopy DISK BLOCK LENGTH debug ...

Merge tag 's390-5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

2020-04-10T16:47:26Z

Pull more s390 updates from Vasily Gorbik: "Second round of s390 fixes and features for 5.7: - The rest of fallthrough; annotations conversion - Couple of fixes for ADD uevents in the common I/O layer - Minor refactoring of the queued direct I/O code" * tag 's390-5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: generate delayed uevent for vfio-ccw subchannels s390/cio: avoid duplicated 'ADD' uevents s390/qdio: clear DSCI early for polling drivers s390/qdio: inline shared_ind() s390/qdio: remove cdev from init_data s390/qdio: allow for non-contiguous SBAL array in init_data zfcp: inline zfcp_qdio_setup_init_data() s390/qdio: cleanly split alloc and establish s390/mm: use fallthrough;

Merge tag 'libnvdimm-for-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

2020-04-09T04:03:40Z

Pull libnvdimm and dax updates from Dan Williams: "There were multiple touches outside of drivers/nvdimm/ this round to add cross arch compatibility to the devm_memremap_pages() interface, enhance numa information for persistent memory ranges, and add a zero_page_range() dax operation. This cycle I switched from the patchwork api to Konstantin's b4 script for collecting tags (from x86, PowerPC, filesystem, and device-mapper folks), and everything looks to have gone ok there. This has all appeared in -next with no reported issues. Summary: - Add support for region alignment configuration and enforcement to fix compatibility across architectures and PowerPC page size configurations. - Introduce 'zero_page_range' as a dax operation. This facilitates filesystem-dax operation without a block-device. - Introduce phys_to_target_node() to facilitate drivers that want to know resulting numa node if a given reserved address range was onlined. - Advertise a persistence-domain for of_pmem and papr_scm. The persistence domain indicates where cpu-store cycles need to reach in the platform-memory subsystem before the platform will consider them power-fail protected. - Promote numa_map_to_online_node() to a cross-kernel generic facility. - Save x86 numa information to allow for node-id lookups for reserved memory ranges, deploy that capability for the e820-pmem driver. - Pick up some miscellaneous minor fixes, that missed v5.6-final, including a some smatch reports in the ioctl path and some unit test compilation fixups. - Fixup some flexible-array declarations" * tag 'libnvdimm-for-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (29 commits) dax: Move mandatory ->zero_page_range() check in alloc_dax() dax,iomap: Add helper dax_iomap_zero() to zero a range dax: Use new dax zero page method for zeroing a page dm,dax: Add dax zero_page_range operation s390,dcssblk,dax: Add dax zero_page_range operation to dcssblk driver dax, pmem: Add a dax operation zero_page_range pmem: Add functions for reading/writing page to/from pmem libnvdimm: Update persistence domain value for of_pmem and papr_scm device tools/test/nvdimm: Fix out of tree build libnvdimm/region: Fix build error libnvdimm/region: Replace zero-length array with flexible-array member libnvdimm/label: Replace zero-length array with flexible-array member ACPI: NFIT: Replace zero-length array with flexible-array member libnvdimm/region: Introduce an 'align' attribute libnvdimm/region: Introduce NDD_LABELING libnvdimm/namespace: Enforce memremap_compat_align() libnvdimm/pfn: Prevent raw mode fallback if pfn-infoblock valid libnvdimm: Out of bounds read in __nd_ioctl() acpi/nfit: improve bounds checking for 'func' mm/memremap_pages: Introduce memremap_compat_align() ...

s390/cio: generate delayed uevent for vfio-ccw subchannels

2020-04-06T12:02:28Z

The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The vfio-ccw I/O subchannel driver, however, did not do that, and will not generate an ADD uevent for subchannels that had not been bound to a different driver (or none at all, which also triggers the uevent). Generate the ADD uevent at the end of the probe function if uevents were still suppressed for the device. Message-Id: <20200327124503.9794-3-cohuck@redhat.com> Fixes: 63f1934d562d ("vfio: ccw: basic implementation for vfio_ccw driver") Reviewed-by: Eric Farman Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik

s390/cio: avoid duplicated 'ADD' uevents

2020-04-06T12:02:28Z

The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The io_subchannel driver will do so when the associated ccw_device has been registered -- but unconditionally, so more ADD uevents will be generated if a subchannel has been unbound from the io_subchannel driver and later rebound. To fix this, only generate the ADD event if uevents were still suppressed for the device. Fixes: fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels") Message-Id: <20200327124503.9794-2-cohuck@redhat.com> Reported-by: Boris Fiuczynski Reviewed-by: Peter Oberparleiter Reviewed-by: Boris Fiuczynski Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik

s390/qdio: clear DSCI early for polling drivers

2020-04-06T11:13:51Z

Polling drivers in a configuration with 1 Input Queue currently keep their DSCI armed all the way through the poll cycle, until qdio_start_irq() clears it. _Any_ intermittent QDIO interrupt delivered to tiqdio_thinint_handler() will thus cause 1) the 'adapter_int' statistic to be incremented, 2) a call to tiqdio_call_inq_handlers() for this device, and then 3) the 'int_discarded' statistics to be incremented. This causes overhead & complexity in the IRQ path, along with ambiguity in the statistics. On the other hand the device should be in IRQ avoidance mode during a poll cycle, so there won't be a lot of DSCI ping-pong that this micro-optimization could prevent. So align the DSCI handling with what we already do for devices with multiple Input Queues: clear it right away while processing the IRQ. For the non-polling path this means that we no longer need to handle the 1-queue case separately. Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik

s390/qdio: inline shared_ind()

2020-04-06T11:13:50Z

This is just prep work for a subsequent patch, no functional change. For the non-polling path we can pull the code chunk in front of the for-loop, since it only evaluates to true for a 1-queue configuration. Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik

s390/qdio: remove cdev from init_data

2020-04-06T11:13:50Z

It's no longer needed. Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik

s390/qdio: allow for non-contiguous SBAL array in init_data

2020-04-06T11:13:50Z

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 Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik

zfcp: inline zfcp_qdio_setup_init_data()

2020-04-06T11:13:50Z

In preparation for a subsequent patch, move the setup of init_data into the only caller. Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik