summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-15PCI/ATS: Cache PRI Capability offsetKuppuswamy Sathyanarayanan
Previously each PRI interface searched for the PRI Capability. Cache the capability offset the first time we use it instead of searching each time. [bhelgaas: commit log, reorder patch to later, call pci_pri_init() from pci_init_capabilities()] Link: https://lore.kernel.org/r/0c5495d376faf6dbb8eb2165204c474438aaae65.156 7029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-5-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-10-15PCI/ATS: Disable PF/VF ATS service independentlyKuppuswamy Sathyanarayanan
Previously we didn't disable the PF ATS until all associated VFs had disabled it. But per PCIe spec r5.0, sec 9.3.7.8, the ATS Capability in VFs and associated PFs may be enabled independently. Leaving ATS enabled in the PF unnecessarily may have power and performance impacts. Remove this dependency logic in the ATS enable/disable code. [bhelgaas: commit log] Suggested-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/8163ab8fa66afd2cba514ae95d29ab12104781aa.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-4-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com>
2019-10-15PCI/ATS: Handle sharing of PF PASID Capability with all VFsKuppuswamy Sathyanarayanan
Per PCIe r5.0, sec 9.3.7.14, if a PF implements the PASID Capability, the PF PASID configuration is shared by its VFs. VFs must not implement their own PASID Capability. Since VFs don't have a PASID Capability, pci_enable_pasid() always failed, which caused IOMMU setup to fail. Update the PASID interfaces so for VFs they reflect the state of the PF PASID. [bhelgaas: rebase without pasid_cap caching, commit log] Suggested-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/8ba1ac192e4ac737508b6ac15002158e176bab91.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-3-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com>
2019-10-15PCI/ATS: Handle sharing of PF PRI Capability with all VFsKuppuswamy Sathyanarayanan
Per PCIe r5.0, sec 9.3.7.11, VFs must not implement the PRI Capability. If the PF implements PRI, it is shared by the VFs. Since VFs don't have a PRI Capability, pci_enable_pri() always failed, which caused IOMMU setup to fail. Update the PRI interfaces so for VFs they reflect the state of the PF PRI. [bhelgaas: rebase without pri_cap caching, commit log] Suggested-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/b971e31f8695980da8e4a7f93e3b6a3edba3edaa.1567029860.git.sathyanarayanan.kuppuswamy@linux.intel.com Link: https://lore.kernel.org/r/20190905193146.90250-2-helgaas@kernel.org Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com>
2019-10-15PCI/ATS: Move pci_prg_resp_pasid_required() to CONFIG_PCI_PRIBjorn Helgaas
pci_prg_resp_pasid_required() returns the value of the "PRG Response PASID Required" bit from the PRI capability, but the interface was previously defined under #ifdef CONFIG_PCI_PASID. Move it from CONFIG_PCI_PASID to CONFIG_PCI_PRI so it's with the other PRI-related things. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2019-10-15iommu/vt-d: Select PCI_PRI for INTEL_IOMMU_SVMBjorn Helgaas
Previously intel-iommu.c depended on CONFIG_AMD_IOMMU in an undesirable way. When CONFIG_INTEL_IOMMU_SVM=y, iommu_enable_dev_iotlb() calls PRI interfaces (pci_reset_pri() and pci_enable_pri()), but those are only implemented when CONFIG_PCI_PRI is enabled. The INTEL_IOMMU_SVM Kconfig did nothing with PCI_PRI, but AMD_IOMMU selects PCI_PRI. So if AMD_IOMMU was enabled, intel-iommu.c got the full PRI interfaces, but if AMD_IOMMU was not enabled, it got the PRI stubs. Make the iommu_enable_dev_iotlb() behavior independent of AMD_IOMMU by having INTEL_IOMMU_SVM select PCI_PRI so iommu_enable_dev_iotlb() always uses the full implementations of PRI interfaces. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Joerg Roedel <jroedel@suse.de> Acked-by: Joerg Roedel <jroedel@suse.de>
2019-10-15xtensa: virt: fix PCI IO ports mappingMax Filippov
virt device tree incorrectly uses 0xf0000000 on both sides of PCI IO ports address space mapping. This results in incorrect port address assignment in PCI IO BARs and subsequent crash on attempt to access them. Use 0 as base address in PCI IO ports address space. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2019-10-15PCI/ASPM: Add pcie_aspm_get_link()Heiner Kallweit
Factor out getting the link associated with a pci_dev and use this helper where appropriate. In addition this helper will be used in a subsequent patch of this series. Link: https://lore.kernel.org/r/19d33770-29de-a9af-4d85-f2b30269d383@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-10-15libata/ahci: Fix PCS quirk applicationDan Williams
Commit c312ef176399 "libata/ahci: Drop PCS quirk for Denverton and beyond" got the polarity wrong on the check for which board-ids should have the quirk applied. The board type board_ahci_pcs7 is defined at the end of the list such that "pcs7" boards can be special cased in the future if they need the quirk. All prior Intel board ids "< board_ahci_pcs7" should proceed with applying the quirk. Reported-by: Andreas Friedrich <afrie@gmx.net> Reported-by: Stephen Douthit <stephend@silicom-usa.com> Fixes: c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-15PCI/ASPM: Allow re-enabling Clock PMHeiner Kallweit
Previously Clock PM could not be re-enabled after being disabled by pci_disable_link_state() because clkpm_capable was reset. Change this by adding a clkpm_disable field similar to aspm_disable. Link: https://lore.kernel.org/r/4e8a66db-7d53-4a66-c26c-f0037ffaa705@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-10-15PCI/ASPM: Add L1 PM substate support to pci_disable_link_state()Heiner Kallweit
Add support for disabling states L1.1 and L1.2 to pci_disable_link_state(). Allow separate control of ASPM and PCI PM L1 substates. Link: https://lore.kernel.org/r/d81f8036-c236-6463-48e7-ebcdcda85bba@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-10-15PCI/ASPM: Remove pcie_aspm_enabled() unnecessary lockingBjorn Helgaas
The lifetime of the link_state structure (bridge->link_state) is not the same as the lifetime of "bridge" itself. The link_state is allocated by pcie_aspm_init_link_state() after children of the bridge have been enumerated, and it is deallocated by pcie_aspm_exit_link_state() after all children of the bridge (but not the bridge itself) have been removed. Previously pcie_aspm_enabled() acquired aspm_lock to ensure that link_state was not deallocated while we're looking at it. But the fact that the caller of pcie_aspm_enabled() holds a reference to @pdev means there's always at least one child of the bridge, which means link_state can't be deallocated. Remove the unnecessary locking in pcie_aspm_enabled(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-15Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Five changes, two in drivers (qla2xxx, zfcp), one to MAINTAINERS (qla2xxx) and two in the core. The last two are mostly about removing incorrect messages from the kernel log: the resid message is definitely wrong and the sync cache on protected drive problem is arguably wrong" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: MAINTAINERS: Update qla2xxx driver scsi: zfcp: fix reaction on bit error threshold notification scsi: core: save/restore command resid for error handling scsi: qla2xxx: Remove WARN_ON_ONCE in qla2x00_status_cont_entry() scsi: sd: Ignore a failure to sync cache due to lack of authorization
2019-10-15net: ethernet: broadcom: have drivers select DIMLIB as neededRandy Dunlap
NET_VENDOR_BROADCOM is intended to control a kconfig menu only. It should not have anything to do with code generation. As such, it should not select DIMLIB for all drivers under NET_VENDOR_BROADCOM. Instead each driver that needs DIMLIB should select it (being the symbols SYSTEMPORT, BNXT, and BCMGENET). Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907021810220.13058@ramsan.of.borg/ Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Tal Gilboa <talgi@mellanox.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Leon Romanovsky <leonro@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Sagi Grimberg <sagi@grimberg.me> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-15net: Update address for vrf and l3mdev in MAINTAINERSDavid Ahern
Use my kernel.org address for all entries in MAINTAINERS. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-15net: bcmgenet: Set phydev->dev_flags only for internal PHYsFlorian Fainelli
phydev->dev_flags is entirely dependent on the PHY device driver which is going to be used, setting the internal GENET PHY revision in those bits only makes sense when drivers/net/phy/bcm7xxx.c is the PHY driver being used. Fixes: 487320c54143 ("net: bcmgenet: communicate integrated PHY revision to PHY driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-15blackhole_netdev: fix syzkaller reported issueMahesh Bandewar
While invalidating the dst, we assign backhole_netdev instead of loopback device. However, this device does not have idev pointer and hence no ip6_ptr even if IPv6 is enabled. Possibly this has triggered the syzbot reported crash. The syzbot report does not have reproducer, however, this is the only device that doesn't have matching idev created. Crash instruction is : static inline bool ip6_ignore_linkdown(const struct net_device *dev) { const struct inet6_dev *idev = __in6_dev_get(dev); return !!idev->cnf.ignore_routes_with_linkdown; <= crash } Also ipv6 always assumes presence of idev and never checks for it being NULL (as does the above referenced code). So adding a idev for the blackhole_netdev to avoid this class of crashes in the future. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-15sparc64: disable fast-GUP due to unexplained oopsesLinus Torvalds
HAVE_FAST_GUP enables the lockless quick page table walker for simple cases, and is a nice optimization for some random loads that can then use get_user_pages_fast() rather than the more careful page walker. However, for some unexplained reason, it seems to be subtly broken on sparc64. The breakage is only with some compiler versions and some hardware, and nobody seems to have figured out what triggers it, although there's a simple reprodicer for the problem when it does trigger. The problem was introduced with the conversion to the generic GUP code in commit 7b9afb86b632 ("sparc64: use the generic get_user_pages_fast code"), but nothing looks obviously wrong in that conversion. It may be a compiler bug that just hits us with the code reorganization. Or it may be something very specific to sparc64. This disables HAVE_FAST_GUP entirely. That makes things like futexes a bit slower, but at least they work. If we can figure out the trigger, that would be lovely, but it's been three months already.. Link: https://lore.kernel.org/lkml/20190717215956.GA30369@altlinux.org/ Fixes: 7b9afb86b632 ("sparc64: use the generic get_user_pages_fast code") Reported-by: Dmitry V Levin <ldv@altlinux.org> Reported-by: Anatoly Pugachev <matorola@gmail.com> Requested-by: Meelis Roos <mroos@linux.ee> Suggested-by: Christoph Hellwig <hch@infradead.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-15Merge tag 'wireless-drivers-for-davem-2019-10-15' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 5.4 Second set of fixes for 5.4. ath10k regression and iwlwifi BAD_COMMAND bug are the ones getting most reports at the moment. ath10k * fix throughput regression on QCA98XX iwlwifi * fix initialization of 3168 devices (the infamous BAD_COMMAND bug) * other smaller fixes rt2x00 * don't include input-polldev.h header * fix hw reset to work during first 5 minutes of system run ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-15drm/panfrost: Handle resetting on timeout betterSteven Price
Panfrost uses multiple schedulers (one for each slot, so 2 in reality), and on a timeout has to stop all the schedulers to safely perform a reset. However more than one scheduler can trigger a timeout at the same time. This race condition results in jobs being freed while they are still in use. When stopping other slots use cancel_delayed_work_sync() to ensure that any timeout started for that slot has completed. Also use mutex_trylock() to obtain reset_lock. This means that only one thread attempts the reset, the other threads will simply complete without doing anything (the first thread will wait for this in the call to cancel_delayed_work_sync()). While we're here and since the function is already dependent on sched_job not being NULL, let's remove the unnecessary checks. Fixes: aa20236784ab ("drm/panfrost: Prevent concurrent resets") Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Steven Price <steven.price@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191009094456.9704-1-steven.price@arm.com
2019-10-15Merge branch 'parisc-5.4-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: - Fix a parisc-specific fallout of Christoph's dma_set_mask_and_coherent() patches (Sven) - Fix a vmap memory leak in ioremap()/ioremap() (Helge) - Some minor cleanups and documentation updates (Nick, Helge) * 'parisc-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Remove 32-bit DMA enforcement from sba_iommu parisc: Fix vmap memory leak in ioremap()/iounmap() parisc: prefer __section from compiler_attributes.h parisc: sysctl.c: Use CONFIG_PARISC instead of __hppa_ define MAINTAINERS: Add hp_sdc drivers to parisc arch
2019-10-15Merge branch 'dmi-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi fix from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi: Fix unlikely out-of-bounds read in save_mem_devices
2019-10-15blk-rq-qos: fix first node deletion of rq_qos_del()Tejun Heo
rq_qos_del() incorrectly assigns the node being deleted to the head if it was the first on the list in the !prev path. Fix it by iterating with ** instead. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Josef Bacik <josef@toxicpanda.com> Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-15blkcg: Fix multiple bugs in blkcg_activate_policy()Tejun Heo
blkcg_activate_policy() has the following bugs. * cf09a8ee19ad ("blkcg: pass @q and @blkcg into blkcg_pol_alloc_pd_fn()") added @blkcg to ->pd_alloc_fn(); however, blkcg_activate_policy() ends up using pd's allocated for the root blkcg for all preallocations, so ->pd_init_fn() for non-root blkcgs can be passed in pd's which are allocated for the root blkcg. For blk-iocost, this means that ->pd_init_fn() can write beyond the end of the allocated object as it determines the length of the flex array at the end based on the blkcg's nesting level. * Each pd is initialized as they get allocated. If alloc fails, the policy will get freed with pd's initialized on it. * After the above partial failure, the partial pds are not freed. This patch fixes all the above issues by * Restructuring blkcg_activate_policy() so that alloc and init passes are separate. Init takes place only after all allocs succeeded and on failure all allocated pds are freed. * Unifying and fixing the cleanup of the remaining pd_prealloc. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: cf09a8ee19ad ("blkcg: pass @q and @blkcg into blkcg_pol_alloc_pd_fn()") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-15xfs: change the seconds fields in xfs_bulkstat to signedDarrick J. Wong
64-bit time is a signed quantity in the kernel, so the bulkstat structure should reflect that. Note that the structure size stays the same and that we have not yet published userspace headers for this new ioctl so there are no users to break. Fixes: 7035f9724f84 ("xfs: introduce new v5 bulkstat structure") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-10-15rbd: cancel lock_dwork if the wait is interruptedDongsheng Yang
There is a warning message in my test with below steps: # rbd bench --io-type write --io-size 4K --io-threads 1 --io-pattern rand test & # sleep 5 # pkill -9 rbd # rbd map test & # sleep 5 # pkill rbd The reason is that the rbd_add_acquire_lock() is interruptable, that means, when we kill the waiting on ->acquire_wait, the lock_dwork could be still running. 1. do_rbd_add() 2. lock_dwork rbd_add_acquire_lock() - queue_delayed_work() lock_dwork queued - wait_for_completion_killable_timeout() <-- kill happen rbd_dev_image_unlock() <-- UNLOCKED now, nothing to do. rbd_dev_device_release() rbd_dev_image_release() - ... lock successed here - cancel_delayed_work_sync(&rbd_dev->lock_dwork) Then when we reach the rbd_dev_free(), WARN_ON is triggered because lock_state is not RBD_LOCK_STATE_UNLOCKED. To fix it, this commit make sure the lock_dwork was finished before calling rbd_dev_image_unlock(). On the other hand, this would not happend in do_rbd_remove(), because after rbd mapped, lock_dwork will only be queued for IO request, and request will continue unless lock_dwork finished. when we call rbd_dev_image_unlock() in do_rbd_remove(), all requests are done. That means, lock_state should not be locked again after rbd_dev_image_unlock(). [ Cancel lock_dwork in rbd_add_acquire_lock(), only if the wait is interrupted. ] Fixes: 637cd060537d ("rbd: new exclusive lock wait/wake code") Signed-off-by: Dongsheng Yang <dongsheng.yang@easystack.cn> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-10-15ceph: just skip unrecognized info in ceph_reply_info_extraJeff Layton
In the future, we're going to want to extend the ceph_reply_info_extra for create replies. Currently though, the kernel code doesn't accept an extra blob that is larger than the expected data. Change the code to skip over any unrecognized fields at the end of the extra blob, rather than returning -EIO. Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-10-15PCI: dwc: Fix find_next_bit() usageNiklas Cassel
find_next_bit() takes a parameter of size long, and performs arithmetic that assumes that the argument is of size long. Therefore we cannot pass a u32, since this will cause find_next_bit() to read outside the stack buffer and will produce the following print: BUG: KASAN: stack-out-of-bounds in find_next_bit+0x38/0xb0 Fixes: 1b497e6493c4 ("PCI: dwc: Fix uninitialized variable in dw_handle_msi_irq()") Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2019-10-15PCI: mobiveil: Fix csr_read()/write() build issueKefeng Wang
RISCV has csr_read()/write() macros in arch/riscv/include/asm/csr.h. The same function naming is used in the PCI mobiveil driver thus causing build error. Rename csr_[read,write][l,] to mobiveil_csr_read()/write() to fix it. drivers/pci/controller/pcie-mobiveil.c:238:69: error: macro "csr_read" passed 3 arguments, but takes just 1 static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size) drivers/pci/controller/pcie-mobiveil.c:253:80: error: macro "csr_write" passed 4 arguments, but takes just 2 static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t size) Fixes: bcbe0d9a8d93 ("PCI: mobiveil: Unify register accessors") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Minghuan Lian <Minghuan.Lian@nxp.com> Cc: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Cc: Andrew Murray <andrew.murray@arm.com>
2019-10-15io_uring: consider the overflow of sequence for timeout reqyangerkun
Now we recalculate the sequence of timeout with 'req->sequence = ctx->cached_sq_head + count - 1', judge the right place to insert for timeout_list by compare the number of request we still expected for completion. But we have not consider about the situation of overflow: 1. ctx->cached_sq_head + count - 1 may overflow. And a bigger count for the new timeout req can have a small req->sequence. 2. cached_sq_head of now may overflow compare with before req. And it will lead the timeout req with small req->sequence. This overflow will lead to the misorder of timeout_list, which can lead to the wrong order of the completion of timeout_list. Fix it by reuse req->submit.sequence to store the count, and change the logic of inserting sort in io_timeout. Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-10-15PCI: endpoint: Cast the page number to phys_addr_tAlan Mikhak
Modify pci_epc_mem_alloc_addr() to cast the variable 'pageno' from type 'int' to 'phys_addr_t' before shifting left. This cast is needed to avoid treating bit 31 of 'pageno' as the sign bit which would otherwise get sign-extended to produce a negative value. When added to the base address of PCI memory space, the negative value would produce an invalid physical address which falls before the start of the PCI memory space. Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-10-15scripts: setlocalversion: fix a bashismRandy Dunlap
Fix bashism reported by checkbashisms by using only one '=': possible bashism in scripts/setlocalversion line 96 (should be 'b = a'): if [ "`hg log -r . --template '{latesttagdistance}'`" == "1" ]; then Fixes: 38b3439d84f4 ("setlocalversion: update mercurial tag parsing") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mike Crowe <mcrowe@zipitwireless.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-15kbuild: update comment about KBUILD_ALLDIRSMasahiro Yamada
Commit 000ec95fbe75 ("kbuild: pkg: rename scripts/package/Makefile to scripts/Makefile.package") missed to update this comment. Fixes: 000ec95fbe75 ("kbuild: pkg: rename scripts/package/Makefile to scripts/Makefile.package") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-15arm64: dts: khadas-vim3: add commented support for PCIeNeil Armstrong
The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between an USB3.0 Type A connector and a M.2 Key M slot. The PHY driving these differential lines is shared between the USB3.0 controller and the PCIe Controller, thus only a single controller can use it. The needed DT configuration when the MCU is configured to mux the PCIe/USB3.0 differential lines to the M.2 Key M slot is added commented and may be uncommented to disable USB3.0 from the USB Complex and enable the PCIe controller. The End User is not expected to uncomment the following except for testing purposes, but instead rely on the firmware/bootloader to update these nodes accordingly if PCIe mode is selected by the MCU. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15arm64: dts: meson-g12a: Add PCIe nodeNeil Armstrong
This adds the Amlogic G12A PCI Express controller node, also using the USB3+PCIe Combo PHY. The PHY mode selection is static, thus the USB3+PCIe Combo PHY phandle would need to be removed from the USB control node if the shared differential lines are used for PCIe instead of USB3. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15phy: meson-g12a-usb3-pcie: Add support for PCIe modeNeil Armstrong
This adds extended PCIe PHY functions for the Amlogic G12A USB3+PCIE Combo PHY to support reset, power_on and power_off for PCIe exclusively. With these callbacks, we can handle all the needed operations of the Amlogic PCIe controller driver. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15PCI: amlogic: meson: Add support for G12ANeil Armstrong
Add support for the Amlogic G12A SoC using a separate shared PHY. This adds support for fetching a PHY phandle and call the PHY init, reset and power on/off calls instead of writing in the PHY register or toggling the PHY reset line. The MIPI clock and the PHY memory resource are only required for the Amlogic AXG SoC PCIe PHY setup, thus these elements are ignored for the Amlogic G12A having a separate shared PHY. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15PCI: amlogic: Fix probed clock namesNeil Armstrong
Fix the clock names used in the probe function according to the bindings. Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15dt-bindings: pci: amlogic, meson-pcie: Add G12A bindingsNeil Armstrong
Add PCIE bindings for the Amlogic G12A SoC, the support is the same but the PHY is shared with USB3 to control the differential lines. Thus this adds a phy phandle to control the PHY, and only requires the MIPI clock for the Amlogic AXG SoC Family. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-10-15PCI: amlogic: Fix reset assertion via gpio descriptorRemi Pommarel
Normally asserting reset signal on gpio would be achieved with: gpiod_set_value_cansleep(reset_gpio, 1); Meson PCI driver set reset value to '0' instead of '1' as it takes into account the PERST# signal polarity. The polarity should be taken care in the device tree instead. This fixes the reset assertion meaning and moves out the polarity configuration in DT (please note that there is no DT currently using this driver). Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-15nvme-tcp: fix possible leakage during error flowMax Gurtovoy
During nvme_tcp_setup_cmd_pdu error flow, one must call nvme_cleanup_cmd since it's symmetric to nvme_setup_cmd. Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2019-10-15nvmet-loop: fix possible leakage during error flowMax Gurtovoy
During nvme_loop_queue_rq error flow, one must call nvme_cleanup_cmd since it's symmetric to nvme_setup_cmd. Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2019-10-15iommu/amd: Fix incorrect PASID decoding from event logSuthikulpanit, Suravee
IOMMU Event Log encodes 20-bit PASID for events: ILLEGAL_DEV_TABLE_ENTRY IO_PAGE_FAULT PAGE_TAB_HARDWARE_ERROR INVALID_DEVICE_REQUEST as: PASID[15:0] = bit 47:32 PASID[19:16] = bit 19:16 Note that INVALID_PPR_REQUEST event has different encoding from the rest of the events as the following: PASID[15:0] = bit 31:16 PASID[19:16] = bit 45:42 So, fixes the decoding logic. Fixes: d64c0486ed50 ("iommu/amd: Update the PASID information printed to the system log") Cc: Joerg Roedel <jroedel@suse.de> Cc: Gary R Hook <gary.hook@amd.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-15PCI: aardvark: Don't rely on jiffies while holding spinlockRemi Pommarel
advk_pcie_wait_pio() can be called while holding a spinlock (from pci_bus_read_config_dword()), then depends on jiffies in order to timeout while polling on PIO state registers. In the case the PIO transaction failed, the timeout will never happen and will also cause the cpu to stall. This decrements a variable and wait instead of using jiffies. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-15iommu/ipmmu-vmsa: Only call platform_get_irq() when interrupt is mandatoryGeert Uytterhoeven
As platform_get_irq() now prints an error when the interrupt does not exist, calling it gratuitously causes scary messages like: ipmmu-vmsa e6740000.mmu: IRQ index 0 not found Fix this by moving the call to platform_get_irq() down, where the existence of the interrupt is mandatory. Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-15iommu/rockchip: Don't use platform_get_irq to implicitly count irqsHeiko Stuebner
Till now the Rockchip iommu driver walked through the irq list via platform_get_irq() until it encountered an ENXIO error. With the recent change to add a central error message, this always results in such an error for each iommu on probe and shutdown. To not confuse people, switch to platform_count_irqs() to get the actual number of interrupts before walking through them. Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-15PCI: aardvark: Fix PCI_EXP_RTCTL register configurationRemi Pommarel
PCI_EXP_RTCTL is used to activate PME interrupt only, so writing into it should not modify other interrupts' mask. The ISR mask polarity was also inverted, when PCI_EXP_RTCTL_PMEIE is set PCIE_MSG_PM_PME_MASK mask bit should actually be cleared. Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-15PCI: aardvark: Wait for endpoint to be ready before training linkRemi Pommarel
When configuring pcie reset pin from gpio (e.g. initially set by u-boot) to pcie function this pin goes low for a brief moment asserting the PERST# signal. Thus connected device enters fundamental reset process and link configuration can only begin after a minimal 100ms delay (see [1]). Because the pin configuration comes from the "default" pinctrl it is implicitly configured before the probe callback is called: driver_probe_device() really_probe() ... pinctrl_bind_pins() /* Here pin goes from gpio to PCIE reset function and PERST# is asserted */ ... drv->probe() [1] "PCI Express Base Specification", REV. 4.0 PCI Express, February 19 2014, 6.6.1 Conventional Reset Signed-off-by: Remi Pommarel <repk@triplefau.lt> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-15x86/apic/x2apic: Fix a NULL pointer deref when handling a dying cpuSean Christopherson
Check that the per-cpu cluster mask pointer has been set prior to clearing a dying cpu's bit. The per-cpu pointer is not set until the target cpu reaches smp_callin() during CPUHP_BRINGUP_CPU, whereas the teardown function, x2apic_dead_cpu(), is associated with the earlier CPUHP_X2APIC_PREPARE. If an error occurs before the cpu is awakened, e.g. if do_boot_cpu() itself fails, x2apic_dead_cpu() will dereference the NULL pointer and cause a panic. smpboot: do_boot_cpu failed(-22) to wakeup CPU#1 BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:x2apic_dead_cpu+0x1a/0x30 Call Trace: cpuhp_invoke_callback+0x9a/0x580 _cpu_up+0x10d/0x140 do_cpu_up+0x69/0xb0 smp_init+0x63/0xa9 kernel_init_freeable+0xd7/0x229 ? rest_init+0xa0/0xa0 kernel_init+0xa/0x100 ret_from_fork+0x35/0x40 Fixes: 023a611748fd5 ("x86/apic/x2apic: Simplify cluster management") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20191001205019.5789-1-sean.j.christopherson@intel.com
2019-10-15x86/hyperv: Make vapic support x2apic modeRoman Kagan
Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode when supported by the vcpus. However, the apic access functions for Hyper-V enlightened apic assume xapic mode only. As a result, Linux fails to bring up secondary cpus when run as a guest in QEMU/KVM with both hv_apic and x2apic enabled. According to Michael Kelley, when in x2apic mode, the Hyper-V synthetic apic MSRs behave exactly the same as the corresponding architectural x2apic MSRs, so there's no need to override the apic accessors. The only exception is hv_apic_eoi_write, which benefits from lazy EOI when available; however, its implementation works for both xapic and x2apic modes. Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver") Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access") Suggested-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20191010123258.16919-1-rkagan@virtuozzo.com