summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-02-27dm thin metadata: fix lockdep complaintTheodore Ts'o
[ 3934.173244] ====================================================== [ 3934.179572] WARNING: possible circular locking dependency detected [ 3934.185884] 5.4.21-xfstests #1 Not tainted [ 3934.190151] ------------------------------------------------------ [ 3934.196673] dmsetup/8897 is trying to acquire lock: [ 3934.201688] ffffffffbce82b18 (shrinker_rwsem){++++}, at: unregister_shrinker+0x22/0x80 [ 3934.210268] but task is already holding lock: [ 3934.216489] ffff92a10cc5e1d0 (&pmd->root_lock){++++}, at: dm_pool_metadata_close+0xba/0x120 [ 3934.225083] which lock already depends on the new lock. [ 3934.564165] Chain exists of: shrinker_rwsem --> &journal->j_checkpoint_mutex --> &pmd->root_lock For a more detailed lockdep report, please see: https://lore.kernel.org/r/20200220234519.GA620489@mit.edu We shouldn't need to hold the lock while are just tearing down and freeing the whole metadata pool structure. Fixes: 44d8ebf436399a4 ("dm thin metadata: use pool locking at end of dm_pool_metadata_close") Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-02-27dm cache: fix a crash due to incorrect work item cancellingMikulas Patocka
The crash can be reproduced by running the lvm2 testsuite test lvconvert-thin-external-cache.sh for several minutes, e.g.: while :; do make check T=shell/lvconvert-thin-external-cache.sh; done The crash happens in this call chain: do_waker -> policy_tick -> smq_tick -> end_hotspot_period -> clear_bitset -> memset -> __memset -- which accesses an invalid pointer in the vmalloc area. The work entry on the workqueue is executed even after the bitmap was freed. The problem is that cancel_delayed_work doesn't wait for the running work item to finish, so the work item can continue running and re-submitting itself even after cache_postsuspend. In order to make sure that the work item won't be running, we must use cancel_delayed_work_sync. Also, change flush_workqueue to drain_workqueue, so that if some work item submits itself or another work item, we are properly waiting for both of them. Fixes: c6b4fcbad044 ("dm: add cache target") Cc: stable@vger.kernel.org # v3.9 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-02-27Merge branch 'omap-for-v5.6/fixes-rc3' into fixesTony Lindgren
2020-02-28nvme-pci: Hold cq_poll_lock while completing CQEsBijan Mottahedeh
Completions need to consumed in the same order the controller submitted them, otherwise future completion entries may overwrite ones we haven't handled yet. Hold the nvme queue's poll lock while completing new CQEs to prevent another thread from freeing command tags for reuse out-of-order. Fixes: dabcefab45d3 ("nvme: provide optimized poll function for separate poll queues") Signed-off-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Keith Busch <kbusch@kernel.org>
2020-02-27media: venus: core: add sc7180 DT compatible and resource structDikshita Agarwal
This add DT compatible string and resource structure for sc7180. Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: core: add sdm845-v2 DT compatible and resource structStanimir Varbanov
In order to use dynamic video codec assignment add a new sdm845-v2 DT compatible and new venus_resource structure to cover the binding where all pmdomains and clocks are under the venus_core control. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27i3c: Fix MODALIAS ueventsBoris Brezillon
file2alias uses %X formatters. Fix typos in the MODALIAS uevent to print the part and ext IDs in uppercase. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Link: https://lore.kernel.org/linux-i3c/9ac5f1f8413fbb0481de76b5e43f2f4e1b2dc49f.1582796652.git.vitor.soares@synopsys.com
2020-02-27media: venus: vdec: handle 10bit bitstreamsAniket Masule
Handle 10bit video streams in the decoder by using dithering, i.e the decoder output buffers will be in 8bit format. The runtime handling is implemented by sending v4l2 event to userspace application, then the application should stop the streaming on capture queue and initiate format negotiation, and start streaming again. Signed-off-by: Aniket Masule <amasule@codeaurora.org> Co-developed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: introduce core selectionAniket Masule
Presently the core (vcodec pipelines) assignment is static. Here we introduce dynamic load balancing across the cores depending on the current session load. The load on earch core is calculated and core with minimum load is assigned to given instance. This will be applicable on Venus v4 with more than one vcodec cores. Signed-off-by: Aniket Masule <amasule@codeaurora.org> Co-developed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: redesign clocks and pm domains controlStanimir Varbanov
Redesign core (vcodec) clock control to give the venus core more freedom to control them in order to make possible to use core selection feature on Venus IP v4. Move all clock and pmdomain functions in separate file and abstract power control with common operations per Venus IP version. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27EDAC/synopsys: Do not print an error with back-to-back snprintf() callsSherry Sun
handle_error() currently calls snprintf() a couple of times in succession to output the message for a CE/UE, therefore overwriting each part of the message which was formatted with the previous snprintf() call. As a result, only the part of the message from the last snprintf() call will be printed. The simplest and most effective way to fix this problem is to combine the whole string into one which to supply to a single snprintf() call. [ bp: Massage. ] Fixes: b500b4a029d57 ("EDAC, synopsys: Add ECC support for ZynqMP DDR controller") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: James Morse <james.morse@arm.com> Cc: Manish Narani <manish.narani@xilinx.com> Link: https://lkml.kernel.org/r/1582792452-32575-1-git-send-email-sherry.sun@nxp.com
2020-02-27media: venus: cache vb payload to be used by clock scalingStanimir Varbanov
Instead of iterate over previously queued buffers in clock scaling code do cache the payload in instance context structure for later use when calculating new clock rate. This will avoid to use spin locks during buffer list iteration in clock_scaling. This fixes following kernel Oops: Unable to handle kernel paging request at virtual address deacfffffffffd6c Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [deacfffffffffd6c] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 7 PID: 5763 Comm: V4L2DecoderThre Tainted: G S W 5.4.11 #8 pstate: 20400009 (nzCv daif +PAN -UAO) pc : load_scale_v4+0x4c/0x2bc [venus_core] lr : session_process_buf+0x18c/0x1c0 [venus_core] sp : ffffffc01376b8d0 x29: ffffffc01376b8d0 x28: ffffff80cf1b0220 x27: ffffffc01376bba0 x26: ffffffd8f562b2d8 x25: ffffff80cf1b0220 x24: 0000000000000005 x23: ffffffd8f5620d98 x22: ffffff80ca01c800 x21: ffffff80cf1b0000 x20: ffffff8149490080 x19: ffffff8174b2c010 x18: 0000000000000000 x17: 0000000000000000 x16: ffffffd96ee3a0dc x15: 0000000000000026 x14: 0000000000000026 x13: 00000000000055ac x12: 0000000000000001 x11: deacfffffffffd6c x10: dead000000000100 x9 : ffffff80ca01cf28 x8 : 0000000000000026 x7 : 0000000000000000 x6 : ffffff80cdd899c0 x5 : ffffff80cdd899c0 x4 : 0000000000000008 x3 : ffffff80ca01cf28 x2 : ffffff80ca01cf28 x1 : ffffff80d47ffc00 x0 : ffffff80cf1b0000 Call trace: load_scale_v4+0x4c/0x2bc [venus_core] session_process_buf+0x18c/0x1c0 [venus_core] venus_helper_vb2_buf_queue+0x7c/0xf0 [venus_core] __enqueue_in_driver+0xe4/0xfc [videobuf2_common] vb2_core_qbuf+0x15c/0x338 [videobuf2_common] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem] v4l_qbuf+0x48/0x58 __video_do_ioctl+0x2b0/0x39c video_usercopy+0x394/0x710 video_ioctl2+0x38/0x48 v4l2_ioctl+0x6c/0x80 do_video_ioctl+0xb00/0x2874 v4l2_compat_ioctl32+0x5c/0xcc __se_compat_sys_ioctl+0x100/0x2074 __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa4/0x154 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Code: eb0a013f 54000200 aa1f03e8 d10e514b (b940016c) ---[ end trace e11304b46552e0b9 ]--- Fixes: c0e284ccfeda ("media: venus: Update clock scaling") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: venc: blacklist two encoder propertiesStanimir Varbanov
Those two properties are not implemented for Venus v4 (sdm845), thus don't set them to firmware. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: firmware: Use %pR to print IO resourceAndy Shevchenko
Replace explicit use of members of struct resource by %pR to print the resource. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27media: venus: hfi_parser: Ignore HEVC encoding for V1Stephan Gerhold
Some older MSM8916 Venus firmware versions also seem to indicate support for encoding HEVC, even though they really can't. This will lead to errors later because hfi_session_init() fails in this case. HEVC is already ignored for "dec_codecs", so add the same for "enc_codecs" to make these old firmware versions work correctly. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-02-27tee: amdtee: fix memory leak in amdtee_open_session()Dan Carpenter
On these error paths the "sess" variable isn't freed. It's a refcounted pointer so we need to call kref_put(). I re-arranged the code a bit so the error case is always handled before the success case and the error paths are indented two tabs. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-27PCI: brcmstb: Fix build on 32bit ARM platforms with older compilersMarek Szyprowski
Some older compilers have no implementation for the helper for 64-bit unsigned division/modulo, so linking pcie-brcmstb driver causes the "undefined reference to `__aeabi_uldivmod'" error. *rc_bar2_size is always a power of two, because it is calculated as: "1ULL << fls64(entry->res->end - entry->res->start)", so the modulo operation in the subsequent check can be replaced by a simple logical AND with a proper mask. Link: https://lore.kernel.org/r/20200227115146.24515-1-m.szyprowski@samsung.com Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2020-02-27drm/virtio: fix mmap page attributesGerd Hoffmann
virtio-gpu uses cached mappings, set drm_gem_shmem_object.map_cached accordingly. Cc: stable@vger.kernel.org Fixes: c66df701e783 ("drm/virtio: switch from ttm to gem shmem helpers") Reported-by: Gurchetan Singh <gurchetansingh@chromium.org> Reported-by: Guillaume Gardet <Guillaume.Gardet@arm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-3-kraxel@redhat.com
2020-02-27drm/shmem: add support for per object caching flags.Gerd Hoffmann
Add map_cached bool to drm_gem_shmem_object, to request cached mappings on a per-object base. Check the flag before adding writecombine to pgprot bits. Cc: stable@vger.kernel.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Guillaume Gardet <Guillaume.Gardet@arm.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-2-kraxel@redhat.com
2020-02-27spi/zynqmp: remove entry that causes a cs glitchThommy Jakobsson
In the public interface for chipselect, there is always an entry commented as "Dummy generic FIFO entry" pushed down to the fifo right after the activate/deactivate command. The dummy entry is 0x0, irregardless if the intention was to activate or deactive the cs. This causes the cs line to glitch rather than beeing activated in the case when there was an activate command. This has been observed on oscilloscope, and have caused problems for at least one specific flash device type connected to the qspi port. After the change the glitch is gone and cs goes active when intended. The reason why this worked before (except for the glitch) was because when sending the actual data, the CS bits are once again set. Since most flashes uses mode 0, there is always a half clk period anyway for cs to clk active setup time. If someone would rely on timing from a chip_select call to a transfer_one, it would fail though. It is unknown why the dummy entry was there in the first place, git log seems to be of no help in this case. The reference manual gives no indication of the necessity of this. In fact the lower 8 bits are a setup (or hold in case of deactivate) time expressed in cycles. So this should not be needed to fulfill any setup/hold timings. Signed-off-by: Thommy Jakobsson <thommyj@gmail.com> Reviewed-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-27dma-buf: free dmabuf->name in dma_buf_release()Cong Wang
dma-buf name can be set via DMA_BUF_SET_NAME ioctl, but once set it never gets freed. Free it in dma_buf_release(). Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+b2098bc44728a4efb3e9@syzkaller.appspotmail.com Cc: Greg Hackmann <ghackmann@google.com> Cc: Chenbo Feng <fengc@google.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Chenbo Feng <fengc@google.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191227063204.5813-1-xiyou.wangcong@gmail.com
2020-02-27drm/bridge: analogix-anx6345: fix set of link bandwidthIcenowy Zheng
Current code tries to store the link rate (in bps, which is a big number) in a u8, which surely overflow. Then it's converted back to bandwidth code (which is thus 0) and written to the chip. The code sometimes works because the chip will automatically fallback to the lowest possible DP link rate (1.62Gbps) when get the invalid value. However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps link, it failed. As we had already read the link bandwidth as bandwidth code in earlier code (to check whether it is supported), use it when setting bandwidth, instead of converting it to link rate and then converting back. Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Torsten Duwe <duwe@suse.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Torsten Duwe <duwe@lst.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200221165127.813325-1-icenowy@aosc.io
2020-02-27cpufreq: Fix policy initialization for internal governor driversRafael J. Wysocki
Before commit 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames") the initial value of the policy field in struct cpufreq_policy set by the driver's ->init() callback was implicitly passed from cpufreq_init_policy() to cpufreq_set_policy() if the default governor was neither "performance" nor "powersave". After that commit, however, cpufreq_init_policy() must take that case into consideration explicitly and handle it as appropriate, so make that happen. Fixes: 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames") Link: https://lore.kernel.org/linux-pm/39fb762880c27da110086741315ca8b111d781cd.camel@gmail.com/ Reported-by: Artem Bityutskiy <dedekind1@gmail.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-02-26net: stmmac: fix notifier registrationAaro Koskinen
We cannot register the same netdev notifier multiple times when probing stmmac devices. Register the notifier only once in module init, and also make debugfs creation/deletion safe against simultaneous notifier call. Fixes: 481a7d154cbb ("stmmac: debugfs entry name is not be changed when udev rename device name.") Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26net: phy: mscc: fix firmware pathsAntoine Tenart
The firmware paths for the VSC8584 PHYs not not contain the leading 'microchip/' directory, as used in linux-firmware, resulting in an error when probing the driver. This patch fixes it. Fixes: a5afc1678044 ("net: phy: mscc: add support for VSC8584 PHY") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-27phy: mapphone-mdm6600: Fix timeouts by adding wake-up handlingTony Lindgren
We have an interrupt handler for the wake-up GPIO pin, but we're missing the code to wake-up the system. This can cause timeouts receiving data for the UART that shares the wake-up GPIO pin with the USB PHY. All we need to do is just wake the system and kick the autosuspend timeout to fix the issue. Fixes: 5d1ebbda0318 ("phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4") Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-02-26net: phy: corrected the return value for genphy_check_and_restart_aneg and ↵Sudheesh Mavila
genphy_c45_check_and_restart_aneg When auto-negotiation is not required, return value should be zero. Changes v1->v2: - improved comments and code as Andrew Lunn and Heiner Kallweit suggestion - fixed issue in genphy_c45_check_and_restart_aneg as Russell King suggestion. Fixes: 2a10ab043ac5 ("net: phy: add genphy_check_and_restart_aneg()") Fixes: 1af9f16840e9 ("net: phy: add genphy_c45_check_and_restart_aneg()") Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26slip: not call free_netdev before rtnl_unlock in slip_openyangerkun
As the description before netdev_run_todo, we cannot call free_netdev before rtnl_unlock, fix it by reorder the code. Signed-off-by: yangerkun <yangerkun@huawei.com> Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26net: bcmgenet: Clear ID_MODE_DIS in EXT_RGMII_OOB_CTRL when not neededNicolas Saenz Julienne
Outdated Raspberry Pi 4 firmware might configure the external PHY as rgmii although the kernel currently sets it as rgmii-rxid. This makes connections unreliable as ID_MODE_DIS is left enabled. To avoid this, explicitly clear that bit whenever we don't need it. Fixes: da38802211cc ("net: bcmgenet: Add RGMII_RXID support") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26net: dsa: bcm_sf2: Forcibly configure IMP port for 1Gb/secFlorian Fainelli
We are still experiencing some packet loss with the existing advanced congestion buffering (ACB) settings with the IMP port configured for 2Gb/sec, so revert to conservative link speeds that do not produce packet loss until this is resolved. Fixes: 8f1880cbe8d0 ("net: dsa: bcm_sf2: Configure IMP port for 2Gb/sec") Fixes: de34d7084edd ("net: dsa: bcm_sf2: Only 7278 supports 2Gb/sec IMP port") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26Merge tag 'tag-chrome-platform-fixes-for-v5.6-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform fix from Benson Leung: "Fix a build warning" * tag 'tag-chrome-platform-fixes-for-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: wilco_ec: Include asm/unaligned instead of linux/ path
2020-02-26bnxt_en: add newline to netdev_*() format stringsJonathan Lemon
Add missing newlines to netdev_* format strings so the lines aren't buffered by the printk subsystem. Nitpicked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Acked-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-26Merge tag 'gvt-fixes-2020-02-26' of https://github.com/intel/gvt-linux into ↵Jani Nikula
drm-intel-fixes gvt-fixes-2020-02-26 - Fix virtual display reset (Tina) - Fix one use-after-free for dmabuf (Tina) Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226103016.GC10413@zhen-hp.sh.intel.com
2020-02-26drm/radeon: Inline drm_get_pci_devDaniel Vetter
It's the last user, and more importantly, it's the last non-legacy user of anything in drm_pci.c. The only tricky bit is the agp initialization. But a close look shows that radeon does not use the drm_agp midlayer (the main use of that is drm_bufs for legacy drivers), and instead could use the agp subsystem directly (like nouveau does already). Hence we can just pull this in too. A further step would be to entirely drop the use of drm_device->agp, but feels like too much churn just for this patch. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-02-26drm/amdgpu: Drop DRIVER_USE_AGPDaniel Vetter
This doesn't do anything except auto-init drm_agp support when you call drm_get_pci_dev(). Which amdgpu stopped doing with commit b58c11314a1706bf094c489ef5cb28f76478c704 Author: Alex Deucher <alexander.deucher@amd.com> Date: Fri Jun 2 17:16:31 2017 -0400 drm/amdgpu: drop deprecated drm_get_pci_dev and drm_put_dev No idea whether this was intentional or accidental breakage, but I guess anyone who manages to boot a this modern gpu behind an agp bridge deserves a price. A price I never expect anyone to ever collect :-) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Xiaojie Yuan <xiaojie.yuan@amd.com> Cc: Evan Quan <evan.quan@amd.com> Cc: "Tianci.Yin" <tianci.yin@amd.com> Cc: "Marek Olšák" <marek.olsak@amd.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-02-26spi: pxa2xx: Add CS control clock quirkEvan Green
In some circumstances on Intel LPSS controllers, toggling the LPSS CS control register doesn't actually cause the CS line to toggle. This seems to be failure of dynamic clock gating that occurs after going through a suspend/resume transition, where the controller is sent through a reset transition. This ruins SPI transactions that either rely on delay_usecs, or toggle the CS line without sending data. Whenever CS is toggled, momentarily set the clock gating register to "Force On" to poke the controller into acting on CS. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20200211223700.110252-1-rajatja@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-26regulator: add smb208 supportAnsuel Smith
Smb208 regulators are used on some ipq806x soc. Add support for it to make it avaiable on some routers that use it. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Signed-off-by: Adrian Panella <ianchi74@outlook.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200219163711.479-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-26bus: ti-sysc: Fix 1-wire reset quirkTony Lindgren
Because of the i2c quirk we have the reset quirks named in a confusing way. Let's fix the 1-wire quirk accordinlyg. Then let's switch to using better naming later on. Fixes: 4e23be473e30 ("bus: ti-sysc: Add support for module specific reset quirks") Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-26efi: READ_ONCE rng seed size before munmapJason A. Donenfeld
This function is consistent with using size instead of seed->size (except for one place that this patch fixes), but it reads seed->size without using READ_ONCE, which means the compiler might still do something unwanted. So, this commit simply adds the READ_ONCE wrapper. Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: linux-efi@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200217123354.21140-1-Jason@zx2c4.com Link: https://lore.kernel.org/r/20200221084849.26878-5-ardb@kernel.org
2020-02-26Merge tag 'efi-next' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core Pull EFI updates for v5.7 from Ard Biesheuvel: This time, the set of changes for the EFI subsystem is much larger than usual. The main reasons are: - Get things cleaned up before EFI support for RISC-V arrives, which will increase the size of the validation matrix, and therefore the threshold to making drastic changes, - After years of defunct maintainership, the GRUB project has finally started to consider changes from the distros regarding UEFI boot, some of which are highly specific to the way x86 does UEFI secure boot and measured boot, based on knowledge of both shim internals and the layout of bootparams and the x86 setup header. Having this maintenance burden on other architectures (which don't need shim in the first place) is hard to justify, so instead, we are introducing a generic Linux/UEFI boot protocol. Summary of changes: - Boot time GDT handling changes (Arvind) - Simplify handling of EFI properties table on arm64 - Generic EFI stub cleanups, to improve command line handling, file I/O, memory allocation, etc. - Introduce a generic initrd loading method based on calling back into the firmware, instead of relying on the x86 EFI handover protocol or device tree. - Introduce a mixed mode boot method that does not rely on the x86 EFI handover protocol either, and could potentially be adopted by other architectures (if another one ever surfaces where one execution mode is a superset of another) - Clean up the contents of struct efi, and move out everything that doesn't need to be stored there. - Incorporate support for UEFI spec v2.8A changes that permit firmware implementations to return EFI_UNSUPPORTED from UEFI runtime services at OS runtime, and expose a mask of which ones are supported or unsupported via a configuration table. - Various documentation updates and minor code cleanups (Heinrich) - Partial fix for the lack of by-VA cache maintenance in the decompressor on 32-bit ARM. Note that these patches were deliberately put at the beginning so they can be used as a stable branch that will be shared with a PR containing the complete fix, which I will send to the ARM tree. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-02-26drm/ttm: fix leaking fences via ttm_buffer_object_transferAhzo
Set the drm_device to NULL, so that the newly created buffer object doesn't appear to use the embedded gem object. This is necessary, because otherwise no corresponding dma_resv_fini for the dma_resv_init is called, resulting in a memory leak. The dma_resv_fini in ttm_bo_release_list is only called if the embedded gem object is not used, which is determined by checking if the drm_device is NULL. Bug: https://gitlab.freedesktop.org/drm/amd/issues/958 Fixes: 1e053b10ba60 ("drm/ttm: use gem reservation object") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Ahzo <Ahzo@tutanota.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/355089/
2020-02-26drm/i915: Avoid recursing onto active vma from the shrinkerChris Wilson
We mark the vma as active while binding it in order to protect outselves from being shrunk under mempressure. This only works if we are strict in not attempting to shrink active objects. <6> [472.618968] Workqueue: events_unbound fence_work [i915] <4> [472.618970] Call Trace: <4> [472.618974] ? __schedule+0x2e5/0x810 <4> [472.618978] schedule+0x37/0xe0 <4> [472.618982] schedule_preempt_disabled+0xf/0x20 <4> [472.618984] __mutex_lock+0x281/0x9c0 <4> [472.618987] ? mark_held_locks+0x49/0x70 <4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60 <4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619122] i915_vma_unbind+0xae/0x110 [i915] <4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915] <4> [472.619208] i915_gem_shrink+0x328/0x660 [i915] <4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915] <4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80 <4> [472.619363] ? __alloc_pd+0xb/0x30 [i915] <4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30 <4> [472.619368] ? __module_address+0x23/0xe0 <4> [472.619371] ? is_module_address+0x26/0x40 <4> [472.619374] ? static_obj+0x34/0x50 <4> [472.619376] ? lockdep_init_map+0x4d/0x1e0 <4> [472.619407] setup_page_dma+0xd/0x90 [i915] <4> [472.619437] alloc_pd+0x29/0x50 [i915] <4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915] <4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915] <4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915] <4> [472.619577] __vma_bind+0x26/0x40 [i915] <4> [472.619611] fence_work+0x1c/0x90 [i915] <4> [472.619617] process_one_work+0x26a/0x620 Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221221818.2861432-1-chris@chris-wilson.co.uk (cherry picked from commit 6f24e41022f28061368776ea1514db0a6e67a9b1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-02-26drm/i915/pmu: Avoid using globals for PMU eventsMichał Winiarski
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915, will cause us to try and double free the global state, hitting null ptr deref in free_event_attributes. Let's move it to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-2-michal.winiarski@intel.com (cherry picked from commit 46129dc10f47c5c2b51c93a82b7b2aca46574ae0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-02-26drm/i915/pmu: Avoid using globals for CPU hotplug stateMichał Winiarski
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915 can lead to leaks and warnings from cpuhp: Error: Removing state XXX which has instances left. Let's move the state to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-1-michal.winiarski@intel.com (cherry picked from commit f5a179d4687d4e7bfadd7cbda7ee5d0bad76761f) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-02-26drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgttChris Wilson
Full-ppgtt on gen7 is proving to be highly unstable and not robust. Closes: https://gitlab.freedesktop.org/drm/intel/issues/694 Fixes: 3cd6e8860ecd ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@redhat.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224101120.4024481-1-chris@chris-wilson.co.uk (cherry picked from commit 4fbe112a569526e46fa2accb5763c069f78cb431) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-02-26drm/i915: fix header test with GCOVJani Nikula
$(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix appended is writable. This is not the case when the output filename is /dev/null: HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h /dev/null:1:0: error: cannot open /dev/null.gcno HDRTEST drivers/gpu/drm/i915/display/intel_ddi.h /dev/null:1:0: error: cannot open /dev/null.gcno make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_ddi.hdrtest] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_frontbuffer.hdrtest] Error 1 Filter out $(CFLAGS_GVOC) from the header test $(c_flags) as they don't make sense here anyway. References: http://lore.kernel.org/r/d8112767-4089-4c58-d7d3-2ce03139858a@infradead.org Reported-by: Randy Dunlap <rdunlap@infradead.org> Fixes: c6d4a099a240 ("drm/i915: reimplement header test feature") Cc: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221105414.14358-1-jani.nikula@intel.com (cherry picked from commit 408c1b3253dab93da175690dc0e21dd8bccf3371) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-02-25hwmon: (pmbus/xdpe12284) Add callback for vout limits conversionVadim Pasternak
Provide read_word_data() callback for overvoltage and undervoltage output readouts conversion. These registers are presented in 'slinear11' format, while default conversion for 'vout' class for the devices is 'vid'. It is resulted in wrong conversion in pmbus_reg2data() for in{3-4}_lcrit and in{3-4}_crit attributes. ) Fixes: aaafb7c8eb1c ("hwmon: (pmbus) Add support for Infineon Multi-phase xdpe122 family controllers") Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200224225202.19576-1-vadimp@mellanox.com [gropeck: Adjusted to mainline PMBus API] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-02-25drm/panfrost: Don't try to map on error faultsTomeu Vizoso
If the exception type isn't a translation fault, don't try to map and instead go straight to a terminal fault. Otherwise, we can get flooded by kernel warnings and further faults. Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212202236.13095-1-robh@kernel.org
2020-02-25dm integrity: fix invalid table returned due to argument count mismatchMikulas Patocka
If the flag SB_FLAG_RECALCULATE is present in the superblock, but it was not specified on the command line (i.e. ic->recalculate_flag is false), dm-integrity would return invalid table line - the reported number of arguments would not match the real number. Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org # v5.2+ Reported-by: Ondrej Kozina <okozina@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-02-25dm integrity: fix a deadlock due to offloading to an incorrect workqueueMikulas Patocka
If we need to perform synchronous I/O in dm_integrity_map_continue(), we must make sure that we are not in the map function - in order to avoid the deadlock due to bio queuing in generic_make_request. To avoid the deadlock, we offload the request to metadata_wq. However, metadata_wq also processes metadata updates for write requests. If there are too many requests that get offloaded to metadata_wq at the beginning of dm_integrity_map_continue, the workqueue metadata_wq becomes clogged and the system is incapable of processing any metadata updates. This causes a deadlock because all the requests that need to do metadata updates wait for metadata_wq to proceed and metadata_wq waits inside wait_and_add_new_range until some existing request releases its range lock (which doesn't happen because the range lock is released after metadata update). In order to fix the deadlock, we create a new workqueue offload_wq and offload requests to it - so that processing of offload_wq is independent from processing of metadata_wq. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org # v4.12+ Reported-by: Heinz Mauelshagen <heinzm@redhat.com> Tested-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-22 16:30:21 +0000