summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtaskStefan Assmann2019-10-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a7542b87607560d0b89e7ff81d870bd6ff8835cb upstream. While testing VF spawn/destroy the following panic occurred. BUG: unable to handle kernel NULL pointer dereference at 0000000000000029 [...] Workqueue: i40e i40e_service_task [i40e] RIP: 0010:i40e_sync_vsi_filters+0x6fd/0xc60 [i40e] [...] Call Trace: ? __switch_to_asm+0x35/0x70 ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x35/0x70 ? _cond_resched+0x15/0x30 i40e_sync_filters_subtask+0x56/0x70 [i40e] i40e_service_task+0x382/0x11b0 [i40e] ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x41/0x70 process_one_work+0x1a7/0x3b0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_bind+0x30/0x30 ret_from_fork+0x35/0x40 Investigation revealed a race where pf->vf[vsi->vf_id].trusted may get accessed by the watchdog via i40e_sync_filters_subtask() although i40e_free_vfs() already free'd pf->vf. To avoid this the call to i40e_sync_vsi_filters() in i40e_sync_filters_subtask() needs to be guarded by __I40E_VF_DISABLE, which is also used by i40e_free_vfs(). Note: put the __I40E_VF_DISABLE check after the __I40E_MACVLAN_SYNC_PENDING check as the latter is more likely to trigger. CC: stable@vger.kernel.org Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ath10k: fix channel info parsing for non tlv targetRakesh Pillai2019-10-053-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6be6c04bcc2e8770b8637632789ff15765124894 upstream. The tlv targets such as WCN3990 send more data in the chan info event, which is not sent by the non tlv targets. There is a minimum size check in the wmi event for non-tlv targets and hence we cannot update the common channel info structure as it was done in commit 13104929d2ec ("ath10k: fill the channel survey results for WCN3990 correctly"). This broke channel survey results on 10.x firmware versions. If the common channel info structure is updated, the size check for chan info event for non-tlv targets will fail and return -EPROTO and we see the below error messages ath10k_pci 0000:01:00.0: failed to parse chan info event: -71 Add tlv specific channel info structure and restore the original size of the common channel info structure to mitigate this issue. Tested HW: WCN3990 QCA9887 Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1 10.2.4-1.0-00037 Fixes: 13104929d2ec ("ath10k: fill the channel survey results for WCN3990 correctly") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* rtw88: pci: Use DMA sync instead of remapping in RX ISRJian-Hong Pan2019-10-051-3/+21
| | | | | | | | | | | | | commit 29b68a920f6abb7b5ba21ab4b779f62d536bac9b upstream. Since each skb in RX ring is reused instead of new allocation, we can treat the DMA in a more efficient way by DMA synchronization. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* rtw88: pci: Rearrange the memory usage for skb in RX ISRJian-Hong Pan2019-10-051-27/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ee6db78f5db9bfe426c57a1ec9713827ebccd2d4 upstream. Testing with RTL8822BE hardware, when available memory is low, we frequently see a kernel panic and system freeze. First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed): rx routine starvation WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] Then we see a variety of different error conditions and kernel panics, such as this one (trimmed): rtw_pci 0000:02:00.0: pci bus timeout, check dma status skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:105! invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:skb_panic+0x43/0x45 When skb allocation fails and the "rx routine starvation" is hit, the function returns immediately without updating the RX ring. At this point, the RX ring may continue referencing an old skb which was already handed off to ieee80211_rx_irqsafe(). When it comes to be used again, bad things happen. This patch allocates a new, data-sized skb first in RX ISR. After copying the data in, we pass it to the upper layers. However, if skb allocation fails, we effectively drop the frame. In both cases, the original, full size ring skb is reused. In addition, to fixing the kernel crash, the RX routine should now generally behave better under low memory conditions. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* KEYS: trusted: correctly initialize digests and fix locking issueRoberto Sassu2019-10-051-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | commit 9f75c82246313d4c2a6bc77e947b45655b3b5ad5 upstream. Commit 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()") modifies tpm_pcr_extend() to accept a digest for each PCR bank. After modification, tpm_pcr_extend() expects that digests are passed in the same order as the algorithms set in chip->allocated_banks. This patch fixes two issues introduced in the last iterations of the patch set: missing initialization of the TPM algorithm ID in the tpm_digest structures passed to tpm_pcr_extend() by the trusted key module, and unreleased locks in the TPM driver due to returning from tpm_pcr_extend() without calling tpm_put_ops(). Cc: stable@vger.kernel.org Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mt76: round up length on mt76_wr_copyFelix Fietkau2019-10-052-2/+2
| | | | | | | | | | | | | | | commit 850e8f6fbd5d0003b0f1119d19a01c6fef1644e2 upstream. When beacon length is not a multiple of 4, the beacon could be sent with the last 1-3 bytes corrupted. The skb data is guaranteed to have enough room for reading beyond the end, because it is always followed by skb_shared_info, so rounding up is safe. All other callers of mt76_wr_copy have multiple-of-4 length already. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efifb: BGRT: Improve efifb_bgrt_sanity_checkHans de Goede2019-10-051-21/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 51677dfcc17f88ed754143df670ff064eae67f84 upstream. For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: Defer init completion for a while after late_initcallMark Brown2019-10-051-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 55576cf1853798e86f620766e23b604c9224c19c upstream. The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu/vt-d: Fix wrong analysis whether devices share the same busNadav Amit2019-10-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2c70010867f164d1b30e787e360e05d10cc40046 upstream. set_msi_sid_cb() is used to determine whether device aliases share the same bus, but it can provide false indications that aliases use the same bus when in fact they do not. The reason is that set_msi_sid_cb() assumes that pdev is fixed, while actually pci_for_each_dma_alias() can call fn() when pdev is set to a subordinate device. As a result, running an VM on ESX with VT-d emulation enabled can results in the log warning such as: DMAR: [INTR-REMAP] Request device [00:11.0] fault index 3b [fault reason 38] Blocked an interrupt request due to source-id verification failure This seems to cause additional ata errors such as: ata3.00: qc timeout (cmd 0xa1) ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) These timeouts also cause boot to be much longer and other errors. Fix it by checking comparing the alias with the previous one instead. Fixes: 3f0c625c6ae71 ("iommu/vt-d: Allow interrupts from the entire bus for aliased devices") Cc: stable@vger.kernel.org Cc: Logan Gunthorpe <logang@deltatee.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Nadav Amit <namit@vmware.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu/arm-smmu-v3: Disable detection of ATS and PRIWill Deacon2019-10-051-0/+2
| | | | | | | | | | | | | | | | | | | | | commit b5e86196b83fd68e065a7c811ab8925fb0dc3893 upstream. Detecting the ATS capability of the SMMU at probe time introduces a spinlock into the ->unmap() fast path, even when ATS is not actually in use. Furthermore, the ATC invalidation that exists is broken, as it occurs before invalidation of the main SMMU TLB which leaves a window where the ATC can be repopulated with stale entries. Given that ATS is both a new feature and a specialist sport, disable it for now whilst we fix it properly in subsequent patches. Since PRI requires ATS, disable that too. Cc: <stable@vger.kernel.org> Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging: erofs: cannot set EROFS_V_Z_INITED_BIT if fill_inode_lazy failsGao Xiang2019-10-051-2/+1
| | | | | | | | | | | | | | | | | commit 3407a4198faf01c9d7596c45b8606834b8dfc2b7 upstream. As reported by erofs-utils fuzzer, unsupported compressed clustersize will make fill_inode_lazy fail, for such case we cannot set EROFS_V_Z_INITED_BIT since we need return failure for each z_erofs_map_blocks_iter(). Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support") Cc: <stable@vger.kernel.org> # 5.3+ Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Reviewed-by: Chao Yu <yuchao0@huawei.com> Link: https://lore.kernel.org/r/20190819103426.87579-3-gaoxiang25@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not oursVladimir Oltean2019-10-051-1/+3
| | | | | | | | | | | | | | | | | commit d41f36a6464a85c06ad920703d878e4491d2c023 upstream. The DSPI interrupt can be shared between two controllers at least on the LX2160A. In that case, the driver for one controller might misbehave and consume the other's interrupt. Fix this by actually checking if any of the bits in the status register have been asserted. Fixes: 13aed2392741 ("spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20190822212450.21420-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* media: vivid: fix device init when no_error_inj=1 and fb disabledGuillaume Tucker2019-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 79e85d1d2c16ba4907bb9d6a4381516b729ff341 upstream. Add an extra condition to add the video output control class when the device has some hdmi outputs defined. This is required to then always be able to add the display present control, which is enabled when there are some hdmi outputs. This fixes the corner case where no_error_inj is enabled and the device has no frame buffer but some hdmi outputs, as otherwise the video output control class would be added anyway. Without this fix, the sanity checks fail in v4l2_ctrl_new() as name is NULL. Fixes: c533435ffb91 ("media: vivid: add display present control") Cc: stable@vger.kernel.org # for 5.3 Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* media: don't drop front-end reference count for ->detachArnd Bergmann2019-10-052-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 14e3cdbb00a885eedc95c0cf8eda8fe28d26d6b4 upstream. A bugfix introduce a link failure in configurations without CONFIG_MODULES: In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0: drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach': drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition The problem is that the !IS_REACHABLE() declaration of stb0899_attach() is a 'static inline' definition that clashes with the weak definition. I further observed that the bugfix was only done for one of the five users of stb0899_attach(), the other four still have the problem. This reverts the bugfix and instead addresses the problem by not dropping the reference count when calling '->detach()', instead we call this function directly in dvb_frontend_put() before dropping the kref on the front-end. I first submitted this in early 2018, and after some discussion it was apparently discarded. While there is a long-term plan in place, that plan is obviously not nearing completion yet, and the current kernel is still broken unless this patch is applied. Link: https://patchwork.kernel.org/patch/10140175/ Link: https://patchwork.linuxtv.org/patch/54831/ Cc: Max Kellermann <max.kellermann@gmail.com> Cc: Wolfgang Rohdewald <wolfgang@rohdewald.de> Cc: stable@vger.kernel.org Fixes: f686c14364ad ("[media] stb0899: move code to "detach" callback") Fixes: 6cdeaed3b142 ("media: dvb_usb_pctv452e: module refcount changes were unbalanced") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* media: hantro: Set DMA max segment sizeFrancois Buergisser2019-10-051-0/+1
| | | | | | | | | | | | | | | | | commit c3c3509b86810293df5c524ef61421d8affc8bf0 upstream. The Hantro codec is typically used in platforms with an IOMMU, so we need to set a proper DMA segment size. Devices without an IOMMU will still fallback to default 64KiB segments. Cc: stable@vger.kernel.org Fixes: 775fec69008d3 ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Francois Buergisser <fbuergisser@chromium.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* media: sn9c20x: Add MSI MS-1039 laptop to flip_dmi_tableHans de Goede2019-10-051-0/+7
| | | | | | | | | | | | | | | | | commit 7e0bb5828311f811309bed5749528ca04992af2f upstream. Like a bunch of other MSI laptops the MS-1039 uses a 0c45:627b SN9C201 + OV7660 webcam which is mounted upside down. Add it to the sn9c20x flip_dmi_table to deal with this. Cc: stable@vger.kernel.org Reported-by: Rui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* media: videobuf-core.c: poll_wait needs a non-NULL buf pointerHans Verkuil2019-10-051-2/+3
| | | | | | | | | | | | | | | | commit 6f51fdfd8229d5358c2d6e272cf73478866e8ddc upstream. poll_wait uses &buf->done, but buf is NULL. Move the poll_wait to later in the function once buf is correctly set and only call it if it is non-NULL. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: bb436cbeb918 ("media: videobuf: fix epoll() by calling poll_wait first") Cc: <stable@vger.kernel.org> # for v5.1 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* platform/x86: intel_int0002_vgpio: Fix wakeups not working on Cherry TrailHans de Goede2019-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | commit 1bd43d0077b9a32a8b8059036471f3fc82dae342 upstream. Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") removed the irq_set_wake method from the struct irq_chip used on Cherry Trail, but it did not set IRQCHIP_SKIP_SET_WAKE causing kernel/irq/manage.c: set_irq_wake_real() to return -ENXIO. This causes the kernel to no longer see PME events reported through the INT0002 device as wakeup events. Which e.g. breaks wakeup by the (USB) keyboard on many Cherry Trail 2-in-1 devices. Cc: stable@vger.kernel.org Fixes: 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* parisc: Disable HP HSC-PCI Cards to prevent kernel crashHelge Deller2019-10-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | commit 5fa1659105fac63e0f3c199b476025c2e04111ce upstream. The HP Dino PCI controller chip can be used in two variants: as on-board controller (e.g. in B160L), or on an Add-On card ("Card-Mode") to bridge PCI components to systems without a PCI bus, e.g. to a HSC/GSC bus. One such Add-On card is the HP HSC-PCI Card which has one or more DEC Tulip PCI NIC chips connected to the on-card Dino PCI controller. Dino in Card-Mode has a big disadvantage: All PCI memory accesses need to go through the DINO_MEM_DATA register, so Linux drivers will not be able to use the ioremap() function. Without ioremap() many drivers will not work, one example is the tulip driver which then simply crashes the kernel if it tries to access the ports on the HP HSC card. This patch disables the HP HSC card if it finds one, and as such fixes the kernel crash on a HP D350/2 machine. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: Phil Scarr <phil.scarr@pm.me> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tpm: Wrap the buffer from the caller to tpm_buf in tpm_send()Jarkko Sakkinen2019-10-051-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e13cd21ffd50a07b55dcc4d8c38cedf27f28eaa1 upstream. tpm_send() does not give anymore the result back to the caller. This would require another memcpy(), which kind of tells that the whole approach is somewhat broken. Instead, as Mimi suggested, this commit just wraps the data to the tpm_buf, and thus the result will not go to the garbage. Obviously this assumes from the caller that it passes large enough buffer, which makes the whole API somewhat broken because it could be different size than @buflen but since trusted keys is the only module using this API right now I think that this fix is sufficient for the moment. In the near future the plan is to replace the parameters with a tpm_buf created by the caller. Reported-by: Mimi Zohar <zohar@linux.ibm.com> Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Cc: stable@vger.kernel.org Fixes: 412eb585587a ("use tpm_buf in tpm_transmit_cmd() as the IO parameter") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interruptsStefan Berger2019-10-051-0/+1
| | | | | | | | | | | | | | | commit 1ea32c83c699df32689d329b2415796b7bfc2f6e upstream. The tpm_tis_core has to set the TPM_CHIP_FLAG_IRQ before probing for interrupts since there is no other place in the code that would set it. Cc: linux-stable@vger.kernel.org Fixes: 570a36097f30 ("tpm: drop 'irq' from struct tpm_vendor_specific") Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tpm_tis_core: Turn on the TPM before probing IRQ'sStefan Berger2019-10-051-0/+2
| | | | | | | | | | | | | | | | commit 5b359c7c43727e624eac3efc7ad21bd2defea161 upstream. The interrupt probing sequence in tpm_tis_core cannot obviously run with the TPM power gated. Power on the TPM with tpm_chip_start() before probing IRQ's. Turn it off once the probing is complete. Cc: linux-stable@vger.kernel.org Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scsi: implement .cleanup_rq callbackMing Lei2019-10-051-0/+13
| | | | | | | | | | | | | | | | | | | | [ Upstream commit b7e9e1fb7a9227be34ad4a5e778022c3164494cf ] Implement .cleanup_rq() callback for freeing driver private part of the request. Then we can avoid to leak this part if the request isn't completed by SCSI, and freed by blk-mq or upper layer(such as dm-rq) finally. Cc: Ewan D. Milne <emilne@redhat.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Snitzer <snitzer@redhat.com> Cc: dm-devel@redhat.com Cc: <stable@vger.kernel.org> Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback") Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
* blk-mq: add callback of .cleanup_rqMing Lei2019-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 226b4fc75c78f9c497c5182d939101b260cfb9f3 ] SCSI maintains its own driver private data hooked off of each SCSI request, and the pridate data won't be freed after scsi_queue_rq() returns BLK_STS_RESOURCE or BLK_STS_DEV_RESOURCE. An upper layer driver (e.g. dm-rq) may need to retry these SCSI requests, before SCSI has fully dispatched them, due to a lower level SCSI driver's resource limitation identified in scsi_queue_rq(). Currently SCSI's per-request private data is leaked when the upper layer driver (dm-rq) frees and then retries these requests in response to BLK_STS_RESOURCE or BLK_STS_DEV_RESOURCE returns from scsi_queue_rq(). This usecase is so specialized that it doesn't warrant training an existing blk-mq interface (e.g. blk_mq_free_request) to allow SCSI to account for freeing its driver private data -- doing so would add an extra branch for handling a special case that all other consumers of SCSI (and blk-mq) won't ever need to worry about. So the most pragmatic way forward is to delegate freeing SCSI driver private data to the upper layer driver (dm-rq). Do so by adding new .cleanup_rq callback and calling a new blk_mq_cleanup_rq() method from dm-rq. A following commit will implement the .cleanup_rq() hook in scsi_mq_ops. Cc: Ewan D. Milne <emilne@redhat.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Snitzer <snitzer@redhat.com> Cc: dm-devel@redhat.com Cc: <stable@vger.kernel.org> Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback") Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
* RDMA: Fix double-free in srq creation error flowJack Morgenstein2019-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | commit 3eca7fc2d8d1275d9cf0c709f0937becbfcf6d96 upstream. The cited commit introduced a double-free of the srq buffer in the error flow of procedure __uverbs_create_xsrq(). The problem is that ib_destroy_srq_user() called in the error flow also frees the srq buffer. Thus, if uverbs_response() fails in __uverbs_create_srq(), the srq buffer will be freed twice. Cc: <stable@vger.kernel.org> Fixes: 68e326dea1db ("RDMA: Handle SRQ allocations by IB/core") Link: https://lore.kernel.org/r/20190916071154.20383-5-leon@kernel.org Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* IB/hfi1: Do not update hcrc for a KDETH packet during fault injectionKaike Wan2019-10-051-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | commit b2590bdd0b1dfb91737e6cb07ebb47bd74957f7e upstream. When a KDETH packet is subject to fault injection during transmission, HCRC is supposed to be omitted from the packet so that the hardware on the receiver side would drop the packet. When creating pbc, the PbcInsertHcrc field is set to be PBC_IHCRC_NONE if the KDETH packet is subject to fault injection, but overwritten with PBC_IHCRC_LKDETH when update_hcrc() is called later. This problem is fixed by not calling update_hcrc() when the packet is subject to fault injection. Fixes: 6b6cf9357f78 ("IB/hfi1: Set PbcInsertHcrc for TID RDMA packets") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190715164546.74174.99296.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* IB/hfi1: Define variables as unsigned long to fix KASAN warningIra Weiny2019-10-051-26/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f8659d68e2bee5b86a1beaf7be42d942e1fc81f4 upstream. Define the working variables to be unsigned long to be compatible with for_each_set_bit and change types as needed. While we are at it remove unused variables from a couple of functions. This was found because of the following KASAN warning: ================================================================== BUG: KASAN: stack-out-of-bounds in find_first_bit+0x19/0x70 Read of size 8 at addr ffff888362d778d0 by task kworker/u308:2/1889 CPU: 21 PID: 1889 Comm: kworker/u308:2 Tainted: G W 5.3.0-rc2-mm1+ #2 Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.02.04.0003.102320141138 10/23/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] Call Trace: dump_stack+0x9a/0xf0 ? find_first_bit+0x19/0x70 print_address_description+0x6c/0x332 ? find_first_bit+0x19/0x70 ? find_first_bit+0x19/0x70 __kasan_report.cold.6+0x1a/0x3b ? find_first_bit+0x19/0x70 kasan_report+0xe/0x12 find_first_bit+0x19/0x70 pma_get_opa_portstatus+0x5cc/0xa80 [hfi1] ? ret_from_fork+0x3a/0x50 ? pma_get_opa_port_ectrs+0x200/0x200 [hfi1] ? stack_trace_consume_entry+0x80/0x80 hfi1_process_mad+0x39b/0x26c0 [hfi1] ? __lock_acquire+0x65e/0x21b0 ? clear_linkup_counters+0xb0/0xb0 [hfi1] ? check_chain_key+0x1d7/0x2e0 ? lock_downgrade+0x3a0/0x3a0 ? match_held_lock+0x2e/0x250 ib_mad_recv_done+0x698/0x15e0 [ib_core] ? clear_linkup_counters+0xb0/0xb0 [hfi1] ? ib_mad_send_done+0xc80/0xc80 [ib_core] ? mark_held_locks+0x79/0xa0 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? rvt_poll_cq+0x1e1/0x340 [rdmavt] __ib_process_cq+0x97/0x100 [ib_core] ib_cq_poll_work+0x31/0xb0 [ib_core] process_one_work+0x4ee/0xa00 ? pwq_dec_nr_in_flight+0x110/0x110 ? do_raw_spin_lock+0x113/0x1d0 worker_thread+0x57/0x5a0 ? process_one_work+0xa00/0xa00 kthread+0x1bb/0x1e0 ? kthread_create_on_node+0xc0/0xc0 ret_from_fork+0x3a/0x50 The buggy address belongs to the page: page:ffffea000d8b5dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 ffffea000d8b5dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888362d778d0 is located in stack of task kworker/u308:2/1889 at offset 32 in frame: pma_get_opa_portstatus+0x0/0xa80 [hfi1] this frame has 1 object: [32, 36) 'vl_select_mask' Memory state around the buggy address: ffff888362d77780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888362d77800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888362d77880: 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2 00 00 ^ ffff888362d77900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888362d77980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2 ================================================================== Cc: <stable@vger.kernel.org> Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20190911113053.126040.47327.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* IB/mlx5: Free mpi in mp_slave modeDanit Goldberg2019-10-051-0/+1
| | | | | | | | | | | | | | | | commit 5d44adebbb7e785939df3db36ac360f5e8b73e44 upstream. ib_add_slave_port() allocates a multiport struct but never frees it. Don't leak memory, free the allocated mpi struct during driver unload. Cc: <stable@vger.kernel.org> Fixes: 32f69e4be269 ("{net, IB}/mlx5: Manage port association for multiport RoCE") Link: https://lore.kernel.org/r/20190916064818.19823-3-leon@kernel.org Signed-off-by: Danit Goldberg <danitg@mellanox.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flagQuinn Tran2019-10-053-6/+21
| | | | | | | | | | | | | | | | | | commit 8b5292bcfcacf15182a77a973a98d310e76fd58b upstream. Relogin fails to move forward due to scan_state flag indicating device is not there. Before relogin process, Session delete process accidently modified the scan_state flag. [mkp: typos plus corrected Fixes: sha as reported by sfr] Fixes: 2dee5521028c ("scsi: qla2xxx: Fix login state machine freeze") Cc: stable@vger.kernel.org Signed-off-by: Quinn Tran <qutran@marvell.com> Signed-off-by: Himanshu Madhani <hmadhani@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scsi: scsi_dh_rdac: zero cdb in send_mode_select()Martin Wilck2019-10-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | commit 57adf5d4cfd3198aa480e7c94a101fc8c4e6109d upstream. cdb in send_mode_select() is not zeroed and is only partially filled in rdac_failover_get(), which leads to some random data getting to the device. Users have reported storage responding to such commands with INVALID FIELD IN CDB. Code before commit 327825574132 was not affected, as it called blk_rq_set_block_pc(). Fix this by zeroing out the cdb first. Identified & fix proposed by HPE. Fixes: 327825574132 ("scsi_dh_rdac: switch to scsi_execute_req_flags()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20190904155205.1666-1-martin.wilck@suse.com Signed-off-by: Martin Wilck <mwilck@suse.com> Acked-by: Ales Novak <alnovak@suse.cz> Reviewed-by: Shane Seymour <shane.seymour@hpe.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: fw: don't send GEO_TX_POWER_LIMIT command to FW version 36Luca Coelho2019-10-051-3/+5
| | | | | | | | | | | | | | | | | | commit fddbfeece9c7882cc47754c7da460fe427e3e85b upstream. The intention was to have the GEO_TX_POWER_LIMIT command in FW version 36 as well, but not all 8000 family got this feature enabled. The 8000 family is the only one using version 36, so skip this version entirely. If we try to send this command to the firmwares that do not support it, we get a BAD_COMMAND response from the firmware. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=204151. Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PM / devfreq: passive: fix compiler warningMyungJoo Ham2019-10-051-1/+0
| | | | | | | | | | | | [ Upstream commit 0465814831a926ce2f83e8f606d067d86745234e ] The recent commit of PM / devfreq: passive: Use non-devm notifiers had incurred compiler warning, "unused variable 'dev'". Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: omap3isp: Set device on omap3isp subdevsSakari Ailus2019-10-056-0/+7
| | | | | | | | | | | | [ Upstream commit e9eb103f027725053a4b02f93d7f2858b56747ce ] The omap3isp driver registered subdevs without the dev field being set. Do that now. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* zd1211rw: remove false assertion from zd_mac_clear()Oliver Neukum2019-10-051-1/+0
| | | | | | | | | | | | [ Upstream commit 7a2eb7367fdea72e448d1a847aa857f6caf8ea2f ] The function is called before the lock which is asserted was ever used. Just remove it. Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systemsKai-Heng Feng2019-10-054-2/+111
| | | | | | | | | | | | | | | | | [ Upstream commit 93d051550ee02eaff9a2541d825605a7bd778027 ] Raven Ridge systems may have malfunction touchpad or hang at boot if incorrect IVRS IOAPIC is provided by BIOS. Users already found correct "ivrs_ioapic=" values, let's put them inside kernel to workaround buggy BIOS. BugLink: https://bugs.launchpad.net/bugs/1795292 BugLink: https://bugs.launchpad.net/bugs/1837688 Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm: fix module name in edid_firmware log messageJani Nikula2019-10-051-1/+1
| | | | | | | | | | | | | | [ Upstream commit ade925995b172f1d7410d1c665b2f47c5e99bef0 ] The module is drm_kms_helper, not drm_kms_firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204549 Reported-by: Göran Uddeborg <goeran@uddeborg.se> Fixes: ac6c35a4d8c7 ("drm: add backwards compatibility support for drm_kms_helper.edid_firmware") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821094312.5514-1-jani.nikula@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: ttusb-dec: Fix info-leak in ttusb_dec_send_command()Tomas Bortoli2019-10-051-1/+1
| | | | | | | | | | | | | | | | [ Upstream commit a10feaf8c464c3f9cfdd3a8a7ce17e1c0d498da1 ] The function at issue does not always initialize each byte allocated for 'b' and can therefore leak uninitialized memory to a USB device in the call to usb_bulk_msg() Use kzalloc() instead of kmalloc() Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Reported-by: syzbot+0522702e9d67142379f1@syzkaller.appspotmail.com Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/powerplay/smu7: enforce minimal VBITimeout (v2)Ahzo2019-10-051-0/+5
| | | | | | | | | | | | | | [ Upstream commit f659bb6dae58c113805f92822e4c16ddd3156b79 ] This fixes screen corruption/flickering on 75 Hz displays. v2: make print statement debug only (Alex) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102646 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Ahzo <Ahzo@tutanota.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* e1000e: add workaround for possible stalled packetKai-Heng Feng2019-10-052-1/+11
| | | | | | | | | | | | | | | [ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ] This works around a possible stalled packet issue, which may occur due to clock recovery from the PCH being too slow, when the LAN is transitioning from K1 at 1G link speed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* libertas: Add missing sentinel at end of if_usb.c fw_tableKevin Easton2019-10-051-1/+2
| | | | | | | | | | | [ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ] This sentinel tells the firmware loading process when to stop. Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com Signed-off-by: Kevin Easton <kevin@guarana.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mmc: mtk-sd: Re-store SDIO IRQs mask at system resumeUlf Hansson2019-10-051-0/+3
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 1c81d69d4c98aab56c5a7d5a810f84aefdb37e9b ] In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means msdc_runtime_suspend|resume() gets called during system suspend/resume, via pm_runtime_force_suspend|resume(). This means during system suspend/resume, the register context of the mtk-sd device most likely loses its register context, even in cases when SDIO IRQs have been enabled. To re-enable the SDIO IRQs during system resume, the mtk-sd driver currently relies on the mmc core to re-enable the SDIO IRQs when it resumes the SDIO card, but this isn't the recommended solution. Instead, it's better to deal with this locally in the mtk-sd driver, so let's do that. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* raid5: don't increment read_errors on EILSEQ returnNigel Croxon2019-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit b76b4715eba0d0ed574f58918b29c1b2f0fa37a8 ] While MD continues to count read errors returned by the lower layer. If those errors are -EILSEQ, instead of -EIO, it should NOT increase the read_errors count. When RAID6 is set up on dm-integrity target that detects massive corruption, the leg will be ejected from the array. Even if the issue is correctable with a sector re-write and the array has necessary redundancy to correct it. The leg is ejected because it runs up the rdev->read_errors beyond conf->max_nr_stripes. The return status in dm-drypt when there is a data integrity error is -EILSEQ (BLK_STS_PROTECTION). Signed-off-by: Nigel Croxon <ncroxon@redhat.com> Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mmc: dw_mmc: Re-store SDIO IRQs mask at system resumeUlf Hansson2019-10-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7c526608d5afb62cbc967225e2ccaacfdd142e9d ] In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means dw_mci_runtime_suspend|resume() gets called during system suspend/resume, via pm_runtime_force_suspend|resume(). This means during system suspend/resume, the register context of the dw_mmc device most likely loses its register context, even in cases when SDIO IRQs have been enabled. To re-enable the SDIO IRQs during system resume, the dw_mmc driver currently relies on the mmc core to re-enable the SDIO IRQs when it resumes the SDIO card, but this isn't the recommended solution. Instead, it's better to deal with this locally in the dw_mmc driver, so let's do that. Tested-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mmc: sdhci: Fix incorrect switch to HS modeAl Cooper2019-10-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c894e33ddc1910e14d6f2a2016f60ab613fd8b37 ] When switching from any MMC speed mode that requires 1.8v (HS200, HS400 and HS400ES) to High Speed (HS) mode, the system ends up configured for SDR12 with a 50MHz clock which is an illegal mode. This happens because the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register is left set and when this bit is set, the speed mode is controlled by the SDHCI_CTRL_UHS field in the SDHCI_HOST_CONTROL2 register. The SDHCI_CTRL_UHS field will end up being set to 0 (SDR12) by sdhci_set_uhs_signaling() because there is no UHS mode being set. The fix is to change sdhci_set_uhs_signaling() to set the SDHCI_CTRL_UHS field to SDR25 (which is the same as HS) for any switch to HS mode. This was found on a new eMMC controller that does strict checking of the speed mode and the corresponding clock rate. It caused the switch to HS400 mode to fail because part of the sequence to switch to HS400 requires a switch from HS200 to HS before going to HS400. Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Al Cooper <alcooperx@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREADUlf Hansson2019-10-051-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 36d57efb4af534dd6b442ea0b9a04aa6dfa37abe ] The sdio_irq_pending flag is used to let host drivers indicate that it has signaled an IRQ. If that is the case and we only have a single SDIO func that have claimed an SDIO IRQ, our assumption is that we can avoid reading the SDIO_CCCR_INTx register and just call the SDIO func irq handler immediately. This makes sense, but the flag is set/cleared in a somewhat messy order, let's fix that up according to below. First, the flag is currently set in sdio_run_irqs(), which is executed as a work that was scheduled from sdio_signal_irq(). To make it more implicit that the host have signaled an IRQ, let's instead immediately set the flag in sdio_signal_irq(). This also makes the behavior consistent with host drivers that uses the legacy, mmc_signal_sdio_irq() API. This have no functional impact, because we don't expect host drivers to call sdio_signal_irq() until after the work (sdio_run_irqs()) have been executed anyways. Second, currently we never clears the flag when using the sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let make the behavior consistent, by moving the flag to be cleared inside the common process_sdio_pending_irqs() function. Additionally, tweak the behavior of the flag slightly, by avoiding to clear it unless we processed the SDIO IRQ. The purpose with this at this point, is to keep the information about whether there have been an SDIO IRQ signaled by the host, so at system resume we can decide to process it without reading the SDIO_CCCR_INTx register. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* raid5: don't set STRIPE_HANDLE to stripe which is in batch listGuoqing Jiang2019-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ] If stripe in batch list is set with STRIPE_HANDLE flag, then the stripe could be set with STRIPE_ACTIVE by the handle_stripe function. And if error happens to the batch_head at the same time, break_stripe_batch_list is called, then below warning could happen (the same report in [1]), it means a member of batch list was set with STRIPE_ACTIVE. [7028915.431770] stripe state: 2001 [7028915.431815] ------------[ cut here ]------------ [7028915.431828] WARNING: CPU: 18 PID: 29089 at drivers/md/raid5.c:4614 break_stripe_batch_list+0x203/0x240 [raid456] [...] [7028915.431879] CPU: 18 PID: 29089 Comm: kworker/u82:5 Tainted: G O 4.14.86-1-storage #4.14.86-1.2~deb9 [7028915.431881] Hardware name: Supermicro SSG-2028R-ACR24L/X10DRH-iT, BIOS 3.1 06/18/2018 [7028915.431888] Workqueue: raid5wq raid5_do_work [raid456] [7028915.431890] task: ffff9ab0ef36d7c0 task.stack: ffffb72926f84000 [7028915.431896] RIP: 0010:break_stripe_batch_list+0x203/0x240 [raid456] [7028915.431898] RSP: 0018:ffffb72926f87ba8 EFLAGS: 00010286 [7028915.431900] RAX: 0000000000000012 RBX: ffff9aaa84a98000 RCX: 0000000000000000 [7028915.431901] RDX: 0000000000000000 RSI: ffff9ab2bfa15458 RDI: ffff9ab2bfa15458 [7028915.431902] RBP: ffff9aaa8fb4e900 R08: 0000000000000001 R09: 0000000000002eb4 [7028915.431903] R10: 00000000ffffffff R11: 0000000000000000 R12: ffff9ab1736f1b00 [7028915.431904] R13: 0000000000000000 R14: ffff9aaa8fb4e900 R15: 0000000000000001 [7028915.431906] FS: 0000000000000000(0000) GS:ffff9ab2bfa00000(0000) knlGS:0000000000000000 [7028915.431907] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [7028915.431908] CR2: 00007ff953b9f5d8 CR3: 0000000bf4009002 CR4: 00000000003606e0 [7028915.431909] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [7028915.431910] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [7028915.431910] Call Trace: [7028915.431923] handle_stripe+0x8e7/0x2020 [raid456] [7028915.431930] ? __wake_up_common_lock+0x89/0xc0 [7028915.431935] handle_active_stripes.isra.58+0x35f/0x560 [raid456] [7028915.431939] raid5_do_work+0xc6/0x1f0 [raid456] Also commit 59fc630b8b5f9f ("RAID5: batch adjacent full stripe write") said "If a stripe is added to batch list, then only the first stripe of the list should be put to handle_list and run handle_stripe." So don't set STRIPE_HANDLE to stripe which is already in batch list, otherwise the stripe could be put to handle_list and run handle_stripe, then the above warning could be triggered. [1]. https://www.spinics.net/lists/raid/msg62552.html Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* spi: bcm2835: Work around DONE bit erratumLukas Wunner2019-10-051-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4c524191c0a21d758b519087c64f84348095e940 ] Commit 3bd7f6589f67 ("spi: bcm2835: Overcome sglist entry length limitation") amended the BCM2835 SPI driver with support for DMA transfers whose buffers are not aligned to 4 bytes and require more than one sglist entry. When testing this feature with upcoming commits to speed up TX-only and RX-only transfers, I noticed that SPI transmission sometimes breaks. A function introduced by the commit, bcm2835_spi_transfer_prologue(), performs one or two PIO transmissions as a prologue to the actual DMA transmission. It turns out that the breakage goes away if the DONE bit in the CS register is set when ending such a PIO transmission. The DONE bit signifies emptiness of the TX FIFO. According to the spec, the bit is of type RO, so writing it should never have any effect. Perhaps the spec is wrong and the bit is actually of type RW1C. E.g. the I2C controller on the BCM2835 does have an RW1C DONE bit which needs to be cleared by the driver. Another, possibly more likely explanation is that it's a hardware erratum since the issue does not occur consistently. Either way, amend bcm2835_spi_transfer_prologue() to always write the DONE bit. Usually a transmission is ended by bcm2835_spi_reset_hw(). If the transmission was successful, the TX FIFO is empty and thus the DONE bit is set when bcm2835_spi_reset_hw() reads the CS register. The bit is then written back to the register, so we happen to do the right thing. However if DONE is not set, e.g. because transmission is aborted with a non-empty TX FIFO, the bit won't be written by bcm2835_spi_reset_hw() and it seems possible that transmission might subsequently break. To be on the safe side, likewise amend bcm2835_spi_reset_hw() to always write the bit. Tested-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/edb004dff4af6106f6bfcb89e1a96391e96eb857.1564825752.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86: intel_pmc_core_pltdrv: Module removal warning fixM. Vefa Bicakci2019-10-051-0/+8
| | | | | | | | | | | | | | | | [ Upstream commit 0b43e41e93815ecd9616759cf5d64d3a7be8e6fb ] Prior to this commit, removing the intel_pmc_core_pltdrv module would cause the following warning: Device 'intel_pmc_core.0' does not have a release() function, it is broken and must be fixed. See Documentation/kobject.txt. WARNING: CPU: 0 PID: 2202 at drivers/base/core.c:1238 device_release+0x6f/0x80 This commit hence adds an empty release function for the driver. Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86: intel_pmc_core: Do not ioremap RAMM. Vefa Bicakci2019-10-051-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7d505758b1e556cdf65a5e451744fe0ae8063d17 ] On a Xen-based PVH virtual machine with more than 4 GiB of RAM, intel_pmc_core fails initialization with the following warning message from the kernel, indicating that the driver is attempting to ioremap RAM: ioremap on RAM at 0x00000000fe000000 - 0x00000000fe001fff WARNING: CPU: 1 PID: 434 at arch/x86/mm/ioremap.c:186 __ioremap_caller.constprop.0+0x2aa/0x2c0 ... Call Trace: ? pmc_core_probe+0x87/0x2d0 [intel_pmc_core] pmc_core_probe+0x87/0x2d0 [intel_pmc_core] This issue appears to manifest itself because of the following fallback mechanism in the driver: if (lpit_read_residency_count_address(&slp_s0_addr)) pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT; The validity of address PMC_BASE_ADDR_DEFAULT (i.e., 0xFE000000) is not verified by the driver, which is what this patch introduces. With this patch, if address PMC_BASE_ADDR_DEFAULT is in RAM, then the driver will not attempt to ioremap the aforementioned address. Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* irqchip/gic-v3-its: Fix LPI release for Multi-MSI devicesMarc Zyngier2019-10-051-5/+4
| | | | | | | | | | | | | | | | | | | | [ Upstream commit c9c96e30ecaa0aafa225aa1a5392cb7db17c7a82 ] When allocating a range of LPIs for a Multi-MSI capable device, this allocation extended to the closest power of 2. But on the release path, the interrupts are released one by one. This results in not releasing the "extra" range, leaking the its_device. Trying to reprobe the device will then fail. Fix it by releasing the LPIs the same way we allocate them. Fixes: 8208d1708b88 ("irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their size") Reported-by: Jiaxing Luo <luojiaxing@huawei.com> Tested-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/f5e948aa-e32f-3f74-ae30-31fee06c2a74@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 01:15:09 +0000