- 15 Jun, 2019 40 commits
-
-
Andrey Smirnov authored
[ Upstream commit 338aa107 ] Fix the warning produced by gpiochip_set_irq_hooks() by allocating a dedicated IRQ chip per GPIO chip/port. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-imx@nxp.com Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takeshi Kihara authored
[ Upstream commit 15160f6d ] The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC revision as ES2.1. Add a workaround to fix this. Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 32a155b1 ] The datasheet says the vconn MUST be off when we start toggling. The tcpm.c state-machine is responsible to make sure vconn is off, but lets add a WARN to catch any cases where vconn is not off for some reason. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 4d8e3e95 ] During early system resume on Exynos5422 with performance counters enabled the following kernel oops happens: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) ... Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4451006a DAC: 00000051 Process bash (pid: 1433, stack limit = 0xb7e0e22f) ... (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24) (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84) (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128) (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54) (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4) (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74) (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04) (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc) (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20) (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50) (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0) (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160) (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c) (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c) (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Undefined instruction is triggered during CP14 reset, because bits: #16 (Secure privileged invasive debug disabled) and #17 (Secure privileged noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN and SPIDEN lines, which are provided by Secure JTAG hardware block. That block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422 boots on cluster 1 (LITTLE/KFC). To fix this issue it is enough to turn on the power on the cluster 0 for a while. This lets the Secure JTAG block to propagate the needed signals to LITTLE/KFC cores and change their DSCR. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Phong Hoang authored
[ Upstream commit 347ab948 ] This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by:
Phong Hoang <phong.hoang.wz@renesas.com> [shimoda: revise the commit log and code] Fixes: 76abbdde ("pwm: Add sysfs interface") Fixes: 0733424c ("pwm: Unexport children before chip removal") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Hoan Nguyen An <na-hoan@jinso.co.jp> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 5ab99cf7 ] The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned off by Linux kernel as unused. However they supply critical parts of SoC so they should be always on: 1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift, RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt lines, TTL/UARTR level shift, reset pins and SW-TACT1 button. It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and VDDQ_GPIO (gpm7, gpy7). The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so marking it "always-on" only reflects its real status. 2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores, memory and Mali (G3D). Signed-off-by:
-
Christoph Vogtländer authored
[ Upstream commit b00ef530 ] It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register. This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired. Fixes: 38dabd91 ("pwm: tiehrpwm: Fix disabling of output of PWMs") Signed-off-by:
Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com> [vigneshr@ti.com: Improve commit message] Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 5ba846b1 ] Intel IOMMU, when enabled, tries to find the domain of the device, assuming it's a PCI one, during DMA operations, such as mapping or unmapping. Since we are splitting the actual PCI device to couple of children via MFD framework (see drivers/mfd/intel-lpss.c for details), the DMA device appears to be a platform one, and thus not an actual one that performs DMA. In a such situation IOMMU can't find or allocate a proper domain for its operations. As a result, all DMA operations are failed. In order to fix this, supply parent of the platform device to the DMA engine framework and fix filter functions accordingly. We may rely on the fact that parent is a real PCI device, because no other configuration is present in the wild. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Mark Brown <broonie@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts] Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Brett Creeley authored
[ Upstream commit 203a068a ] Currently we aren't checking for the ICE_FC_NONE case for the current flow control mode. This is causing "Unknown" to be printed for the current flow control method if flow control is disabled. Fix this by adding the case for ICE_FC_NONE to print "None". Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit da38ef3e ] We are currently assuming all GPIOs are non-wakeup capable GPIOs as we not configuring the bank->non_wakeup_gpios like we used to earlier with platform_data. Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer while considering that later patches may want to configure SoC specific bank->non_wakeup_gpios for the GPIOs in wakeup domain. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Reported-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 699ca301 ] If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Paolo Valente authored
[ Upstream commit 778c02a2 ] If a sync bfq_queue has a higher weight than some other queue, and remains temporarily empty while in service, then, to preserve the bandwidth share of the queue, it is necessary to plug I/O dispatching until a new request arrives for the queue. In addition, a timeout needs to be set, to avoid waiting for ever if the process associated with the queue has actually finished its I/O. Even with the above timeout, the device is however not fed with new I/O for a while, if the process has finished its I/O. If this happens often, then throughput drops and latencies grow. For this reason, the timeout is kept rather low: 8 ms is the current default. Unfortunately, such a low value may cause, on the opposite end, a violation of bandwidth guarantees for a process that happens to issue new I/O too late. The higher the system load, the higher the probability that this happens to some process. This is a problem in scenarios where service guarantees matter more than throughput. One important case are weight-raised queues, which need to be granted a very high fraction of the bandwidth. To address this issue, this commit lower-bounds the plugging timeout for weight-raised queues to 20 ms. This simple change provides relevant benefits. For example, on a PLEXTOR PX-256M5S, with which gnome-terminal starts in 0.6 seconds if there is no other I/O in progress, the same applications starts in - 0.8 seconds, instead of 1.2 seconds, if ten files are being read sequentially in parallel - 1 second, instead of 2 seconds, if, in parallel, five files are being read sequentially, and five more files are being written sequentially Tested-by:
Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by:
Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 1d84353d ] In case ioremap fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereferences. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit ec7f6aad ] When ioremap fails, hga_vram should not be dereferenced. The fix check the failure to avoid NULL pointer dereference. Signed-off-by:
-
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:
-
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:
Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-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:
-
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:
-
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:
-
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:
-
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:
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:
-
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:
-
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 <kishon@ti.com> [lorenzo.pieralisi@arm.com: commit log] 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:
-
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:
-
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:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
-
