- 15 Jun, 2019 40 commits
-
-
Jagan Teki authored
[ Upstream commit a5f50c50 ] GT5663 is capacitive touch controller with customized smart wakeup gestures. Add support for it by adding compatible and supported chip data. The chip data on GT5663 is similar to GT1151, like - config data register has 0x8050 address - config data register max len is 240 - config data checksum has 16-bit Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Giridhar Malavali authored
[ Upstream commit 0257eda0 ] Driver maintains state machine for processing and completing switch commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the previous command is active or sent, in order for next GPSC command to advance the state machine. [mkp: commit desc typo] Signed-off-by:
Giridhar Malavali <gmalavali@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 954b4b75 ] The MSI message address in the RC address space can be 64 bit. The R-Car PCIe RC supports such a 64bit MSI message address as well. The code currently uses virt_to_phys(__get_free_pages()) to obtain a reserved page for the MSI message address, and the return value of which can be a 64 bit physical address on 64 bit system. However, the driver only programs PCIEMSIALR register with the bottom 32 bits of the virt_to_phys(__get_free_pages()) return value and does not program the top 32 bits into PCIEMSIAUR, but rather programs the PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car SoCs, however may fail on new 64 bit R-Car SoCs. Since from a PCIe controller perspective, an inbound MSI is a memory write to a special address (in case of this controller, defined by the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but never hits the DRAM _and_ because allocation of an MSI by a PCIe card driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot cause memory corruption or other issues. There is however the possibility that if virt_to_phys(__get_free_pages()) returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed to 0x0 _and_ if the system had physical RAM at the address matching the value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a physical address matching the value of PCIEMSIALR and a remote write to such a buffer by a PCIe card would trigger a spurious MSI. Fixes: e015f88c ("PCI: rcar: Add support for R-Car H3 to pcie-rcar") Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit f0d14edd ] In case __get_free_pages() fails and returns NULL, fix the return value to -ENOMEM and release resources to avoid dereferencing a NULL pointer. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit fd8a44bd ] Platforms which populate msi_host_init() have their own MSI controller logic. Writing to MSI control registers on platforms which do not use Designware's MSI controller logic might have side effects. To be safe, do not write to MSI control registers if the platform uses its own MSI controller logic instead of Designware's MSI one. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by:
-
Peng Li authored
[ Upstream commit 72110b56 ] When set 2 same MAC to different function of one port, IMP will return error as the later one may modify the origin one. This will cause bond fail for 2 VFs of one port. Driver just print warning and return 0 with this patch, so if set same MAC address, it will return 0 but do not really configure HW. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Chao Yu authored
[ Upstream commit 186857c5 ] As Hagbard Celine reported: Hi, this is a long standing bug that I've hit before on older kernels, but I was not able to get the syslog saved because of the nature of the bug. This time I had booted form a pen-drive, and was able to save the log to it's efi-partition. What i did to trigger it was to create a partition and format it f2fs, then mount it with options: "rw,relatime,lazytime,background_gc=on,disable_ext_identify,discard,heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,data_flush,extent_cache,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict". Then I unpacked a big .tar.xz to the partition (I used a gentoo-stage3-tarball as I was in process of installing Gentoo). Same options just without data_flush gives no problems. Mar 20 20:54:01 usbgentoo kernel: FAT-fs (nvme0n1p4): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. Mar 20 21:05:23 usbgentoo kernel: kworker/dying (1588) used greatest stack depth: 12064 bytes left Mar 20 21:06:40 usbgentoo kernel: BUG: stack guard page was hit at 00000000a4b0733c (stack is 0000000056016422..0000000096e7463f) Mar 20 21:06:40 usbgentoo kernel: kernel stack overflow ...... Mar 20 21:06:40 usbgentoo kernel: Call Trace: Mar 20 21:06:40 usbgentoo kernel: read_node_page+0x71/0xf0 Mar 20 21:06:40 usbgentoo kernel: ? xas_load+0x8/0x50 Mar 20 21:06:40 usbgentoo kernel: __get_node_page+0x73/0x2a0 Mar 20 21:06:40 usbgentoo kernel: f2fs_get_dnode_of_data+0x34e/0x580 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_inline_data+0x5e/0x2a0 Mar 20 21:06:40 usbgentoo kernel: __write_data_page+0x421/0x690 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_cache_pages+0x1cf/0x460 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_data_pages+0x2b3/0x2e0 Mar 20 21:06:40 usbgentoo kernel: ? f2fs_inode_chksum_verify+0x1d/0xc0 Mar 20 21:06:40 usbgentoo kernel: ? read_node_page+0x71/0xf0 Mar 20 21:06:40 usbgentoo kernel: do_writepages+0x3c/0xd0 Mar 20 21:06:40 usbgentoo kernel: __filemap_fdatawrite_range+0x7c/0xb0 Mar 20 21:06:40 usbgentoo kernel: f2fs_sync_dirty_inodes+0xf2/0x200 Mar 20 21:06:40 usbgentoo kernel: f2fs_balance_fs_bg+0x2a3/0x2c0 Mar 20 21:06:40 usbgentoo kernel: ? f2fs_inode_dirtied+0x21/0xc0 Mar 20 21:06:40 usbgentoo kernel: f2fs_balance_fs+0xd6/0x2b0 Mar 20 21:06:40 usbgentoo kernel: __write_data_page+0x4fb/0x690 ...... Mar 20 21:06:40 usbgentoo kernel: __writeback_single_inode+0x2a1/0x340 Mar 20 21:06:40 usbgentoo kernel: ? soft_cursor+0x1b4/0x220 Mar 20 21:06:40 usbgentoo kernel: writeback_sb_inodes+0x1d5/0x3e0 Mar 20 21:06:40 usbgentoo kernel: __writeback_inodes_wb+0x58/0xa0 Mar 20 21:06:40 usbgentoo kernel: wb_writeback+0x250/0x2e0 Mar 20 21:06:40 usbgentoo kernel: ? 0xffffffff8c000000 Mar 20 21:06:40 usbgentoo kernel: ? cpumask_next+0x16/0x20 Mar 20 21:06:40 usbgentoo kernel: wb_workfn+0x2f6/0x3b0 Mar 20 21:06:40 usbgentoo kernel: ? __switch_to_asm+0x40/0x70 Mar 20 21:06:40 usbgentoo kernel: process_one_work+0x1f5/0x3f0 Mar 20 21:06:40 usbgentoo kernel: worker_thread+0x28/0x3c0 Mar 20 21:06:40 usbgentoo kernel: ? rescuer_thread+0x330/0x330 Mar 20 21:06:40 usbgentoo kernel: kthread+0x10e/0x130 Mar 20 21:06:40 usbgentoo kernel: ? kthread_create_on_node+0x60/0x60 Mar 20 21:06:40 usbgentoo kernel: ret_from_fork+0x35/0x40 The root cause is that we run into an infinite recursive calling in between f2fs_balance_fs_bg and writepage() as described below: - f2fs_write_data_pages --- A - __write_data_page - f2fs_balance_fs - f2fs_balance_fs_bg --- B - f2fs_sync_dirty_inodes - filemap_fdatawrite - f2fs_write_data_pages --- A ... - f2fs_balance_fs_bg --- B ... In order to fix this issue, let's detect such condition in __write_data_page() and just skip calling f2fs_balance_fs() recursively. Reported-by:
Hagbard Celine <hagbardcelin@gmail.com> Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Sven Van Asbroeck authored
[ Upstream commit 0cd0e497 ] Call order on probe(): - max14656_hw_init() enables interrupts on the chip - devm_request_irq() starts processing interrupts, isr could be called immediately - isr: schedules delayed work (irq_work) - irq_work: calls power_supply_changed() - devm_power_supply_register() registers the power supply Depending on timing, it's possible that power_supply_changed() is called on an unregistered power supply structure. Fix by registering the power supply before requesting the irq. Cc: Alexander Kurz <akurz@blala.de> Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Junxiao Chang authored
[ Upstream commit e61985d0 ] If punit or telemetry device initialization fails, pmc driver should unregister and return failure. This change is to fix a kernel panic when removing kernel module intel_pmc_ipc. Fixes: 48c19170 ("platform:x86: Add Intel telemetry platform device") Signed-off-by:
Junxiao Chang <junxiao.chang@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Binbin Wu authored
[ Upstream commit 2fef3276 ] In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the callbacks for suspend/resume. GPIO pin may be used as the interrupt pin by some device. However, using SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume callback is called after resume_device_irqs(). Unintended interrupts may arrive due to resuming device irqs first, but the GPIO controller is not properly restored. Normally, for a SMP system, there are multiple cores, so even when there are unintended interrupts, BSP gets the chance to initialize the GPIO chip soon. But when there is only 1 core is active (other cores are offlined or single core) during resume, it is more easily to observe the unintended interrupts. This patch renames the suspend/resume function by adding suffix "_noirq", and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(). Signed-off-by:
Binbin Wu <binbin.wu@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Kabir Sahane authored
[ Upstream commit 72aff4ec ] This area is used to store keys by HSPPA in case of AM438x SOC. Leave it active. Signed-off-by:
Kabir Sahane <x0153567@ti.com> Signed-off-by:
Andrew F. Davis <afd@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit a1e07ba8 ] [Why] The input color space for the plane was previously ignored even if it was set. If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead. [How] Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Anthony Koo authored
[ Upstream commit 15ae3b28 ] [Why] If link is already enabled at a different rate (for example 5.4 Gbps) then calling VBIOS command table to switch to a new rate (for example 2.7 Gbps) will not take effect. This can lead to link training failure to occur. [How] If the requested link rate is different than the current link rate, the link must be disabled in order to re-enable at the new link rate. In today's logic it is currently only impacting eDP since DP connection types will always disable the link during display detection, when initial link verification occurs. Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Signed-off-by:
-
Tyrel Datwyler authored
[ Upstream commit fb26228b ] The find_dlpar_node() helper returns a device node with its reference incremented. Both the add and remove paths use this helper for find the appropriate node, but fail to release the reference when done. Annotate the find_dlpar_node() helper with a comment about the incremented reference count and call of_node_put() on the obtained device_node in the add and remove paths. Also, fixup a reference leak in the find_vio_slot() helper where we fail to call of_node_put() on the vdevice node after we iterate over its children. Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit b14c872e ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality(this at least breaks RAVE SP serdev driver on RDU2). Fix the code to specify IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Cc: Angus Ainslie (Purism) <angus@akkea.ca> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Tested-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit 89791177 ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit 7b3132ec ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6UL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit 412b032a ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit c5ed5daa ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit cc839d0f ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit 28c16801 ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit b7b4fda2 ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit 918bbde8 ] Since 25aaa75d SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by:
-
Andrey Smirnov authored
[ Upstream commit beea0f22 ] Mark iomuxc_gpr as compatible with "fsl,imx6q-iomuxc-gpr" in order for to allow i.MX6 PCIe driver to use it. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit bbdc00a7 ] The rk3288 SoC has two PWM implementations available, the "old" implementation and the "new" one. You can switch between the two of them by flipping a bit in the grf. The "old" implementation is the default at chip power up but isn't the one that's officially supposed to be used. ...and, in fact, the driver that gets selected in Linux using the rk3288 device tree only supports the "new" implementation. Long ago I tried to get a switch to the right IP block landed in the PWM driver (search for "rk3288: Switch to use the proper PWM IP") but that got rejected. In the mean time the grf has grown a full-fledged driver that already sets other random bits like this. That means we can now get the fix landed. For those wondering how things could have possibly worked for the last 4.5 years, folks have mostly been relying on the bootloader to set this bit. ...but occasionally folks have pointed back to my old patch series [1] in downstream kernels. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.htmlSigned-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit f7b0c4ce ] By default, for performance consideration, Intel IOMMU driver won't flush IOTLB immediately after a buffer is unmapped. It schedules a thread and flushes IOTLB in a batched mode. This isn't suitable for untrusted device since it still can access the memory even if it isn't supposed to do so. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Tested-by:
Xu Pengfei <pengfei.xu@intel.com> Tested-by:
Mika Westerberg <mika.westerberg@intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit d3273301 ] Historically the power supply management in this driver has been handled in two separate places in parallel. Device-tree users simply defined an appropriate regulator, while two boards with no DT support (da830-evm and omapl138-hawk) passed functions defined in their respective board files over platform data. These functions simply used legacy GPIO calls to watch the oc GPIO for interrupts and disable the vbus GPIO when the irq fires. Commit d193abf1 ("usb: ohci-da8xx: add vbus and overcurrent gpios") updated these GPIO calls to the modern API and moved them inside the driver. This however is not the optimal solution for the vbus GPIO which should be modeled as a fixed regulator that can be controlled with a GPIO. In order to keep the overcurrent protection available once we move the board files to using fixed regulators we need to disable the enable_reg regulator when the overcurrent indicator interrupt fires. Since we cannot call regulator_disable() from interrupt context, we need to switch to using a oneshot threaded interrupt. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit 57a20248 ] Experimentally it can be seen that going into deep sleep (specifically setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1) appears to fail unless "aclk_dmac1" is on. The failure is that the system never signals that it made it into suspend on the GLOBAL_PWROFF pin and it just hangs. NOTE that it's confirmed that it's the actual suspend that fails, not one of the earlier calls to read/write registers. Specifically if you comment out the "PMU_GLOBAL_INT_DISABLE" setting in rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in rockchip_lpmode_enter() then you can exercise the whole suspend path without any crashing. This is currently not a problem with suspend upstream because there is no current way to exercise the deep suspend code. However, anyone trying to make it work will run into this issue. This was not a problem on shipping rk3288-based Chromebooks because those devices all ran on an old kernel based on 3.14. On that kernel "aclk_dmac1" appears to be left on all the time. There are several ways to skin this problem. A) We could add "aclk_dmac1" to the list of critical clocks and that apperas to work, but presumably that wastes power. B) We could keep a list of "struct clk" objects to enable at suspend time in clk-rk3288.c and use the standard clock APIs. C) We could make the rk3288-pmu driver keep a list of clocks to enable at suspend time. Presumably this would require a dts and bindings change. D) We could just whack the clock on in the existing syscore suspend function where we whack a bunch of other clocks. This is particularly easy because we know for sure that the clock's only parent ("aclk_cpu") is a critical clock so we don't need to do anything more than ungate it. In this case I have chosen D) because it seemed like the least work, but any of the other options would presumably also work fine. Signed-off-by:
Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 89e28da8 ] When building with -Wsometimes-uninitialized, Clang warns: drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is used uninitialized whenever '||' condition is true [-Werror,-Wsometimes-uninitialized] If pwrap_write returns non-zero, pwrap_read will not be called to initialize rdata, meaning that we will use some random uninitialized stack value in our print statement. Zero initialize rdata in case this happens. Link: https://github.com/ClangBuiltLinux/linux/issues/401Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit f316a2b5 ] hook_fault_code() is an ARM32 specific API for hooking into data abort. AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as arch) rely on pci-keystone.c but on them the enumeration of a non-present BDF does not trigger a bus error, so the fixup exception provided by calling hook_fault_code() is not needed and can be guarded with CONFIG_ARM. Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit b22af42b ] SERDES connected to the PCIe controller in AM654 requires power on reset enable (POR_EN) to be set in the SERDES. The SERDES driver sets POR_EN in the reset ops and it has to be invoked before init or enable ops. In order for SERDES driver to set POR_EN, invoke the phy_reset() API in pci-keystone driver. Signed-off-by:
-
Enrico Granata authored
[ Upstream commit 94d4e7af ] As new transfer mechanisms are added to the EC codebase, they may not support v2 of the EC protocol. If the v3 initial handshake transfer fails, the kernel will try and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer will be NULL, and the code will end up causing a kernel panic. Add a check for NULL before calling the transfer function, along with a helpful comment explaining how one might end up in this situation. Signed-off-by:
Enrico Granata <egranata@chromium.org> Reviewed-by:
Jett Rink <jettrink@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit c68b901a ] The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Adam Ludkiewicz authored
[ Upstream commit 3e957b37 ] Added a new local variable in the i40e_setup_tc function named old_queue_pairs so num_queue_pairs can be restored to the correct value in case configuring queue channels fails. Additionally, moved the exit label in the i40e_setup_tc function so the if (need_reset) block can be executed. Also, fixed data packing in the i40e_setup_tc function. Signed-off-by:
Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Jon Hunter authored
[ Upstream commit a46b51cd ] Commit 5f84bb1a ("soc/tegra: pmc: Add sysfs entries for reset info") added sysfs entries for Tegra reset source and level. However, these sysfs are not removed on error and so if the registering of PMC device is probe deferred, then the next time we attempt to probe the PMC device warnings such as the following will be displayed on boot ... sysfs: cannot create duplicate filename '/devices/platform/7000e400.pmc/reset_reason' Fix this by calling device_remove_file() for each sysfs entry added on failure. Note that we call device_remove_file() unconditionally without checking if the sysfs entry was created in the first place, but this should be OK because kernfs_remove_by_name_ns() will fail silently. Fixes: 5f84bb1a ("soc/tegra: pmc: Add sysfs entries for reset info") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Wenwen Wang authored
[ Upstream commit ea094d53 ] In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first found through pirq_find_routing_table(). If the table is not found and CONFIG_PCI_BIOS is defined, the table is then allocated in pcibios_get_irq_routing_table() using kmalloc(). Later, if the I/O APIC is used, this table is actually not used. In that case, the allocated table is not freed, which is a memory leak. Free the allocated table if it is not used. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> [bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to use the irq_routing_table local variable name he suggested] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Mika Westerberg authored
[ Upstream commit 9872760e ] The XDomain protocol messages may start as soon as Thunderbolt control channel is started. This means that if the other host starts sending ThunderboltIP packets early enough they will be passed to the network driver which then gets confused because its resume hook is not called yet. Fix this by unregistering the ThunderboltIP protocol handler when suspending and registering it back on resume. Signed-off-by:
-
Wesley Sheng authored
[ Upstream commit 083c1b5e ] When running application tool switchtec-user's `firmware update` and `event wait` commands concurrently, sometimes the firmware update speed reduced significantly. It is because when the MRPC event happened after MRPC event occurrence check but before the event mask loop reaches its header register in event ISR, the MRPC event would be masked unintentionally. Since there's no chance to enable it again except for a module reload, all the following MRPC execution completion checks time out. Fix this bug by skipping the mask operation for MRPC event in event ISR, same as what we already do for LINK event. Fixes: 52eabba5 ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by:
Wesley Sheng <wesley.sheng@microchip.com> Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 3f54c447 ] Disabling the SMMU when probing from within a kdump kernel so that all incoming transactions are terminated can prevent the core of the crashed kernel from being transferred off the machine if all I/O devices are behind the SMMU. Instead, continue to probe the SMMU after it is disabled so that we can reinitialise it entirely and re-attach the DMA masters as they are reset. Since the kdump kernel may not have drivers for all of the active DMA masters, we suppress fault reporting to avoid spamming the console and swamping the IRQ threads. Reported-by:
"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> Tested-by:
Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Farhan Ali authored
[ Upstream commit 41be3e26 ] vfio_dev_present() which is the condition to wait_event_interruptible_timeout(), will call vfio_group_get_device and try to acquire the mutex group->device_lock. wait_event_interruptible_timeout() will set the state of the current task to TASK_INTERRUPTIBLE, before doing the condition check. This means that we will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning: [ 4050.264464] ------------[ cut here ]------------ [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188 [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90 .... 4050.264756] Call Trace: [ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90) [ 4050.264774] [<0000000000b97edc>] __mutex_lock+0x44/0x8c0 [ 4050.264782] [<0000000000b9878a>] mutex_lock_nested+0x32/0x40 [ 4050.264793] [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio] [ 4050.264803] [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio] [ 4050.264813] [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev] [ 4050.264825] [<00000000008e01b0>] device_release_driver_internal+0x168/0x268 [ 4050.264834] [<00000000008de692>] bus_remove_device+0x162/0x190 [ 4050.264843] [<00000000008daf42>] device_del+0x1e2/0x368 [ 4050.264851] [<00000000008db12c>] device_unregister+0x64/0x88 [ 4050.264862] [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev] [ 4050.264872] [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev] [ 4050.264881] [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8 [ 4050.264890] [<00000000003c1530>] __vfs_write+0x38/0x1a8 [ 4050.264899] [<00000000003c187c>] vfs_write+0xb4/0x198 [ 4050.264908] [<00000000003c1af2>] ksys_write+0x5a/0xb0 [ 4050.264916] [<0000000000b9e270>] system_call+0xdc/0x2d8 [ 4050.264925] 4 locks held by sh/35924: [ 4050.264933] #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198 [ 4050.264948] #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8 [ 4050.264963] #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150 [ 4050.264979] #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268 [ 4050.264993] Last Breaking-Event-Address: [ 4050.265002] [<000000000017bbaa>] __might_sleep+0x72/0x90 [ 4050.265010] irq event stamp: 7039 [ 4050.265020] hardirqs last enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740 [ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740 [ 4050.265040] softirqs last enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100 [ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100 [ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]--- Let's fix this as described in the article https://lwn.net/Articles/628628/. Signed-off-by:
Farhan Ali <alifm@linux.ibm.com> [remove now redundant vfio_dev_present()] Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
