summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* dm raid: fix updating of max_discard_sectors limitMing Lei2019-10-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c8156fc77d0796ba2618936dbb3084e769e916c1 upstream. Unit of 'chunk_size' is byte, instead of sector, so fix it by setting the queue_limits' max_discard_sectors to rs->md.chunk_sectors. Also, rename chunk_size to chunk_size_bytes. Without this fix, too big max_discard_sectors is applied on the request queue of dm-raid, finally raid code has to split the bio again. This re-split done by raid causes the following nested clone_endio: 1) one big bio 'A' is submitted to dm queue, and served as the original bio 2) one new bio 'B' is cloned from the original bio 'A', and .map() is run on this bio of 'B', and B's original bio points to 'A' 3) raid code sees that 'B' is too big, and split 'B' and re-submit the remainded part of 'B' to dm-raid queue via generic_make_request(). 4) now dm will handle 'B' as new original bio, then allocate a new clone bio of 'C' and run .map() on 'C'. Meantime C's original bio points to 'B'. 5) suppose now 'C' is completed by raid directly, then the following clone_endio() is called recursively: clone_endio(C) ->clone_endio(B) #B is original bio of 'C' ->bio_endio(A) 'A' can be big enough to make hundreds of nested clone_endio(), then stack can be corrupted easily. Fixes: 61697a6abd24a ("dm: eliminate 'split_discard_bios' flag from DM target interface") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* soundwire: fix regmap dependencies and align with other serial linksPierre-Louis Bossart2019-10-073-8/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8676b3ca4673517650fd509d7fa586aff87b3c28 ] The existing code has a mixed select/depend usage which makes no sense. config SOUNDWIRE_BUS tristate select REGMAP_SOUNDWIRE config REGMAP_SOUNDWIRE tristate depends on SOUNDWIRE_BUS Let's remove one layer of Kconfig definitions and align with the solutions used by all other serial links. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190718230215.18675-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: hisilicon - Fix double free in sec_free_hw_sgl()Yunfeng Ye2019-10-071-6/+7
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 24fbf7bad888767bed952f540ac963bc57e47e15 ] There are two problems in sec_free_hw_sgl(): First, when sgl_current->next is valid, @hw_sgl will be freed in the first loop, but it free again after the loop. Second, sgl_current and sgl_current->next_sgl is not match when dma_pool_free() is invoked, the third parameter should be the dma address of sgl_current, but sgl_current->next_sgl is the dma address of next chain, so use sgl_current->next_sgl is wrong. Fix this by deleting the last dma_pool_free() in sec_free_hw_sgl(), modifying the condition for while loop, and matching the address for dma_pool_free(). Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* pktcdvd: remove warning on attempting to register non-passthrough devJens Axboe2019-10-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit eb09b3cc464d2c3bbde9a6648603c8d599ea8582 ] Anatoly reports that he gets the below warning when booting -git on a sparc64 box on debian unstable: ... [ 13.352975] aes_sparc64: Using sparc64 aes opcodes optimized AES implementation [ 13.428002] ------------[ cut here ]------------ [ 13.428081] WARNING: CPU: 21 PID: 586 at drivers/block/pktcdvd.c:2597 pkt_setup_dev+0x2e4/0x5a0 [pktcdvd] [ 13.428147] Attempt to register a non-SCSI queue [ 13.428184] Modules linked in: pktcdvd libdes cdrom aes_sparc64 n2_rng md5_sparc64 sha512_sparc64 rng_core sha256_sparc64 flash sha1_sparc64 ip_tables x_tables ipv6 crc_ccitt nf_defrag_ipv6 autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear md_mod crc32c_sparc64 [ 13.428452] CPU: 21 PID: 586 Comm: pktsetup Not tainted 5.3.0-10169-g574cc4539762 #1234 [ 13.428507] Call Trace: [ 13.428542] [00000000004635c0] __warn+0xc0/0x100 [ 13.428582] [0000000000463634] warn_slowpath_fmt+0x34/0x60 [ 13.428626] [000000001045b244] pkt_setup_dev+0x2e4/0x5a0 [pktcdvd] [ 13.428674] [000000001045ccf4] pkt_ctl_ioctl+0x94/0x220 [pktcdvd] [ 13.428724] [00000000006b95c8] do_vfs_ioctl+0x628/0x6e0 [ 13.428764] [00000000006b96c8] ksys_ioctl+0x48/0x80 [ 13.428803] [00000000006b9714] sys_ioctl+0x14/0x40 [ 13.428847] [0000000000406294] linux_sparc_syscall+0x34/0x44 [ 13.428890] irq event stamp: 4181 [ 13.428924] hardirqs last enabled at (4189): [<00000000004e0a74>] console_unlock+0x634/0x6c0 [ 13.428984] hardirqs last disabled at (4196): [<00000000004e0540>] console_unlock+0x100/0x6c0 [ 13.429048] softirqs last enabled at (3978): [<0000000000b2e2d8>] __do_softirq+0x498/0x520 [ 13.429110] softirqs last disabled at (3967): [<000000000042cfb4>] do_softirq_own_stack+0x34/0x60 [ 13.429172] ---[ end trace 2220ca468f32967d ]--- [ 13.430018] pktcdvd: setup of pktcdvd device failed [ 13.455589] des_sparc64: Using sparc64 des opcodes optimized DES implementation [ 13.515334] camellia_sparc64: Using sparc64 camellia opcodes optimized CAMELLIA implementation [ 13.522856] pktcdvd: setup of pktcdvd device failed [ 13.529327] pktcdvd: setup of pktcdvd device failed [ 13.532932] pktcdvd: setup of pktcdvd device failed [ 13.536165] pktcdvd: setup of pktcdvd device failed [ 13.539372] pktcdvd: setup of pktcdvd device failed [ 13.542834] pktcdvd: setup of pktcdvd device failed [ 13.546536] pktcdvd: setup of pktcdvd device failed [ 15.431071] XFS (dm-0): Mounting V5 Filesystem ... Apparently debian auto-attaches any cdrom like device to pktcdvd, which can lead to the above warning. There's really no reason to warn for this situation, kill it. Reported-by: Anatoly Pugachev <matorola@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: Use static const struct, not const static structKrzysztof Wilczynski2019-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8050f3f6645ae0f7e4c1304593f6f7eb2ee7d85c ] Move the static keyword to the front of declarations of pci_regs_behavior[] and pcie_cap_regs_behavior[], which resolves compiler warnings when building with "W=1": drivers/pci/pci-bridge-emul.c:41:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] const static struct pci_bridge_reg_behavior pci_regs_behavior[] = { ^ drivers/pci/pci-bridge-emul.c:176:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] const static struct pci_bridge_reg_behavior pcie_cap_regs_behavior[] = { ^ Link: https://lore.kernel.org/r/20190826151436.4672-1-kw@linux.com Link: https://lore.kernel.org/r/20190828131733.5817-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: exynos: Propagate errors for optional PHYsThierry Reding2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ddd6960087d4b45759434146d681a94bbb1c54ad ] devm_of_phy_get() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate devres structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "PHY not specified in DT". What we really want is to ignore the optional PHYs only if they have not been specified in DT. devm_of_phy_get() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: imx6: Propagate errors for optional regulatorsThierry Reding2019-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2170a09fb4b0f66e06e5bcdcbc98c9ccbf353650 ] regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: kernel@pengutronix.de Cc: linux-imx@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: histb: Propagate errors for optional regulatorsThierry Reding2019-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8f9e1641ba445437095411d9fda2324121110d5d ] regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: rockchip: Propagate errors for optional regulatorsThierry Reding2019-10-071-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0e3ff0ac5f71bdb6be2a698de0ed0c7e6e738269 ] regulator_get_optional() can fail for a number of reasons besides probe deferral. It can for example return -ENOMEM if it runs out of memory as it tries to allocate data structures. Propagating only -EPROBE_DEFER is problematic because it results in these legitimately fatal errors being treated as "regulator not specified in DT". What we really want is to ignore the optional regulators only if they have not been specified in DT. regulator_get_optional() returns -ENODEV in this case, so that's the special case that we need to handle. So we propagate all errors, except -ENODEV, so that real failures will still cause the driver to fail probe. Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: apple: Fix stuck function keys when using FNJoao Moreno2019-10-071-21/+28
| | | | | | | | | | | | | | | | | | [ Upstream commit aec256d0ecd561036f188dbc8fa7924c47a9edfd ] This fixes an issue in which key down events for function keys would be repeatedly emitted even after the user has raised the physical key. For example, the driver fails to emit the F5 key up event when going through the following steps: - fnmode=1: hold FN, hold F5, release FN, release F5 - fnmode=2: hold F5, hold FN, release F5, release FN The repeated F5 key down events can be easily verified using xev. Signed-off-by: Joao Moreno <mail@joaomoreno.com> Co-developed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: Add pci_info_ratelimited() to ratelimit PCI separatelyKrzysztof Wilczynski2019-10-071-2/+2
| | | | | | | | | | | | | | | | [ Upstream commit 7f1c62c443a453deb6eb3515e3c05650ffe0dcf0 ] Do not use printk_ratelimit() in drivers/pci/pci.c as it shares the rate limiting state with all other callers to the printk_ratelimit(). Add pci_info_ratelimited() (similar to pci_notice_ratelimited() added in the commit a88a7b3eb076 ("vfio: Use dev_printk() when possible")) and use it instead of printk_ratelimit() + pci_info(). Link: https://lore.kernel.org/r/20190825224616.8021-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: pcf85363/pcf85263: fix regmap error in set_timeBiwen Li2019-10-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7ef66122bdb3b839e9f51b76d7e600b6e21ef648 ] Issue: - # hwclock -w hwclock: RTC_SET_TIME: Invalid argument Why: - Relative commit: 8b9f9d4dc511 ("regmap: verify if register is writeable before writing operations"), this patch will always check for unwritable registers, it will compare reg with max_register in regmap_writeable. - The pcf85363/pcf85263 has the capability of address wrapping which means if you access an address outside the allowed range (0x00-0x2f) hardware actually wraps the access to a lower address. The rtc-pcf85363 driver will use this feature to configure the time and execute 2 actions in the same i2c write operation (stopping the clock and configure the time). However the driver has also configured the `regmap maxregister` protection mechanism that will block accessing addresses outside valid range (0x00-0x2f). How: - Split of writing regs to two parts, first part writes control registers about stop_enable and resets, second part writes RTC time and date registers. Signed-off-by: Biwen Li <biwen.li@nxp.com> Link: https://lore.kernel.org/r/20190829021418.4607-1-biwen.li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: snvs: fix possible race conditionAnson Huang2019-10-071-4/+7
| | | | | | | | | | | | | | | | | [ Upstream commit 6fd4fe9b496d9ba3382992ff4fde3871d1b6f63d ] The RTC IRQ is requested before the struct rtc_device is allocated, this may lead to a NULL pointer dereference in IRQ handler. To fix this issue, allocating the rtc_device struct before requesting the RTC IRQ using devm_rtc_allocate_device, and use rtc_register_device to register the RTC device. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20190716071858.36750-1-Anson.Huang@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* soundwire: intel: fix channel number reported by hardwarePierre-Louis Bossart2019-10-071-0/+10
| | | | | | | | | | | | | | | [ Upstream commit 18046335643de6d21327f5ae034c8fb8463f6715 ] On all released Intel controllers (CNL/CML/ICL), PDI2 reports an invalid count, force the correct hardware-supported value This may have to be revisited with platform-specific values if the hardware changes, but for now this is good enough. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190806005522.22642-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: layerscape: Add the bar_fixed_64bit property to the endpoint driverXiaowei Bao2019-10-071-0/+1
| | | | | | | | | | | | | | | | | [ Upstream commit fd5d16531a39322c3d7433d9f8a36203c9aaeddc ] The layerscape PCIe controller have 4 BARs. BAR0 and BAR1 are 32bit, BAR2 and BAR4 are 64bit and that's a fixed hardware configuration. Set the bar_fixed_64bit variable accordingly. Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: pci-hyperv: Fix build errors on non-SYSFS configRandy Dunlap2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f58ba5e3f6863ea4486952698898848a6db726c2 ] Fix build errors when building almost-allmodconfig but with SYSFS not set (not enabled). Fixes these build errors: ERROR: "pci_destroy_slot" [drivers/pci/controller/pci-hyperv.ko] undefined! ERROR: "pci_create_slot" [drivers/pci/controller/pci-hyperv.ko] undefined! drivers/pci/slot.o is only built when SYSFS is enabled, so pci-hyperv.o has an implicit dependency on SYSFS. Make that explicit. Also, depending on X86 && X86_64 is not needed, so just change that to depend on X86_64. Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Jake Oshins <jakeo@microsoft.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Cc: linux-hyperv@vger.kernel.org Cc: Dexuan Cui <decui@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: wacom: Fix several minor compiler warningsJason Gerecke2019-10-072-5/+6
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ] Addresses a few issues that were noticed when compiling with non-default warnings enabled. The trimmed-down warnings in the order they are fixed below are: * declaration of 'size' shadows a parameter * '%s' directive output may be truncated writing up to 5 bytes into a region of size between 1 and 64 * pointer targets in initialization of 'char *' from 'unsigned char *' differ in signedness * left shift of negative value Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: tegra: Fix OF node reference leakNishka Dasgupta2019-10-071-7/+15
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9e38e690ace3e7a22a81fc02652fc101efb340cf ] Each iteration of for_each_child_of_node() executes of_node_put() on the previous node, but in some return paths in the middle of the loop of_node_put() is missing thus causing a reference leak. Hence stash these mid-loop return values in a variable 'err' and add a new label err_node_put which executes of_node_put() on the previous node and returns 'err' on failure. Change mid-loop return statements to point to jump to this label to fix the reference leak. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> [lorenzo.pieralisi@arm.com: rewrote commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mfd: intel-lpss: Remove D3cold delayKai-Heng Feng2019-10-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 76380a607ba0b28627c9b4b55cd47a079a59624b ] Goodix touchpad may drop its first couple input events when i2c-designware-platdrv and intel-lpss it connects to took too long to runtime resume from runtime suspended state. This issue happens becuase the touchpad has a rather small buffer to store up to 13 input events, so if the host doesn't read those events in time (i.e. runtime resume takes too long), events are dropped from the touchpad's buffer. The bottleneck is D3cold delay it waits when transitioning from D3cold to D0, hence remove the delay to make the resume faster. I've tested some systems with intel-lpss and haven't seen any regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* i2c-cht-wc: Fix lockdep warningHans de Goede2019-10-071-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 232219b9a464c2479c98aa589acb1bd3383ae9d6 ] When the kernel is build with lockdep support and the i2c-cht-wc driver is used, the following warning is shown: [ 66.674334] ====================================================== [ 66.674337] WARNING: possible circular locking dependency detected [ 66.674340] 5.3.0-rc4+ #83 Not tainted [ 66.674342] ------------------------------------------------------ [ 66.674345] systemd-udevd/1232 is trying to acquire lock: [ 66.674349] 00000000a74dab07 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}, at: regmap_write+0x31/0x70 [ 66.674360] but task is already holding lock: [ 66.674362] 00000000d44a85b7 (i2c_register_adapter){+.+.}, at: i2c_smbus_xfer+0x49/0xf0 [ 66.674370] which lock already depends on the new lock. [ 66.674371] the existing dependency chain (in reverse order) is: [ 66.674374] -> #1 (i2c_register_adapter){+.+.}: [ 66.674381] rt_mutex_lock_nested+0x46/0x60 [ 66.674384] i2c_smbus_xfer+0x49/0xf0 [ 66.674387] i2c_smbus_read_byte_data+0x45/0x70 [ 66.674391] cht_wc_byte_reg_read+0x35/0x50 [ 66.674394] _regmap_read+0x63/0x1a0 [ 66.674396] _regmap_update_bits+0xa8/0xe0 [ 66.674399] regmap_update_bits_base+0x63/0xa0 [ 66.674403] regmap_irq_update_bits.isra.0+0x3b/0x50 [ 66.674406] regmap_add_irq_chip+0x592/0x7a0 [ 66.674409] devm_regmap_add_irq_chip+0x89/0xed [ 66.674412] cht_wc_probe+0x102/0x158 [ 66.674415] i2c_device_probe+0x95/0x250 [ 66.674419] really_probe+0xf3/0x380 [ 66.674422] driver_probe_device+0x59/0xd0 [ 66.674425] device_driver_attach+0x53/0x60 [ 66.674428] __driver_attach+0x92/0x150 [ 66.674431] bus_for_each_dev+0x7d/0xc0 [ 66.674434] bus_add_driver+0x14d/0x1f0 [ 66.674437] driver_register+0x6d/0xb0 [ 66.674440] i2c_register_driver+0x45/0x80 [ 66.674445] do_one_initcall+0x60/0x2f4 [ 66.674450] kernel_init_freeable+0x20d/0x2b4 [ 66.674453] kernel_init+0xa/0x10c [ 66.674457] ret_from_fork+0x3a/0x50 [ 66.674459] -> #0 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}: [ 66.674465] __lock_acquire+0xe07/0x1930 [ 66.674468] lock_acquire+0x9d/0x1a0 [ 66.674472] __mutex_lock+0xa8/0x9a0 [ 66.674474] regmap_write+0x31/0x70 [ 66.674480] cht_wc_i2c_adap_smbus_xfer+0x72/0x240 [i2c_cht_wc] [ 66.674483] __i2c_smbus_xfer+0x1a3/0x640 [ 66.674486] i2c_smbus_xfer+0x67/0xf0 [ 66.674489] i2c_smbus_read_byte_data+0x45/0x70 [ 66.674494] bq24190_probe+0x26b/0x410 [bq24190_charger] [ 66.674497] i2c_device_probe+0x189/0x250 [ 66.674500] really_probe+0xf3/0x380 [ 66.674503] driver_probe_device+0x59/0xd0 [ 66.674506] device_driver_attach+0x53/0x60 [ 66.674509] __driver_attach+0x92/0x150 [ 66.674512] bus_for_each_dev+0x7d/0xc0 [ 66.674515] bus_add_driver+0x14d/0x1f0 [ 66.674518] driver_register+0x6d/0xb0 [ 66.674521] i2c_register_driver+0x45/0x80 [ 66.674524] do_one_initcall+0x60/0x2f4 [ 66.674528] do_init_module+0x5c/0x230 [ 66.674531] load_module+0x2707/0x2a20 [ 66.674534] __do_sys_init_module+0x188/0x1b0 [ 66.674537] do_syscall_64+0x5c/0xb0 [ 66.674541] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 66.674543] other info that might help us debug this: [ 66.674545] Possible unsafe locking scenario: [ 66.674547] CPU0 CPU1 [ 66.674548] ---- ---- [ 66.674550] lock(i2c_register_adapter); [ 66.674553] lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock); [ 66.674556] lock(i2c_register_adapter); [ 66.674559] lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock); [ 66.674561] *** DEADLOCK *** The problem is that the CHT Whiskey Cove PMIC's builtin i2c-adapter is itself a part of an i2c-client (the PMIC). This means that transfers done through it take adapter->bus_lock twice, once for the parent i2c-adapter and once for its own bus_lock. Lockdep does not like this nested locking. To make lockdep happy in the case of busses with muxes, the i2c-core's i2c_adapter_lock_bus function calls: rt_mutex_lock_nested(&adapter->bus_lock, i2c_adapter_depth(adapter)); But i2c_adapter_depth only works when the direct parent of the adapter is another adapter, as it is only meant for muxes. In this case there is an i2c-client and MFD instantiated platform_device in the parent->child chain between the 2 devices. This commit overrides the default i2c_lock_operations, passing a hardcoded depth of 1 to rt_mutex_lock_nested, making lockdep happy. Note that if there were to be a mux attached to the i2c-wc-cht adapter, this would break things again since the i2c-mux code expects the root-adapter to have a locking depth of 0. But the i2c-wc-cht adapter always has only 1 client directly attached in the form of the charger IC paired with the CHT Whiskey Cove PMIC. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* dma-buf/sw_sync: Synchronize signal vs syncpt freeChris Wilson2019-10-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d3c6dd1fb30d3853c2012549affe75c930f4a2f9 ] During release of the syncpt, we remove it from the list of syncpt and the tree, but only if it is not already been removed. However, during signaling, we first remove the syncpt from the list. So, if we concurrently free and signal the syncpt, the free may decide that it is not part of the tree and immediately free itself -- meanwhile the signaler goes on to use the now freed datastructure. In particular, we get struck by commit 0e2f733addbf ("dma-buf: make dma_fence structure a bit smaller v2") as the cb_list is immediately clobbered by the kfree_rcu. v2: Avoid calling into timeline_fence_release() from under the spinlock Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111381 Fixes: d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline lists") References: 0e2f733addbf ("dma-buf: make dma_fence structure a bit smaller v2") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> # v4.14+ Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190812154247.20508-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: core: Reduce memory required for SCSI loggingBart Van Assche2019-10-071-45/+3
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit dccc96abfb21dc19d69e707c38c8ba439bba7160 ] The data structure used for log messages is so large that it can cause a boot failure. Since allocations from that data structure can fail anyway, use kmalloc() / kfree() instead of that data structure. See also https://bugzilla.kernel.org/show_bug.cgi?id=204119. See also commit ded85c193a39 ("scsi: Implement per-cpu logging buffer") # v4.0. Reported-by: Jan Palus <jpalus@fastmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Jan Palus <jpalus@fastmail.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: sprd: add missing kfreeChunyan Zhang2019-10-071-0/+2
| | | | | | | | | | | | | | [ Upstream commit 5e75ea9c67433a065b0e8595ad3c91c7c0ca0d2d ] The number of config registers for different pll clocks probably are not same, so we have to use malloc, and should free the memory before return. Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lkml.kernel.org/r/20190905103009.27166-1-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mbox: qcom: add APCS child device for QCS404Jorge Ramirez-Ortiz2019-10-071-2/+6
| | | | | | | | | | | | | | | [ Upstream commit 78c86458a440ff356073c21b568cb58ddb67b82b ] There is clock controller functionality in the APCS hardware block of qcs404 devices similar to msm8916. Co-developed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: Make clk_bulk_get_all() return a valid "id"Bjorn Andersson2019-10-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7f81c2426587b34bf73e643c1a6d080dfa14cf8a ] The adreno driver expects the "id" field of the returned clk_bulk_data to be filled in with strings from the clock-names property. But due to the use of kmalloc_array() in of_clk_bulk_get_all() it receives a list of bogus pointers instead. Zero-initialize the "id" field and attempt to populate with strings from the clock-names property to resolve both these issues. Fixes: 616e45df7c4a ("clk: add new APIs to operate on all available clocks") Fixes: 8e3e791d20d2 ("drm/msm: Use generic bulk clock function") Cc: Dong Aisheng <aisheng.dong@nxp.com> Cc: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lkml.kernel.org/r/20190913024029.2640-1-bjorn.andersson@linaro.org Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: imx: clk-pll14xx: unbypass PLL by defaultPeng Fan2019-10-071-0/+5
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit a9aa8306074d9519dd6e5fdf07240b01bac72e04 ] When registering the PLL, unbypass the PLL. The PLL has two bypass control bit, BYPASS and EXT_BYPASS. we will expose EXT_BYPASS to clk driver for mux usage, and keep BYPASS inside pll14xx usage. The PLL has a restriction that when M/P change, need to RESET/BYPASS pll to avoid glitch, so we could not expose BYPASS. To make it easy for clk driver usage, unbypass PLL which does not hurt current function. Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc") Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lkml.kernel.org/r/1568043491-20680-3-git-send-email-peng.fan@nxp.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: imx: pll14xx: avoid glitch when set ratePeng Fan2019-10-071-1/+21
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dee1bc9c23cd41fe32549c0adbe6cb57cab02282 ] According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to output unstable clock until lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT." So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch. In the end of set rate, BYPASS will be cleared. When prepare clock, also need to take care to avoid glitch. So we also follow Spec to set BYPASS before RESETB changed from 0 to 1. And add a check if the RESETB is already 0, directly return 0; Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc") Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lkml.kernel.org/r/1568043491-20680-2-git-send-email-peng.fan@nxp.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: at91: select parent if main oscillator or bypass is enabledEugen Hristev2019-10-071-3/+7
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 69a6bcde7fd3fe6f3268ce26f31d9d9378384c98 ] Selecting the right parent for the main clock is done using only main oscillator enabled bit. In case we have this oscillator bypassed by an external signal (no driving on the XOUT line), we still use external clock, but with BYPASS bit set. So, in this case we must select the same parent as before. Create a macro that will select the right parent considering both bits from the MOR register. Use this macro when looking for the right parent. Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Link: https://lkml.kernel.org/r/1568042692-11784-2-git-send-email-eugen.hristev@microchip.com Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mailbox: mediatek: cmdq: clear the event in cmdq initial flowBibby Hsieh2019-10-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6058f11870b8e6d4f5cc7b591097c00bf69a000d ] GCE hardware stored event information in own internal sysram, if the initial value in those sysram is not zero value it will cause a situation that gce can wait the event immediately after client ask gce to wait event but not really trigger the corresponding hardware. In order to make sure that the wait event function is exactly correct, we need to clear the sysram value in cmdq initial flow. Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* pinctrl: meson-gxbb: Fix wrong pinning definition for uart_cOtto Meier2019-10-071-6/+6
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cb0438e4436085d89706b5ccfce4d5da531253de ] Hi i tried to use the uart_C of the the odroid-c2. I enabled it in the dts file. During boot it crashed when the the sdcard slot is addressed. After long search in the net i found this: https://forum.odroid.com/viewtopic.php?f=139&t=25371&p=194370&hilit=uart_C#p177856 After changing the pin definitions accordingly erverything works. Uart_c is functioning and sdcard ist working. Fixes: 6db0f3a8a04e46 ("pinctrl: amlogic: gxbb: add more UART pins") Signed-off-by: Otto Meier <gf435@gmx.net> Link: https://lore.kernel.org/r/1cc32a18-464d-5531-7a1c-084390e2ecb1@gmx.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: qcom: gcc-sdm845: Use floor ops for sdcc clksStephen Boyd2019-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5e4b7e82d497580bc430576c4c9bce157dd72512 ] Some MMC cards fail to enumerate properly when inserted into an MMC slot on sdm845 devices. This is because the clk ops for qcom clks round the frequency up to the nearest rate instead of down to the nearest rate. For example, the MMC driver requests a frequency of 52MHz from clk_set_rate() but the qcom implementation for these clks rounds 52MHz up to the next supported frequency of 100MHz. The MMC driver could be modified to request clk rate ranges but for now we can fix this in the clk driver by changing the rounding policy for this clk to be round down instead of round up. Fixes: 06391eddb60a ("clk: qcom: Add Global Clock controller (GCC) driver for SDM845") Reported-by: Douglas Anderson <dianders@chromium.org> Cc: Taniya Das <tdas@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lkml.kernel.org/r/20190830195142.103564-1-swboyd@chromium.org Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdgpu/si: fix ASIC testsJean Delvare2019-10-071-3/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ] Comparing adev->family with CHIP constants is not correct. adev->family can only be compared with AMDGPU_FAMILY constants and adev->asic_type is the struct member to compare with CHIP constants. They are separate identification spaces. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: support spdifCharlene Liu2019-10-072-11/+10
| | | | | | | | | | | | | | | | [ Upstream commit b5a41620bb88efb9fb31a4fa5e652e3d5bead7d4 ] [Description] port spdif fix to staging: spdif hardwired to afmt inst 1. spdif func pointer spdif resource allocation (reserve last audio endpoint for spdif only) Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: renesas: cpg-mssr: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven2019-10-071-1/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit f787216f33ce5b5a2567766398f44ab62157114c ] The CPG/MSSR Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. Note that this only affects RZ/A2 SoCs. On R-Car Gen2 and Gen3 SoCs, the R-Car SYSC driver handles Clock Domain creation, and offloads only device attachment/detachment to the CPG/MSSR driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: renesas: mstp: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven2019-10-071-1/+2
| | | | | | | | | | | | | | | | | | | | [ Upstream commit a459a184c978ca9ad538aab93aafdde873953f30 ] The CPG/MSTP Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. This also gets rid of a boot warning when the Clock Domain contains an IRQ-safe device, e.g. on RZ/A1: sh_mtu2 fcff0000.timer: PM domain cpg_clocks will not be powered off Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* pinctrl: amd: disable spurious-firing GPIO IRQsDaniel Drake2019-10-071-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d21b8adbd475dba19ac2086d3306327b4a297418 ] When cold-booting Asus X434DA, GPIO 7 is found to be already configured as an interrupt, and the GPIO level is found to be in a state that causes the interrupt to fire. As soon as pinctrl-amd probes, this interrupt fires and invokes amd_gpio_irq_handler(). The IRQ is acked, but no GPIO-IRQ handler was invoked, so the GPIO level being unchanged just causes another interrupt to fire again immediately after. This results in an interrupt storm causing this platform to hang during boot, right after pinctrl-amd is probed. Detect this situation and disable the GPIO interrupt when this happens. This enables the affected platform to boot as normal. GPIO 7 actually is the I2C touchpad interrupt line, and later on, i2c-multitouch loads and re-enables this interrupt when it is ready to handle it. Instead of this approach, I considered disabling all GPIO interrupts at probe time, however that seems a little risky, and I also confirmed that Windows does not seem to have this behaviour: the same 41 GPIO IRQs are enabled under both Linux and Windows, which is a far larger collection than the GPIOs referenced by the DSDT on this platform. Signed-off-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190814090540.7152-1-drake@endlessm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/nouveau/volt: Fix for some cards having 0 maximum voltageMark Menzynski2019-10-071-0/+2
| | | | | | | | | | | | | | [ Upstream commit a1af2afbd244089560794c260b2d4326a86e39b6 ] Some, mostly Fermi, vbioses appear to have zero max voltage. That causes Nouveau to not parse voltage entries, thus users not being able to set higher clocks. When changing this value Nvidia driver still appeared to ignore it, and I wasn't able to find out why, thus the code is ignoring the value if it is zero. CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mark Menzynski <mmenzyns@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/nouveau/kms/tu102-: disable input lut when input is already FP16Ben Skeggs2019-10-071-1/+3
| | | | | | | | | | | | | | [ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also disabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* vfio_pci: Restore original state on releasehexin2019-10-071-4/+13
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 92c8026854c25093946e0d7fe536fd9eac440f06 ] vfio_pci_enable() saves the device's initial configuration information with the intent that it is restored in vfio_pci_disable(). However, the commit referenced in Fixes: below replaced the call to __pci_reset_function_locked(), which is not wrapped in a state save and restore, with pci_try_reset_function(), which overwrites the restored device state with the current state before applying it to the device. Reinstate use of __pci_reset_function_locked() to return to the desired behavior. Fixes: 890ed578df82 ("vfio-pci: Use pci "try" reset interface") Signed-off-by: hexin <hexin15@baidu.com> Signed-off-by: Liu Qi <liuqi16@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* pinctrl: tegra: Fix write barrier placement in pmx_writelSowjanya Komatineni2019-10-071-1/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit c2cf351eba2ff6002ce8eb178452219d2521e38e ] pmx_writel uses writel which inserts write barrier before the register write. This patch has fix to replace writel with writel_relaxed followed by a readback and memory barrier to ensure write operation is completed for successful pinctrl change. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1565984527-5272-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: zx296718: Don't reference clk_init_data after registrationStephen Boyd2019-10-071-60/+49
| | | | | | | | | | | | | | | [ Upstream commit 1a4549c150e27dbc3aea762e879a88209df6d1a5 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Jun Nie <jun.nie@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190815160020.183334-3-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: sprd: Don't reference clk_init_data after registrationStephen Boyd2019-10-071-2/+3
| | | | | | | | | | | | | | | | | [ Upstream commit f6c90df8e7e33c3dc33d4d7471bc42c232b0510e ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-8-sboyd@kernel.org Acked-by: Baolin Wang <baolin.wang@linaro.org> Acked-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: meson: axg-audio: Don't reference clk_init_data after registrationStephen Boyd2019-10-071-2/+5
| | | | | | | | | | | | | | | | [ Upstream commit 1610dd79d0f6202c5c1a91122255fa598679c13a ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-4-sboyd@kernel.org Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: sirf: Don't reference clk_init_data after registrationStephen Boyd2019-10-071-4/+8
| | | | | | | | | | | | | | | [ Upstream commit af55dadfbce35b4f4c6247244ce3e44b2e242b84 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Guo Zeng <Guo.Zeng@csr.com> Cc: Barry Song <Baohua.Song@csr.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-6-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: actions: Don't reference clk_init_data after registrationStephen Boyd2019-10-071-2/+3
| | | | | | | | | | | | | | | | [ Upstream commit cf9ec1fc6d7cceb73e7f1efd079d2eae173fdf57 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-2-sboyd@kernel.org [sboyd@kernel.org: Move name to after checking for error or NULL hw] Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: reprogram VM config when system resumeLewis Huang2019-10-071-0/+8
| | | | | | | | | | | | | | | | | | | | [ Upstream commit e5382701c3520b3ed66169a6e4aa6ce5df8c56e0 ] [Why] The vm config will be clear to 0 when system enter S4. It will cause hubbub didn't know how to fetch data when system resume. The flip always pending because earliest_inuse_address and request_address are different. [How] Reprogram VM config when system resume Signed-off-by: Lewis Huang <Lewis.Huang@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Eric Yang <eric.yang2@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: Fix frames_to_insert mathBayan Zabihiyan2019-10-071-10/+17
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit a463b263032f7c98c5912207db43be1aa34a6438 ] [Why] The math on deciding on how many "frames to insert" sometimes sent us over the max refresh rate. Also integer overflow can occur if we have high refresh rates. [How] Instead of clipping the frame duration such that it doesn’t go below the min, just remove a frame from the number of frames to insert. + Use unsigned long long for intermediate calculations to prevent integer overflow. Signed-off-by: Bayan Zabihiyan <bayan.zabihiyan@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: fix issue where 252-255 values are clippedAnthony Koo2019-10-071-1/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit 1cbcfc975164f397b449efb17f59d81a703090db ] [Why] When endpoint is at the boundary of a region, such as at 2^0=1 we find that the last segment has a sharp slope and some points are clipped at the top. [How] If end point is 1, which is exactly at the 2^0 region boundary, we need to program an additional region beyond this point. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocksIcenowy Zheng2019-10-071-0/+3
| | | | | | | | | | | | | | [ Upstream commit 720099603d1f62e37b789366d7e89824b009ca28 ] The MMC2 clock slices are currently not defined in V3s CCU driver, which makes MMC2 not working. Fix this issue. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: qoriq: Fix -Wunused-const-variableNathan Huckleberry2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a95fb581b144b5e73da382eaedb2e32027610597 ] drivers/clk/clk-qoriq.c:138:38: warning: unused variable 'p5020_cmux_grp1' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp1 drivers/clk/clk-qoriq.c:146:38: warning: unused variable 'p5020_cmux_grp2' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp2 In the definition of the p5020 chip, the p2041 chip's info was used instead. The p5020 and p2041 chips have different info. This is most likely a typo. Link: https://github.com/ClangBuiltLinux/linux/issues/525 Cc: clang-built-linux@googlegroups.com Signed-off-by: Nathan Huckleberry <nhuck@google.com> Link: https://lkml.kernel.org/r/20190627220642.78575-1-nhuck@google.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 02:05:16 +0000