- 10 Jul, 2019 10 commits
-
-
Don Brace authored
[ Upstream commit 625d7d35 ] - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for the last s/g element. - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when chaining. Reviewed-by:
Bader Ali - Saleh <bader.alisaleh@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Reviewed-by:
Matt Perricone <matt.perricone@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alexandre Belloni authored
[ Upstream commit fbc318af ] Gadget drivers may queue request in interrupt context. This would lead to a descriptor allocation in that context. In that case we would hit BUG_ON(in_interrupt()) in __get_vm_area_node. Also remove the unnecessary cast. Acked-by:
Sylvain Lemieux <slemieux.tyco@gmail.com> Tested-by:
James Grant <jamesg@zaltys.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Young Xiao authored
[ Upstream commit 62fd0e0a ] There is no deallocation of fusb300->ep[i] elements, allocated at fusb300_probe. The patch adds deallocation of fusb300->ep array elements. Signed-off-by:
Young Xiao <92siuyang@gmail.com> Signed-off-by:
-
Hsin-Yi Wang authored
[ Upstream commit 2458d9d6 ] mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last irq, it will timeout with this message: "vblank wait timed out on crtc 0". This happens sometimes when turning off the screen. In drm_atomic_helper.c#disable_outputs(), the calling sequence when turning off the screen is: 1. mtk_dsi_encoder_disable() --> mtk_output_dsi_disable() --> mtk_dsi_stop(); /* sometimes make vblank timeout in atomic_disable */ --> mtk_dsi_poweroff(); 2. mtk_drm_crtc_atomic_disable() --> drm_crtc_wait_one_vblank(); ... --> mtk_dsi_ddp_stop() --> mtk_dsi_poweroff(); mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0. Fixes: 0707632b ("drm/mediatek: update DSI sub driver flow for sending commands to panel") Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
Hsin-Yi Wang authored
[ Upstream commit a4cd1d2b ] num_pipes is used for mutex created in mtk_drm_crtc_create(). If we don't clear num_pipes count, when rebinding driver, the count will be accumulated. From mtk_disp_mutex_get(), there can only be at most 10 mutex id. Clear this number so it starts from 0 in every rebind. Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by:
-
Hsin-Yi Wang authored
[ Upstream commit cf49b24f ] shutdown all CRTC when unbinding drm driver. Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by:
-
Hsin-Yi Wang authored
[ Upstream commit f0fd8483 ] Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind won't actually unbind components. During the next bind, mtk_drm_kms_init() is called, and the components are added back. .unbind() should call mtk_drm_kms_deinit() to unbind components. And since component_master_del() in .remove() will trigger .unbind(), which will also unregister device, it's fine to remove original functions called here. Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by:
-
Hsin-Yi Wang authored
[ Upstream commit 8fd7a37b ] detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to attach it again. Fixes: 2e54c14e ("drm/mediatek: Add DSI sub driver") Signed-off-by:
-
YueHaibing authored
[ Upstream commit 5caaf29a ] If spi_register_master fails in spi_bitbang_start because device_add failure, We should return the error code other than 0, otherwise calling spi_bitbang_stop may trigger NULL pointer dereference like this: BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0 Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661 CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: dump_stack+0xa9/0x10e ? __list_del_entry_valid+0x45/0xd0 ? __list_del_entry_valid+0x45/0xd0 __kasan_report+0x171/0x18d ? __list_del_entry_valid+0x45/0xd0 kasan_report+0xe/0x20 __list_del_entry_valid+0x45/0xd0 spi_unregister_controller+0x99/0x1b0 spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp] ? 0xffffffffc1128000 ? klist_next+0x131/0x1e0 ? driver_detach+0x40/0x40 [parport] port_check+0x3b/0x50 [parport] bus_for_each_dev+0x115/0x180 ? subsys_dev_iter_exit+0x20/0x20 __parport_register_driver+0x1f0/0x210 [parport] ? 0xffffffffc1150000 do_one_initcall+0xb9/0x3b5 ? perf_trace_initcall_level+0x270/0x270 ? kasan_unpoison_shadow+0x30/0x40 ? kasan_unpoison_shadow+0x30/0x40 do_init_module+0xe0/0x330 load_module+0x38eb/0x4270 ? module_frob_arch_sections+0x20/0x20 ? kernel_read_file+0x188/0x3f0 ? find_held_lock+0x6d/0xd0 ? fput_many+0x1a/0xe0 ? __do_sys_finit_module+0x162/0x190 __do_sys_finit_module+0x162/0x190 ? __ia32_sys_init_module+0x40/0x40 ? __mutex_unlock_slowpath+0xb4/0x3f0 ? wait_for_completion+0x240/0x240 ? vfs_write+0x160/0x2a0 ? lockdep_hardirqs_off+0xb5/0x100 ? mark_held_locks+0x1a/0x90 ? do_syscall_64+0x14/0x2a0 do_syscall_64+0x72/0x2a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 702a4879 ("spi: bitbang: Let spi_bitbang_start() take a reference to master") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Axel Lin <axel.lin@ingics.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Guilherme G. Piccoli authored
```-------------------------------------------------------------- This patch is not on mainline and is meant to 4.19 stable *only*. After the patch description there's a reasoning about that. ``` -------------------------------------------------------------- Commit cd4a4ae4 ("block: don't use blocking queue entered for recursive bio submits") introduced the flag BIO_QUEUE_ENTERED in order split bios bypass the blocking queue entering routine and use the live non-blocking version. It was a result of an extensive discussion in a linux-block thread[0], and the purpose of this change was to prevent a hung task waiting on a reference to drop. Happens that md raid0 split bios all the time, and more important, it changes their underlying device to the raid member. After the change introduced by this flag's usage, we experience various crashes if a raid0 member is removed during a large write. This happens because the bio reaches the live queue entering function when the queue of the raid0 member is dying. A simple reproducer of this behavior is presented below: a) Build kernel v4.19.56-stable with CONFIG_BLK_DEV_THROTTLING=y. b) Create a raid0 md array with 2 NVMe devices as members, and mount it with an ext4 filesystem. c) Run the following oneliner (supposing the raid0 is mounted in /mnt): (dd of=/mnt/tmp if=/dev/zero bs=1M count=999 &); sleep 0.3; echo 1 > /sys/block/nvme1n1/device/device/remove (whereas nvme1n1 is the 2nd array member) This will trigger the following warning/oops: ------------[ cut here ]------------ BUG: unable to handle kernel NULL pointer dereference at 0000000000000155 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI RIP: 0010:blk_throtl_bio+0x45/0x970 [...] Call Trace: generic_make_request_checks+0x1bf/0x690 generic_make_request+0x64/0x3f0 raid0_make_request+0x184/0x620 [raid0] ? raid0_make_request+0x184/0x620 [raid0] md_handle_request+0x126/0x1a0 md_make_request+0x7b/0x180 generic_make_request+0x19e/0x3f0 submit_bio+0x73/0x140 [...] This patch changes raid0 driver to fallback to the "old" blocking queue entering procedure, by clearing the BIO_QUEUE_ENTERED from raid0 bios. This prevents the crashes and restores the regular behavior of raid0 arrays when a member is removed during a large write. [0] lore.kernel.org/linux-block/343bbbf6-64eb-879e-d19e-96aebb037d47@I-love.SAKURA.ne.jp ---------------------------- Why this is not on mainline? ---------------------------- The patch was originally submitted upstream in linux-raid and linux-block mailing-lists - it was initially accepted by Song Liu, but Christoph Hellwig[1] observed that there was a clean-up series ready to be accepted from Ming Lei[2] that fixed the same issue. The accepted patches from Ming's series in upstream are: commit 47cdee29 ("block: move blk_exit_queue into __blk_release_queue") and commit fe200864 ("block: don't protect generic_make_request_checks with blk_queue_enter"). Those patches basically do a clean-up in the block layer involving: 1) Putting back blk_exit_queue() logic into __blk_release_queue(); that path was changed in the past and the logic from blk_exit_queue() was added to blk_cleanup_queue(). 2) Removing the guard/protection in generic_make_request_checks() with blk_queue_enter(). The problem with Ming's series for -stable is that it relies in the legacy request IO path removal. So it's "backport-able" to v5.0+, but doing that for early versions (like 4.19) would incur in complex code changes. Hence, it was suggested by Christoph and Song Liu that this patch was submitted to stable only; otherwise merging it upstream would add code to fix a path removed in a subsequent commit. [1] lore.kernel.org/linux-block/20190521172258.GA32702@infradead.org [2] lore.kernel.org/linux-block/20190515030310.20393-1-ming.lei@redhat.com Cc: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Ming Lei <ming.lei@redhat.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: cd4a4ae4 ("block: don't use blocking queue entered for recursive bio submits") Signed-off-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Jul, 2019 23 commits
-
-
Thinh Nguyen authored
commit c7152763 upstream. Currently req->num_trbs is not reset after the TRBs are skipped and processed from the cancelled list. The gadget driver may reuse the request with an invalid req->num_trbs, and DWC3 will incorrectly skip trbs. To fix this, simply reset req->num_trbs to 0 after skipping through all of them. Fixes: c3acd590 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()") Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
-
Jason Gunthorpe authored
commit 641114d2 upstream. gcc 9 now does allocation size tracking and thinks that passing the member of a union and then accessing beyond that member's bounds is an overflow. Instead of using the union member, use the entire union with a cast to get to the sockaddr. gcc will now know that the memory extends the full size of the union. Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Fei Li authored
[ Upstream commit 72b319dc ] Currently after setting tap0 link up, the tun code wakes tx/rx waited queues up in tun_net_open() when .ndo_open() is called, however the IFF_UP flag has not been set yet. If there's already a wait queue, it would fail to transmit when checking the IFF_UP flag in tun_sendmsg(). Then the saving vhost_poll_start() will add the wq into wqh until it is waken up again. Although this works when IFF_UP flag has been set when tun_chr_poll detects; this is not true if IFF_UP flag has not been set at that time. Sadly the latter case is a fatal error, as the wq will never be waken up in future unless later manually setting link up on purpose. Fix this by moving the wakeup process into the NETDEV_UP event notifying process, this makes sure IFF_UP has been set before all waited queues been waken up. Signed-off-by:
Fei Li <lifei.shirley@bytedance.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
YueHaibing authored
[ Upstream commit ee429742 ] We should rather have vlan_tci filled all the way down to the transmitting netdevice and let it do the hw/sw vlan implementation. Suggested-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Roland Hii authored
[ Upstream commit d0bb82fd ] When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit hardware timestamp. The polling will most likely timeout if the tx coalesce is enabled due to the Interrupt-on-Completion (IC) bit is not set in tx descriptor for those frames. This patch will ignore the tx coalesce parameter and set the IC bit when transmitting PTP frames which need to report out the frame transmit hardware timestamp to user space. Fixes: f748be53 ("net: stmmac: Rework coalesce timer and fix multi-queue races") Signed-off-by:
Roland Hii <roland.king.guan.hii@intel.com> Signed-off-by:
Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by:
Voon Weifeng <weifeng.voon@intel.com> Signed-off-by:
-
Roland Hii authored
[ Upstream commit a1e5388b ] When ADDSUB bit is set, the system time seconds field is calculated as the complement of the seconds part of the update value. For example, if 3.000000001 seconds need to be subtracted from the system time, this field is calculated as 2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD Previously, the 0x100000000 is mistakenly written as 100000000. This is further simplified from sec = (0x100000000ULL - sec); to sec = -sec; Fixes: ba1ffd74 ("stmmac: fix PTP support for GMAC4") Signed-off-by:
-
YueHaibing authored
[ Upstream commit 30d8177e ] We build vlan on top of bonding interface, which vlan offload is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is BOND_XMIT_POLICY_ENCAP34. Because vlan tx offload is off, vlan tci is cleared and skb push the vlan header in validate_xmit_vlan() while sending from vlan devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to get information from protocol headers encapsulated within vlan, because 'nhoff' is points to IP header, so bond hashing is based on layer 2 info, which fails to distribute packets across slaves. This patch always enable bonding's vlan tx offload, pass the vlan packets to the slave devices with vlan tci, let them to handle vlan implementation. Fixes: 278339a4 ("bonding: propogate vlan_features to bonding master") Suggested-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Wang Xin authored
commit 9a9e295e upstream. Within at24_loop_until_timeout the timestamp used for timeout checking is recorded after the I2C transfer and sleep_range(). Under high CPU load either the execution time for I2C transfer or sleep_range() could actually be larger than the timeout value. Worst case the I2C transfer is only tried once because the loop will exit due to the timeout although the EEPROM is now ready. To fix this issue the timestamp is recorded at the beginning of each iteration. That is, before I2C transfer and sleep. Then the timeout is actually checked against the timestamp of the previous iteration. This makes sure that even if the timeout is reached, there is still one more chance to try the I2C transfer in case the EEPROM is ready. Example: If you have a system which combines high CPU load with repeated EEPROM writes you will run into the following scenario. - System makes a successful regmap_bulk_write() to EEPROM. - System wants to perform another write to EEPROM but EEPROM is still busy with the last write. - Because of high CPU load the usleep_range() will sleep more than 25 ms (at24_write_timeout). - Within the over-long sleeping the EEPROM finished the previous write operation and is ready again. - at24_loop_until_timeout() will detect timeout and won't try to write. Signed-off-by:
Wang Xin <xin.wang7@cn.bosch.com> Signed-off-by:
Mark Jonas <mark.jonas@de.bosch.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Paul Burton authored
commit 6d4d367d upstream. The MIPS GIC contains a block of registers used to map local interrupts to a particular CPU interrupt pin. Since these registers are found at a consecutive range of addresses we access them using an index, via the (read|write)_gic_v[lo]_map accessor functions. We currently use values from enum mips_gic_local_interrupt as those indices. Unfortunately whilst enum mips_gic_local_interrupt provides the correct offsets for bits in the pending & mask registers, the ordering of the map registers is subtly different... Compared with the ordering of pending & mask bits, the map registers move the FDC from the end of the list to index 3 after the timer interrupt. As a result the performance counter & software interrupts are therefore at indices 4-6 rather than indices 3-5. Notably this causes problems with performance counter interrupts being incorrectly mapped on some systems, and presumably will also cause problems for FDC interrupts. Introduce a function to map from enum mips_gic_local_interrupt to the index of the corresponding map register, and use it to ensure we access the map registers for the correct interrupts. Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: a0dc5cb5 ("irqchip: mips-gic: Simplify gic_local_irq_domain_map()") Fixes: da61fcf9 ("irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs") Reported-and-tested-by:
Archer Yan <ayan@wavecomp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org # v4.14+ Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Jan Kara authored
commit 240b4cc8 upstream. Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0] dereference can dereference already freed request leading to kernel crashes or other issues (which one of our customers observed). Store cmd->cmnd[0] in a local variable before unlocking adapter->hw_lock to fix the issue. CC: <stable@vger.kernel.org> Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
zhangyi (F) authored
commit 211ad4b7 upstream. Currently, although we submit super bios in order (and super.nr_entries is incremented by each logged entry), submit_bio() is async so each super sector may not be written to log device in order and then the final nr_entries may be smaller than it should be. This problem can be reproduced by the xfstests generic/455 with ext4: QA output created by 455 -Silence is golden +mark 'end' does not exist Fix this by serializing submission of super sectors to make sure each is written to the log disk in order. Fixes: 0e9cebe7 ("dm: add log writes target") Cc: stable@vger.kernel.org Signed-off-by:
zhangyi (F) <yi.zhang@huawei.com> Suggested-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Dinh Nguyen authored
commit 74684cce upstream. The fixed dividers for the emac clocks should be 2 not 4. Cc: stable@vger.kernel.org Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Jack Pham authored
commit bd674224 upstream OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Felipe Balbi authored
commit fec9095b upstream Now that we have a list of cancelled requests, we can skip over TRBs when END_TRANSFER command completes. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit d4f1afe5 upstream Whenever we have a request in flight, we can move it to the cancelled list and later simply iterate over that list and skip over any TRBs we find. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit d5443bbf upstream This list will host cancelled requests who still have TRBs being processed. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit 7746a8df upstream Extract the logic for skipping over TRBs to its own function. This makes the code slightly more readable and makes it easier to move this call to its final resting place as a following patch. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit c3acd590 upstream Now that we track how many TRBs a request uses, it's easier to skip over them in case of a call to usb_ep_dequeue(). Let's do so and simplify the code a bit. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit 09fe1f8d upstream This will help us remove the wait_event() from our ->dequeue(). Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Felipe Balbi authored
commit 1a22ec64 upstream Both flags are used for the same purpose in dwc3: appending an extra TRB at the end to deal with controller requirements. By combining both flags into one, we make it clear that the situation is the same and that they should be treated equally. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
John Stultz authored
This reverts commit 25ad17d6 , as we will be cherry-picking a number of changes from upstream that allows us to later cherry-pick the same fix from upstream rather than using this modified backported version. Cc: Fei Yang <fei.yang@intel.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org # 4.19.y Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit 904d88d7 ] The syzbot reported Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x67/0x231 mm/kasan/report.c:188 __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 kasan_report+0xe/0x20 mm/kasan/common.c:614 qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 Caused by too many confusing indirections and casts. id->driver_info is a pointer stored in a long. We want the pointer here, not the address of it. Thanks-to: Hillf Danton <hdanton@sina.com> Reported-by: syzbot+b68605d7fadd21510de1@syzkaller.appspotmail.com Cc: Kristian Evensen <kristian.evensen@gmail.com> Fixes: e4bf6348 ("qmi_wwan: Add quirk for Quectel dynamic config") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Mike Marciniszyn authored
commit da9de5f8 upstream. The call to sdma_progress() is called outside the wait lock. In this case, there is a race condition where sdma_progress() can return false and the sdma_engine can idle. If that happens, there will be no more sdma interrupts to cause the wakeup and the user_sdma xmit will hang. Fix by moving the lock to enclose the sdma_progress() call. Also, delete busycount. The need for this was removed by: commit bcad2913 ("IB/hfi1: Serve the most starved iowait entry first") Ported to linux-4.19.y. Cc: <stable@vger.kernel.org> Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Gary Leshner <Gary.S.Leshner@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
-
- 25 Jun, 2019 7 commits
-
-
Gao Xiang authored
commit 5efe5137 upstream. There are some backward incompatible features pending for months, mainly due to on-disk format expensions. However, we should ensure that it cannot be mounted with old kernels. Otherwise, it will causes unexpected behaviors. Fixes: ba2b77a8 ("staging: erofs: add super block operations") Cc: <stable@vger.kernel.org> # 4.19+ Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Gao Xiang <gaoxiang25@huawei.com> Signed-off-by:
-
Thomas Hellstrom authored
commit cc0ba0d8 upstream. The HB port may not be available for various reasons. Either it has been disabled by a config option or by the hypervisor for other reasons. In that case, make sure we have a backup plan and use the backdoor port instead with a performance penalty. Cc: stable@vger.kernel.org Fixes: 89da76fd ("drm/vmwgfx: Add VMWare host messaging capability") Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Deepak Rawat <drawat@vmware.com> Signed-off-by:
-
Joakim Zhang authored
commit 247e5356 upstream. Current we can meet timeout issue when setting a small bitrate like 10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ): | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000 A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check. | RTNETLINK answers: Connection timed out It is caused by calling of flexcan_chip_unfreeze() timeout. Originally the code is using usleep_range(10, 20) for unfreeze operation, but the patch (8badd65e can: flexcan: avoid calling usleep_range from interrupt context) changed it into udelay(10) which is only a half delay of before, there're also some other delay changes. After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue. Meanwhile, Rasmus Villemoes reported that even with a timeout of 100, flexcan_probe() fails on the MPC8309, which requires a value of at least 140 to work reliably. 250 works for everyone. Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Anssi Hannula authored
commit 904044dd upstream. Commit 9e5f1b27 ("can: xilinx_can: add support for Xilinx CAN FD core") added a new can_bittiming_const structure for CAN FD cores that support larger values for tseg1, tseg2, and sjw than previous Xilinx CAN cores, but the commit did not actually take that into use. Fix that. Tested with CAN FD core on a ZynqMP board. Fixes: 9e5f1b27 ("can: xilinx_can: add support for Xilinx CAN FD core") Reported-by:
Shubhrajyoti Datta <shubhrajyoti.datta@gmail.com> Signed-off-by:
Anssi Hannula <anssi.hannula@bitwise.fi> Cc: Michal Simek <michal.simek@xilinx.com> Reviewed-by:
-
Jaesoo Lee authored
[ Upstream commit c8e8c77b ] The Number of Namespaces (nn) field in the identify controller data structure is defined as u32 and the maximum allowed value in NVMe specification is 0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP() operation used in nvme_scan_ns_list() by casting the nn to u64. Signed-off-by:
Jaesoo Lee <jalee@purestorage.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Robert Hancock authored
[ Upstream commit 4a60570d ] Some chips have attributes which exist on more than one page but the attribute is not presently marked as paged. This causes the attributes to be generated with the same label, which makes it impossible for userspace to tell them apart. Marking all such attributes as paged would result in the page suffix being added regardless of whether they were present on more than one page or not, which might break existing setups. Therefore, we add a second check which treats the attribute as paged, even if not marked as such, if it is present on multiple pages. Fixes: b4ce237b ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers") Signed-off-by:
Robert Hancock <hancock@sedsystems.ca> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Eduardo Valentin authored
[ Upstream commit c41dd48e ] Drivers may register to hwmon and request for also registering with the thermal subsystem (HWMON_C_REGISTER_TZ). However, some of these driver, e.g. marvell phy, may be probed from Device Tree or being dynamically allocated, and in the later case, it will not have a dev->of_node entry. Registering with hwmon without the dev->of_node may result in different outcomes depending on the device tree, which may be a bit misleading. If the device tree blob has no 'thermal-zones' node, the *hwmon_device_register*() family functions are going to gracefully succeed, because of-thermal, *thermal_zone_of_sensor_register() return -ENODEV in this case, and the hwmon error path handles this error code as success to cover for the case where CONFIG_THERMAL_OF is not set. However, if the device tree blob has the 'thermal-zones' entry, the *hwmon_device_register*() will always fail on callers with no dev->of_node, propagating -EINVAL. If dev->of_node is not present, calling of-thermal does not make sense. For this reason, this patch checks first if the device has a of_node before going over the process of registering with the thermal subsystem of-thermal interface. And in this case, when a caller of *hwmon_device_register*() with HWMON_C_REGISTER_TZ and no dev->of_node will still register with hwmon, but not with the thermal subsystem. If all the hwmon part bits are in place, the registration will succeed. Fixes: d560168b ("hwmon: (core) New hwmon registration API") Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Eduardo Valentin <eduval@amazon.com> Signed-off-by:
-
