summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-04-23netfs: Make a netfs helper moduleDavid Howells
Make a netfs helper module to manage read request segmentation, caching support and transparent huge page support on behalf of a network filesystem. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-and-tested-by: Jeff Layton <jlayton@redhat.com> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> cc: Matthew Wilcox <willy@infradead.org> cc: linux-mm@kvack.org cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: linux-nfs@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/160588496284.3465195.10102643717770106661.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161118135638.1232039.1622182202673126285.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161161031028.2537118.1213974428943508753.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161340391427.1303470.14884950716721956560.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/161539531569.286939.18317119181653706665.stgit@warthog.procyon.org.uk/ # v4 Link: https://lore.kernel.org/r/161653790328.2770958.6710423217716151549.stgit@warthog.procyon.org.uk/ # v5 Link: https://lore.kernel.org/r/161789071202.6155.16519256513958534906.stgit@warthog.procyon.org.uk/ # v6
2021-04-23mm: Implement readahead_control pageset expansionDavid Howells
Provide a function, readahead_expand(), that expands the set of pages specified by a readahead_control object to encompass a revised area with a proposed size and length. The proposed area must include all of the old area and may be expanded yet more by this function so that the edges align on (transparent huge) page boundaries as allocated. The expansion will be cut short if a page already exists in either of the areas being expanded into. Note that any expansion made in such a case is not rolled back. This will be used by fscache so that reads can be expanded to cache granule boundaries, thereby allowing whole granules to be stored in the cache, but there are other potential users also. Changes: v6: - Fold in a patch from Matthew Wilcox to tell the ondemand readahead algorithm about the expansion so that the next readahead starts at the right place[2]. v4: - Moved the declaration of readahead_expand() to a better place[1]. Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Tested-by: Jeff Layton <jlayton@kernel.org> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> cc: Alexander Viro <viro@zeniv.linux.org.uk> cc: Christoph Hellwig <hch@lst.de> cc: Mike Marshall <hubcap@omnibond.com> cc: linux-mm@kvack.org cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: linux-nfs@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20210217161358.GM2858050@casper.infradead.org/ [1] Link: https://lore.kernel.org/r/20210407201857.3582797-4-willy@infradead.org/ [2] Link: https://lore.kernel.org/r/159974633888.2094769.8326206446358128373.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/160588479816.3465195.553952688795241765.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161118131787.1232039.4863969952441067985.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161161028670.2537118.13831420617039766044.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161340389201.1303470.14353807284546854878.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/161539530488.286939.18085961677838089157.stgit@warthog.procyon.org.uk/ # v4 Link: https://lore.kernel.org/r/161653789422.2770958.2108046612147345000.stgit@warthog.procyon.org.uk/ # v5 Link: https://lore.kernel.org/r/161789069829.6155.4295672417565512161.stgit@warthog.procyon.org.uk/ # v6
2021-04-23mm/readahead: Handle ractl nr_pages being modifiedMatthew Wilcox (Oracle)
Filesystems are not currently permitted to modify the number of pages in the ractl. An upcoming patch to add readahead_expand() changes that rule, so remove the check and resync the loop counter after every call to the filesystem. Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20210420200116.3715790-1-willy@infradead.org/ Link: https://lore.kernel.org/r/20210421170923.4005574-1-willy@infradead.org/ # v2
2021-04-23fs: Document file_ra_stateMatthew Wilcox (Oracle)
Turn the comments into kernel-doc and improve the wording slightly. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Jeff Layton <jlayton@kernel.org> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> Link: https://lore.kernel.org/r/20210407201857.3582797-3-willy@infradead.org/ Link: https://lore.kernel.org/r/161789068619.6155.1397999970593531574.stgit@warthog.procyon.org.uk/ # v6
2021-04-23mm/filemap: Pass the file_ra_state in the ractlMatthew Wilcox (Oracle)
For readahead_expand(), we need to modify the file ra_state, so pass it down by adding it to the ractl. We have to do this because it's not always the same as f_ra in the struct file that is already being passed. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Jeff Layton <jlayton@kernel.org> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> Link: https://lore.kernel.org/r/20210407201857.3582797-2-willy@infradead.org/ Link: https://lore.kernel.org/r/161789067431.6155.8063840447229665720.stgit@warthog.procyon.org.uk/ # v6
2021-04-23mm: Add set/end/wait functions for PG_private_2David Howells
Add three functions to manipulate PG_private_2: (*) set_page_private_2() - Set the flag and take an appropriate reference on the flagged page. (*) end_page_private_2() - Clear the flag, drop the reference and wake up any waiters, somewhat analogously with end_page_writeback(). (*) wait_on_page_private_2() - Wait for the flag to be cleared. Wrappers will need to be placed in the netfs lib header in the patch that adds that. [This implements a suggestion by Linus[1] to not mix the terminology of PG_private_2 and PG_fscache in the mm core function] Changes: v7: - Use compound_head() in all the functions to make them THP safe[6]. v5: - Add set and end functions, calling the end function end rather than unlock[3]. - Keep a ref on the page when PG_private_2 is set[4][5]. v4: - Remove extern from the declaration[2]. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Tested-by: Jeff Layton <jlayton@kernel.org> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> cc: Alexander Viro <viro@zeniv.linux.org.uk> cc: Christoph Hellwig <hch@lst.de> cc: linux-mm@kvack.org cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: linux-nfs@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/1330473.1612974547@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/CAHk-=wjgA-74ddehziVk=XAEMTKswPu1Yw4uaro1R3ibs27ztw@mail.gmail.com/ [1] Link: https://lore.kernel.org/r/20210216102659.GA27714@lst.de/ [2] Link: https://lore.kernel.org/r/161340387944.1303470.7944159520278177652.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/161539528910.286939.1252328699383291173.stgit@warthog.procyon.org.uk # v4 Link: https://lore.kernel.org/r/20210321105309.GG3420@casper.infradead.org [3] Link: https://lore.kernel.org/r/CAHk-=wh+2gbF7XEjYc=HV9w_2uVzVf7vs60BPz0gFA=+pUm3ww@mail.gmail.com/ [4] Link: https://lore.kernel.org/r/CAHk-=wjSGsRj7xwhSMQ6dAQiz53xA39pOG+XA_WeTgwBBu4uqg@mail.gmail.com/ [5] Link: https://lore.kernel.org/r/20210408145057.GN2531743@casper.infradead.org/ [6] Link: https://lore.kernel.org/r/161653788200.2770958.9517755716374927208.stgit@warthog.procyon.org.uk/ # v5 Link: https://lore.kernel.org/r/161789066013.6155.9816857201817288382.stgit@warthog.procyon.org.uk/ # v6
2021-04-23iov_iter: Add ITER_XARRAYDavid Howells
Add an iterator, ITER_XARRAY, that walks through a set of pages attached to an xarray, starting at a given page and offset and walking for the specified amount of bytes. The iterator supports transparent huge pages. The iterate_xarray() macro calls the helper function with rcu_access() helped. I think that this is only a problem for iov_iter_for_each_range() - and that returns an error for ITER_XARRAY (also, this function does not appear to be called). The caller must guarantee that the pages are all present and they must be locked using PG_locked, PG_writeback or PG_fscache to prevent them from going away or being migrated whilst they're being accessed. This is useful for copying data from socket buffers to inodes in network filesystems and for transferring data between those inodes and the cache using direct I/O. Whilst it is true that ITER_BVEC could be used instead, that would require a bio_vec array to be allocated to refer to all the pages - which should be redundant if inode->i_pages also points to all these pages. Note that older versions of this patch implemented an ITER_MAPPING instead, which was almost the same. Changes: v7: - Rename iter_xarray_copy_pages() to iter_xarray_populate_pages()[1]. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-and-tested-by: Jeff Layton <jlayton@kernel.org> Tested-by: Dave Wysochanski <dwysocha@redhat.com> Tested-By: Marc Dionne <marc.dionne@auristor.com> cc: Alexander Viro <viro@zeniv.linux.org.uk> cc: Matthew Wilcox (Oracle) <willy@infradead.org> cc: Christoph Hellwig <hch@lst.de> cc: linux-mm@kvack.org cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: linux-nfs@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/3577430.1579705075@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/158861205740.340223.16592990225607814022.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/159465785214.1376674.6062549291411362531.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/160588477334.3465195.3608963255682568730.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161118129703.1232039.17141248432017826976.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/161161026313.2537118.14676007075365418649.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161340386671.1303470.10752208972482479840.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/161539527815.286939.14607323792547049341.stgit@warthog.procyon.org.uk/ # v4 Link: https://lore.kernel.org/r/161653786033.2770958.14154191921867463240.stgit@warthog.procyon.org.uk/ # v5 Link: https://lore.kernel.org/r/161789064740.6155.11932541175173658065.stgit@warthog.procyon.org.uk/ # v6 Link: https://lore.kernel.org/r/27c369a8f42bb8a617672b2dc0126a5c6df5a050.camel@kernel.org [1]
2021-04-23xen-pciback: simplify vpci's find hookJan Beulich
There's no point in comparing SBDF - we can simply compare the struct pci_dev pointers. If they weren't the same for a given device, we'd have bigger problems from having stored a stale pointer. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/158273a2-d1b9-3545-b25d-affca867376c@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-04-23xen-blkfront: Fix 'physical' typosBjorn Helgaas
Fix misspelling of "physical". Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20210126205509.2917606-1-helgaas@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com>
2021-04-23xen-blkback: fix compatibility bug with single page ringsPaul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the behaviour of xen-blkback when connecting to a frontend was: - read 'ring-page-order' - if not present then expect a single page ring specified by 'ring-ref' - else expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order This was correct behaviour, but was broken by the afforementioned commit to become: - read 'ring-page-order' - if not present then expect a single page ring (i.e. ring-page-order = 0) - expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order - if that didn't work then see if there's a single page ring specified by 'ring-ref' This incorrect behaviour works most of the time but fails when a frontend that sets 'ring-page-order' is unloaded and replaced by one that does not because, instead of reading 'ring-ref', xen-blkback will read the stale 'ring-ref0' left around by the previous frontend will try to map the wrong grant reference. This patch restores the original behaviour. Fixes: 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront") Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: "Roger Pau Monné" <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20210202175659.18452-1-paul@xen.org Signed-off-by: Juergen Gross <jgross@suse.com>
2021-04-23xen: Remove support for PV ACPI cpu/memory hotplugBoris Ostrovsky
Commit 76fc253723ad ("xen/acpi-stub: Disable it b/c the acpi_processor_add is no longer called.") declared as BROKEN support for Xen ACPI stub (which is required for xen-acpi-{cpu|memory}-hotplug) and suggested that this is temporary and will be soon fixed. This was in March 2013. Further, commit cfafae940381 ("xen: rename dom0_op to platform_op") renamed an interface used by memory hotplug code without updating that code (as it was BROKEN and therefore not compiled). This was in November 2015 and has gone unnoticed for over 5 year. It is now clear that this code is of no interest to anyone and therefore should be removed. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1618336344-3162-1-git-send-email-boris.ostrovsky@oracle.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-04-23xen/pciback: Fix incorrect type warningsMuhammad Usama Anjum
Correct enum pci_channel_io_normal should be used instead of putting integer value 1. Fix following smatch warnings: drivers/xen/xen-pciback/pci_stub.c:805:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:805:40: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:805:40: got int drivers/xen/xen-pciback/pci_stub.c:862:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:862:40: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:862:40: got int drivers/xen/xen-pciback/pci_stub.c:973:31: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:973:31: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:973:31: got int Signed-off-by: Muhammad Usama Anjum <musamaanjum@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210326181442.GA1735905@LEGION Signed-off-by: Juergen Gross <jgross@suse.com>
2021-04-23Merge tag 'drm-intel-fixes-2021-04-22' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - GVT's BDW regression fix for cmd parser (Zhenyu) - Fix modesetting in case of unexpected AUX timeouts (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YIGZ3pQPgPQtZtyI@intel.com
2021-04-23Merge tag 'amd-drm-fixes-5.12-2021-04-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.12-2021-04-21: amdgpu: - Fix gpuvm page table update issue - Modifier fixes - Register fix for dimgrey cavefish Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421220456.3839-1-alexander.deucher@amd.com
2021-04-22Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull virtio fixes from Michael Tsirkin: "Very late in the cycle but both risky if left unfixed and more or less obvious.." * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vdpa/mlx5: Set err = -ENOMEM in case dma_map_sg_attrs fails vhost-vdpa: protect concurrent access to vhost device iotlb
2021-04-22vdpa/mlx5: Set err = -ENOMEM in case dma_map_sg_attrs failsEli Cohen
Set err = -ENOMEM if dma_map_sg_attrs() fails so the function reutrns error. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Eli Cohen <elic@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210411083646.910546-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2021-04-22vhost-vdpa: protect concurrent access to vhost device iotlbXie Yongji
Protect vhost device iotlb by vhost_dev->mutex. Otherwise, it might cause corruption of the list and interval tree in struct vhost_iotlb if userspace sends the VHOST_IOTLB_MSG_V2 message concurrently. Fixes: 4c8cf318("vhost: introduce vDPA-based backend") Cc: stable@vger.kernel.org Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20210412095512.178-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-04-22dt-bindings: mali-bifrost: add dma-coherentKevin Hilman
Add optional dma-coherent property to binding doc. Found by 'make dtbs_check' on arm64/amlogic DT files. Signed-off-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210421204833.18523-2-khilman@baylibre.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-04-22arm64: dts: amlogic: misc DT schema fixupsKevin Hilman
Take a pass at cleaning up a bunch of warnings from 'make dtbs_check' that have crept in. Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210421204833.18523-1-khilman@baylibre.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-04-22Merge tag 'sunxi-fixes-for-5.12-2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes One fix for the MMC card detect on the Pine H64 board * tag 'sunxi-fixes-for-5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS Link: https://lore.kernel.org/r/45fc5e4d-ef48-4729-a869-79a8f288bb83.lettre@localhost Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-04-22Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmddLinus Torvalds
Pull tpm fix from James Bottomley: "This is an urgent regression fix for a tpm patch set that went in this merge window. It looks like a rebase before the original pull request lost a tpm_try_get_ops() so we have a lock imbalance in our code which is causing oopses. The original patch was correct on the mailing list. I'm sending this in agreement with Mimi (as joint maintainers of trusted keys) because Jarkko is off communing with the Reindeer or whatever it is Finns do when on holiday" * tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmdd: KEYS: trusted: Fix TPM reservation for seal/unseal
2021-04-22spi: stm32-qspi: fix debug format stringArnd Bergmann
Printing size_t needs a special %zx format modifier to avoid a warning like: drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here 481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf); Patrice already tried to fix this, but picked %lx instead of %zx, which fixed some architectures but broke others in the same way. Using %zx works everywhere. Fixes: 18674dee3cd6 ("spi: stm32-qspi: Add dirmap support") Fixes: 1b8a7d4282c0 ("spi: stm32-qspi: Fix compilation warning in ARM64") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210422134955.1988316-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-22spi: tools: make a symbolic link to the header file spi.hQuanyang Wang
The header file spi.h in include/uapi/linux/spi is needed for spidev.h, so we also need make a symbolic link to it to eliminate the error message as below: In file included from spidev_test.c:24: include/linux/spi/spidev.h:28:10: fatal error: linux/spi/spi.h: No such file or directory 28 | #include <linux/spi/spi.h> | ^~~~~~~~~~~~~~~~~ compilation terminated. Fixes: f7005142dace ("spi: uapi: unify SPI modes into a single spi.h") Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Link: https://lore.kernel.org/r/20210422102604.3034217-1-quanyang.wang@windriver.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-22regulator: core: Respect off_on_delay at startupVincent Whitchurch
We currently do not respect off_on_delay the first time we turn on a regulator. This is problematic since the regulator could have been turned off by the bootloader, or it could it have been turned off during the probe of the regulator driver (such as when regulator-fixed requests the enable GPIO), either of which could potentially have happened less than off_on_delay microseconds ago before the first time a client requests for the regulator to be turned on. We can't know exactly when the regulator was turned off, but initialise off_on_delay to the current time when registering the regulator, so that we guarantee that we respect the off_on_delay in all cases. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210422083044.11479-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-22dt-bindings: interrupt-controller: Add IDT 79RC3243x Interrupt ControllerThomas Bogendoerfer
Document DT bindings for IDT 79RC3243x Interrupt Controller. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210422145330.73452-2-tsbogend@alpha.franken.de
2021-04-22irqchip: Add support for IDT 79rc3243x interrupt controllerThomas Bogendoerfer
IDT 79rc3243x SoCs have rather simple interrupt controllers connected to the MIPS CPU interrupt lines. Each of them has room for up to 32 interrupts. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210422145330.73452-1-tsbogend@alpha.franken.de
2021-04-22irqdomain: Drop references to recusive irqdomain setupMarc Zyngier
It was never completely implemented, and was removed a long time ago. Adjust the documentation to reflect this. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210406093557.1073423-8-maz@kernel.org
2021-04-22irqdomain: Get rid of irq_create_strict_mappings()Marc Zyngier
No user of this helper is left, remove it. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-04-22irqchip/jcore-aic: Kill use of irq_create_strict_mappings()Marc Zyngier
irq_create_strict_mappings() is a poor way to allow the use of a linear IRQ domain as a legacy one. Let's be upfront about it. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210406093557.1073423-4-maz@kernel.org
2021-04-22ARM: PXA: Kill use of irq_create_strict_mappings()Marc Zyngier
irq_create_strict_mappings() is a poor way to allow the use of a linear IRQ domain as a legacy one. Let's be upfront about it and use a legacy domain when appropriate. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210406093557.1073423-3-maz@kernel.org
2021-04-22irqchip/gic-v4.1: Disable vSGI upon (GIC CPUIF < v4.1) detectionLorenzo Pieralisi
GIC CPU interfaces versions predating GIC v4.1 were not built to accommodate vINTID within the vSGI range; as reported in the GIC specifications (8.2 "Changes to the CPU interface"), it is CONSTRAINED UNPREDICTABLE to deliver a vSGI to a PE with ID_AA64PFR0_EL1.GIC < b0011. Check the GIC CPUIF version by reading the SYS_ID_AA64_PFR0_EL1. Disable vSGIs if a CPUIF version < 4.1 is detected to prevent using vSGIs on systems where they may misbehave. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210317100719.3331-2-lorenzo.pieralisi@arm.com
2021-04-22PM: wakeup: remove redundant assignment to variable retvalColin Ian King
The variable retval is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-04-22irqchip/tb10x: Use 'fallthrough' to eliminate a warningRandy Dunlap
Use the 'fallthrough' macro to document that this switch case does indeed fall through to the next case. ../drivers/irqchip/irq-tb10x.c: In function 'tb10x_irq_set_type': ../drivers/irqchip/irq-tb10x.c:62:13: warning: this statement may fall through [-Wimplicit-fallthrough=] 62 | flow_type = IRQ_TYPE_LEVEL_LOW; ../drivers/irqchip/irq-tb10x.c:63:2: note: here 63 | case IRQ_TYPE_LEVEL_LOW: | ^~~~ Fixes: b06eb0173ef1 ("irqchip: Add TB10x interrupt controller driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210422051620.23021-1-rdunlap@infradead.org
2021-04-22perf/x86/kvm: Fix Broadwell Xeon stepping in isolation_ucodes[]Jim Mattson
The only stepping of Broadwell Xeon parts is stepping 1. Fix the relevant isolation_ucodes[] entry, which previously enumerated stepping 2. Although the original commit was characterized as an optimization, it is also a workaround for a correctness issue. If a PMI arrives between kvm's call to perf_guest_get_msrs() and the subsequent VM-entry, a stale value for the IA32_PEBS_ENABLE MSR may be restored at the next VM-exit. This is because, unbeknownst to kvm, PMI throttling may clear bits in the IA32_PEBS_ENABLE MSR. CPUs with "PEBS isolation" don't suffer from this issue, because perf_guest_get_msrs() doesn't report the IA32_PEBS_ENABLE value. Fixes: 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering") Signed-off-by: Jim Mattson <jmattson@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Peter Shier <pshier@google.com> Acked-by: Andi Kleen <ak@linux.intel.com> Link: https://lkml.kernel.org/r/20210422001834.1748319-1-jmattson@google.com
2021-04-22usb: gadget: prevent a ternary sign expansion bugDan Carpenter
The problem is that "req->actual" is a u32, "req->status" is an int, and iocb->ki_complete() takes a long. We would expect that a negative error code in "req->status" would translate to a negative long value. But what actually happens is that because "req->actual" is a u32, the error codes is type promoted to a high positive value and then remains a positive value when it is cast to long. (No sign expansion). We can fix this by casting "req->status" to long. Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YIE7RrBPLWc3XtMg@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: extend compile-test coverageJohan Hovold
Allow more drivers to be compile tested more easily, for example, when doing subsystem-wide changes. Verified on X86_64 as well as arm, powerpc and m68k with minimal configs in order to catch missing implicit build dependencies (e.g. MAILBOX for SERIAL_TEGRA_TCU). Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210422080211.29326-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: stm32: add FIFO threshold configurationFabrice Gasnier
Add the support for two optional DT properties, to configure RX and TX FIFO thresholds: - rx-threshold - tx-threshold This replaces hard-coded 8 bytes threshold. Keep 8 as the default value if not specified, for backward compatibility. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Changes in v2: Change added properties naming as proposed by Rob Herring. Link: https://lore.kernel.org/r/20210413174015.23011-5-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22dt-bindings: serial: 8250: update TX FIFO trigger levelErwan Le Ray
Remove data type from tx-threshold trigger level as defined now as a serial generic property. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Link: https://lore.kernel.org/r/20210413174015.23011-4-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22dt-bindings: serial: stm32: override FIFO threshold propertiesErwan Le Ray
Override rx-threshold and tx-threshold properties: - extend description - provide default and expected values Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Changes in v2: Change added properties naming and factorize it in serial.yaml as proposed by Rob Herring. Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210413174015.23011-3-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22dt-bindings: serial: add RX and TX FIFO propertiesErwan Le Ray
Add two optional DT properties to configure RX and TX FIFO thresholds: - rx-threshold - tx-threshold Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Link: https://lore.kernel.org/r/20210413174015.23011-2-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: xilinx_uartps: drop low-latency workaroundJohan Hovold
Commit c8dbdc842d30 ("serial: xuartps: Rewrite the interrupt handling logic") reworked the driver interrupt processing but also, without comment, added an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which had been removed years before. Specifically, since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-27-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: vt8500: drop low-latency workaroundJohan Hovold
Commit de49df58366f ("tty: serial: vt8500: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tony Prisk <linux@prisktech.co.nz> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-26-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: timbuart: drop low-latency workaroundJohan Hovold
The timbuart driver has always carried a workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which required not holding the port lock when the low_latency flag was set. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-25-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: sunsu: drop low-latency workaroundJohan Hovold
The sunsu driver has been carrying a workaround for the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock in the interrupt handler since 2004. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: "David S. Miller" <davem@davemloft.net> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-24-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: sifive: drop low-latency workaroundJohan Hovold
The sifive driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which had been removed years before the driver was added by commit 45c054d0815b ("tty: serial: add driver for the SiFive UART"). Specifically, since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-23-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: txx9: drop low-latency workaroundJohan Hovold
Commit f5ee56cc184e ("[PATCH] txx9 serial update") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-22-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: sa1100: drop low-latency workaroundJohan Hovold
Commit 53e0e6706c76 ("tty: serial: sa1100: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-21-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: rp2: drop low-latency workaroundJohan Hovold
Commit de7053c77123 ("tty: serial: rp2: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-20-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: rda: drop low-latency workaroundJohan Hovold
The rda driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit c10b13325ced ("tty: serial: Add RDA8810PL UART driver"). Specifically, since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-19-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-22serial: owl: drop low-latency workaroundJohan Hovold
The owl driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit fc60a8b675bd ("tty: serial: owl: Implement console driver"). Specifically, since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-18-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-11 21:47:51 +0000