summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Linux 5.12.19v5.12.19linux-5.12.yGreg Kroah-Hartman2021-07-201-1/+1
| | | | | | | | | | Link: https://lore.kernel.org/r/20210719144942.514164272@linuxfoundation.org Link: https://lore.kernel.org/r/20210719183557.768945788@linuxfoundation.org Tested-by: Fox Chen <foxhlchen@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* seq_file: disallow extremely large seq buffer allocationsEric Sandeen2021-07-201-0/+3
| | | | | | | | | | | | | | | commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream. There is no reasonable need for a buffer larger than this, and it avoids int overflow pitfalls. Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Reported-by: Qualys Security Advisory <qsa@qualys.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* misc: alcor_pci: fix inverted branch conditionTong Zhang2021-07-201-1/+1
| | | | | | | | | | | | | | commit 281e468446994a7672733af2bf941f4110d4a895 upstream. This patch fixes a trivial mistake that I made in the previous attempt in fixing the null bridge issue. The branch condition is inverted and we should call alcor_pci_find_cap_offset() only if bridge is not null. Reported-by: Colin Ian King <colin.king@canonical.com> Fixes: 3ce3e45cc333 ("misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge") Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20210522043725.602179-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()Dan Carpenter2021-07-201-1/+2
| | | | | | | | | | | | | commit 80927822e8b6be46f488524cd7d5fe683de97fc4 upstream. The "retval" variable needs to be signed for the error handling to work. Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value") Reviewed-by: Martin Wilck <mwilck@suse.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* certs: add 'x509_revocation_list' to gitignoreLinus Torvalds2021-07-201-0/+1
| | | | | | | | | | | | | | commit 81f202315856edb75a371f3376aa3a47543c16f0 upstream. Commit d1f044103dad ("certs: Add ability to preload revocation certs") created a new generated file for revocation certs, but didn't tell git to ignore it. Thus causing unnecessary "git status" noise after a kernel build with CONFIG_SYSTEM_REVOCATION_LIST enabled. Add the proper gitignore magic. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_initViresh Kumar2021-07-201-7/+20
| | | | | | | | | | | | | | | | [ Upstream commit fe2535a44904a77615a3af8e8fd7dafb98fb0e1b ] It's a classic example of memleak, we allocate something, we fail and never free the resources. Make sure we free all resources on policy ->init() failures. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Tested-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: vdso: Invalid GIC access through VDSOMartin Fäcknitz2021-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ] Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO doesn't return the correct time when using the GIC as clock source. The address of the GIC mapped page is in this case not calculated correctly. The GIC mapped page is calculated from the VDSO data by subtracting PAGE_SIZE: void *get_gic(const struct vdso_data *data) { return (void __iomem *)data - PAGE_SIZE; } However, the data pointer is not page aligned for raw clock sources. This is because the VDSO data for raw clock sources (CS_RAW = 1) is stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0). Therefore, only the VDSO data for CS_HRES_COARSE is page aligned: +--------------------+ | | | vd[CS_RAW] | ---+ | vd[CS_HRES_COARSE] | | +--------------------+ | -PAGE_SIZE | | | | GIC mapped page | <--+ | | +--------------------+ When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns the wrong address (somewhere inside the GIC mapped page). The GIC counter values are not returned which results in an invalid time. Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()") Signed-off-by: Martin Fäcknitz <faecknitz@hotsplots.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* s390/irq: remove HAVE_IRQ_EXIT_ON_IRQ_STACKSven Schnelle2021-07-201-1/+0
| | | | | | | | | | | | | | [ Upstream commit 0aa4ff7688632a86bdb133fa106f2ccd514b91a7 ] This is no longer true since we switched to generic entry. The code switches to the IRQ stack before calling do_IRQ, but switches back to the kernel stack before calling irq_exit(). Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* perf script python: Fix buffer size to report iregs in perf scriptKajol Jain2021-07-201-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dea8cfcc33695f70f56023b416cf88ae44c8a45a ] Commit 48a1f565261d2ab1 ("perf script python: Add more PMU fields to event handler dict") added functionality to report fields like weight, iregs, uregs etc via perf report. That commit predefined buffer size to 512 bytes to print those fields. But in PowerPC, since we added extended regs support in: 068aeea3773a6f4c ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs") d735599a069f6936 ("powerpc/perf: Add extended regs support for power10 platform") Now iregs can carry more bytes of data and this predefined buffer size can result to data loss in perf script output. This patch resolves this issue by making the buffer size dynamic, based on the number of registers needed to print. It also changes the regs_map() return type from int to void, as it is not being used by the set_regs_in_dict(), its only caller. Fixes: 068aeea3773a6f4c ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs") Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Paul Clarke <pc@us.ibm.com> Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Link: http://lore.kernel.org/lkml/20210628062341.155839-1-kjain@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mips: disable branch profiling in boot/decompress.oRandy Dunlap2021-07-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ] Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o to prevent linkage errors. mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict': decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update' mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update' mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: linux-mips@vger.kernel.org Cc: Kyungsik Lee <kyungsik.lee@lge.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mips: always link byteswap helpers into decompressorArnd Bergmann2021-07-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cddc40f5617e53f97ef019d5b29c1bd6cbb031ec ] My series to clean up the unaligned access implementation across architectures caused some mips randconfig builds to fail with: mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel': decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2' It turns out that this problem has already been fixed for the XZ decompressor but now it also shows up in (at least) LZO and LZ4. From my analysis I concluded that the compiler could always have emitted those calls, but the different implementation allowed it to make otherwise better decisions about not inlining the byteswap, which results in the link error when the out-of-line code is missing. While it could be addressed by adding it to the two decompressor implementations that are known to be affected, but as this only adds 112 bytes to the kernel, the safer choice is to always add them. Fixes: c50ec6787536 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions") Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers") Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/ Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kprobe/static_call: Restore missing static_call_text_reserved()Peter Zijlstra2021-07-201-0/+2
| | | | | | | | | | | | | | | | | [ Upstream commit fa68bd09fc62240a383c0c601d3349c47db10c34 ] Restore two hunks from commit: 6333e8f73b83 ("static_call: Avoid kprobes on inline static_call()s") that went walkabout in a Git merge commit. Fixes: 76d4acf22b48 ("Merge tag 'perf-kprobes-2020-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20210628113045.167127609@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* static_call: Fix static_call_text_reserved() vs __initPeter Zijlstra2021-07-201-5/+8
| | | | | | | | | | | | | | | | | [ Upstream commit 2bee6d16e4379326b1eea454e68c98b17456769e ] It turns out that static_call_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. This is mostly harmless and will at worst result in refusing a kprobe. Fixes: 6333e8f73b83 ("static_call: Avoid kprobes on inline static_call()s") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20210628113045.106211657@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* jump_label: Fix jump_label_text_reserved() vs __initPeter Zijlstra2021-07-201-5/+8
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9e667624c291753b8a5128f620f493d0b5226063 ] It turns out that jump_label_text_reserved() was reporting __init text as being reserved past the time when the __init text was freed and re-used. For a long time, this resulted in, at worst, not being able to kprobe text that happened to land at the re-used address. However a recent commit e7bf1ba97afd ("jump_label, x86: Emit short JMP") made it a fatal mistake because it now needs to read the instruction in order to determine the conflict -- an instruction that's no longer there. Fixes: 4c3ef6d79328 ("jump label: Add jump_label_text_reserved() to reserve jump points") Reported-by: kernel test robot <oliver.sang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20210628113045.045141693@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* sched/uclamp: Ignore max aggregation if rq is idleXuewen Yan2021-07-201-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3e1493f46390618ea78607cb30c58fc19e2a5035 ] When a task wakes up on an idle rq, uclamp_rq_util_with() would max aggregate with rq value. But since there is no task enqueued yet, the values are stale based on the last task that was running. When the new task actually wakes up and enqueued, then the rq uclamp values should reflect that of the newly woken up task effective uclamp values. This is a problem particularly for uclamp_max because it default to 1024. If a task p with uclamp_max = 512 wakes up, then max aggregation would ignore the capping that should apply when this task is enqueued, which is wrong. Fix that by ignoring max aggregation if the rq is idle since in that case the effective uclamp value of the rq will be the ones of the task that will wake up. Fixes: 9d20ad7dfc9a ("sched/uclamp: Add uclamp_util_with()") Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> [qias: Changelog] Reviewed-by: Qais Yousef <qais.yousef@arm.com> Link: https://lore.kernel.org/r/20210630141204.8197-1-xuewen.yan94@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()Christophe JAILLET2021-07-201-0/+1
| | | | | | | | | | | | | | [ Upstream commit 030e4138d11fced3b831c2761e4cecf347bae99c ] If an error occurs after a pci_enable_pcie_error_reporting() call, it must be undone by a corresponding pci_disable_pcie_error_reporting() call, as already done in the remove function. Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr Fixes: 3567f36a09d1 ("[SCSI] be2iscsi: Fix AER handling in driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: rockchip: Re-add regulator-always-on for vcc_sdio for rk3399-roc-pcAlex Bee2021-07-201-0/+1
| | | | | | | | | | | | | | | [ Upstream commit eb607cd4957fb0ef97beb2a8293478be6a54240a ] Re-add the regulator-always-on property for vcc_sdio which supplies sdmmc, since it gets disabled during reboot now and the bootrom expects it to be enabled when booting from SD card. This makes rebooting impossible in that case and requires a hard reset to boot again. Fixes: 04a0077fdb19 ("arm64: dts: rockchip: Remove always-on properties from regulator nodes on rk3399-roc-pc.") Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20210619121306.7740-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: rockchip: Re-add regulator-boot-on, regulator-always-on for ↵Alex Bee2021-07-201-0/+2
| | | | | | | | | | | | | | | | | vdd_gpu on rk3399-roc-pc [ Upstream commit 06b2818678d9b35102c9816ffaf6893caf306ed0 ] This might be a limitation of either the current panfrost driver devfreq implementation or how the gpu is implemented in RK3399 SoC. The gpu regulator must never get disabled or the registers get (randomly?) inaccessable by the driver. (see all other RK3399 boards) Fixes: ec7d731d81e7 ("arm64: dts: rockchip: Add node for gpu on rk3399-roc-pc") Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20210619121446.7802-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: show message about HWRNG registrationPali Rohár2021-07-201-0/+2
| | | | | | | | | | | | | | [ Upstream commit fae20160992269431507708fb74c1fd9f3c309c1 ] Currently it is hard to determinate if on Armada 3720 device is HWRNG by running kernel accessible or not. So print information message into dmesg when HWRNG is available and registration was successful. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: fail probing when firmware does not support hwrngPali Rohár2021-07-201-0/+28
| | | | | | | | | | | | | | | | | | | [ Upstream commit 2eab59cf0d2036a5a9e264f719b71c21ccf679c2 ] When Marvell's rWTM firmware, which does not support the GET_RANDOM command, is used, kernel prints an error message hwrng: no data available every 10 seconds. Fail probing of this driver if the rWTM firmware does not support the GET_RANDOM command. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: report failures betterMarek Behún2021-07-201-6/+12
| | | | | | | | | | | | | | | | | [ Upstream commit 72f99888944c44de1c899bbe44db1e53bdc9d994 ] Report a notice level message if a command is not supported by the rWTM firmware. This should not be an error, merely a notice, because the firmware can be used on boards that do not have manufacturing information burned. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: fix reply status decoding functionMarek Behún2021-07-201-2/+5
| | | | | | | | | | | | | | | | | | [ Upstream commit e34e60253d9272311831daed8a2d967cf80ca3dc ] The status decoding function mox_get_status() currently contains an incorrect check: if the error status is not MBOX_STS_SUCCESS, it always returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and we don't get the actual error code sent by the firmware. Fix this. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* thermal/drivers/rcar_gen3_thermal: Fix coefficient calculationsNiklas Söderlund2021-07-201-1/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 8946187ab57ffd02088e50256c73dd31f49db06d ] The fixed value of 157 used in the calculations are only correct for M3-W, on other Gen3 SoC it should be 167. The constant can be derived correctly from the static TJ_3 constant and the SoC specific TJ_1 value. Update the calculation be correct on all Gen3 SoCs. Fixes: 4eb39f79ef44 ("thermal: rcar_gen3_thermal: Update value of Tj_1") Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210605085211.564909-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: imx6q-dhcom: Add gpios pinctrl for i2c bus recoveryChristoph Niedermaier2021-07-201-3/+33
| | | | | | | | | | | | | | | | | | | [ Upstream commit ddc873cd3c0af4faad6a00bffda21c3f775126dd ] The i2c bus can freeze at the end of transaction so the bus can no longer work. This scenario is improved by adding scl/sda gpios definitions to implement the i2c bus recovery mechanism. Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: kernel@dh-electronics.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: imx6q-dhcom: Fix ethernet plugin detection problemsChristoph Niedermaier2021-07-201-0/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit e2bdd3484890441b9cc2560413a86e8f2aa04157 ] To make the ethernet cable plugin detection reliable the power detection of the smsc phy has been disabled. Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: kernel@dh-electronics.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: imx6q-dhcom: Fix ethernet reset time propertiesChristoph Niedermaier2021-07-201-2/+2
| | | | | | | | | | | | | | | | | | [ Upstream commit c016c26c1631f539c652b5d82242a3ca402545c1 ] Fix ethernet reset time properties as described in Documentation/devicetree/bindings/net/ethernet-phy.yaml Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: kernel@dh-electronics.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* thermal/drivers/sprd: Add missing MODULE_DEVICE_TABLEChunyan Zhang2021-07-201-0/+1
| | | | | | | | | | | | | | | [ Upstream commit 4d57fd9aeaa013a245bf1fade81e2c30a5efd491 ] MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Fixes: 554fdbaf19b18 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210512093752.243168-1-zhang.lyra@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: am437x: align ti,pindir-d0-out-d1-in property with dt-shemaAswath Govindraju2021-07-201-2/+2
| | | | | | | | | | | | [ Upstream commit 9b11fec7345f21995f4ea4bafb0e108b9a620238 ] ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: b0b039515445 ("ARM: dts: am43x-epos-evm: set data pin directions for spi0 and spi1") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: am335x: align ti,pindir-d0-out-d1-in property with dt-shemaAswath Govindraju2021-07-201-1/+1
| | | | | | | | | | | | [ Upstream commit 414bfe1d26b60ef20b58e36efd5363188a694bab ] ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: 444d66fafab8 ("ARM: dts: add spi wifi support to cm-t335") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: dra7: Fix duplicate USB4 target module nodeGowtham Tammana2021-07-205-78/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 78b4b165280d3d70e7a217599f0c06a4c0bb11f9 ] With [1] USB4 target-module node got defined in dra74x.dtsi file. However, the earlier definition in [2] was not removed, and this duplication of the target module is causing boot failure on dra74 variant boards - dra7-evm, dra76-evm. USB4 is only present in DRA74x variants, so keeping the entry in dra74x.dtsi and removing it from the top level interconnect hierarchy dra7-l4.dtsi file. This change makes the USB4 target module no longer visible to AM5718, DRA71x and DRA72x so removing references to it in their respective dts files. [1]: commit c7b72abca61ec ("ARM: OMAP2+: Drop legacy platform data for dra7 dwc3") [2]: commit 549fce068a311 ("ARM: dts: dra7: Add l4 interconnect hierarchy and ti-sysc data") Fixes: c7b72abca61ec ("ARM: OMAP2+: Drop legacy platform data for dra7 dwc3") Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: a64-sopine-baseboard: change RGMII mode to TXIDIcenowy Zheng2021-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit bd5431b2f9b30a70f6ed964dd5ee9a6d1c397c06 ] Although the schematics of Pine A64-LTS and SoPine Baseboard shows both the RX and TX internal delay are enabled, they're using the same broken RTL8211E chip batch with Pine A64+, so they should use TXID instead, not ID. In addition, by checking the real components soldered on both a SoPine Baseboard and a Pine A64-LTS, RX delay is not enabled (GR69 soldered and GR70 NC) despite the schematics says it's enabled. It's a common situation for Pine64 boards that the NC information on schematics is not the same with the board. So the RGMII delay mode should be TXID on these boards. Fixes: c2b111e59a7b ("arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210609083843.463750-1-icenowy@aosc.io Signed-off-by: Sasha Levin <sashal@kernel.org>
* memory: fsl_ifc: fix leak of private memory on probe failureKrzysztof Kozlowski2021-07-201-2/+2
| | | | | | | | | | | | [ Upstream commit 8e0d09b1232d0538066c40ed4c13086faccbdff6 ] On probe error the driver should free the memory allocated for private structure. Fix this by using resource-managed allocation. Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210527154322.81253-2-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* memory: fsl_ifc: fix leak of IO mapping on probe failureKrzysztof Kozlowski2021-07-201-2/+2
| | | | | | | | | | | | | | | [ Upstream commit 3b132ab67fc7a358fff35e808fa65d4bea452521 ] On probe error the driver should unmap the IO memory. Smatch reports: drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298. Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210527154322.81253-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: ti: k3-j721e-main: Fix external refclk input to SERDESKishon Vijay Abraham I2021-07-202-28/+34
| | | | | | | | | | | | | | | | | [ Upstream commit 5c6d0b55b46aeb91355e6a9616decf50a3778c91 ] Rename the external refclk inputs to the SERDES from dummy_cmn_refclk/dummy_cmn_refclk1 to cmn_refclk/cmn_refclk1 respectively. Also move the external refclk DT nodes outside the cbass_main DT node. Since in j721e common processor board, only the cmn_refclk1 is connected to 100MHz clock, fix the clock frequency. Fixes: afd094ebe69f ("arm64: dts: ti: k3-j721e-main: Add WIZ and SERDES PHY nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210603143427.28735-2-kishon@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* Revert "ARM: dts: bcm283x: increase dwc2's RX FIFO size"Stefan Wahren2021-07-202-2/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 77daceabedb42482bb6200fa26047c5591716e45 ] This reverts commit 278407a53c3b33fb820332c4d39eb39316c3879a. The original change breaks USB config on Raspberry Pi Zero and Pi 4 B, because it exceeds the total fifo size of 4080. A naive attempt to reduce g-tx-fifo-size doesn't help on Raspberry Pi Zero. So better go back. Fixes: 278407a53c3b ("ARM: dts: bcm283x: increase dwc2's RX FIFO size") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Cc: Pavel Hofman <pavel.hofman@ivitera.com> Link: https://lore.kernel.org/r/1622293371-5997-1-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: r8a779a0: Drop power-domains property from GIC nodeGeert Uytterhoeven2021-07-201-1/+0
| | | | | | | | | | | | | | | | | | [ Upstream commit 1771a33b34421050c7b830f0a8af703178ba9d36 ] "make dtbs_check": arm64/boot/dts/renesas/r8a779a0-falcon.dt.yaml: interrupt-controller@f1000000: 'power-domains' does not match any of the regexes: '^(msi-controller|gic-its|interrupt-controller)@[0-9a-f]+$', '^gic-its@', '^interrupt-controller@[0-9a-f]+$', 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml Remove the "power-domains" property, as the GIC on R-Car V3U is always-on, and not part of a clock domain. Fixes: 834c310f541839b6 ("arm64: dts: renesas: Add Renesas R8A779A0 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/a9ae5cbc7c586bf2c6b18ddc665ad7051bd1d206.1622560236.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
* reset: bail if try_module_get() failsPhilipp Zabel2021-07-201-1/+4
| | | | | | | | | | | | | | [ Upstream commit 4fb26fb83f0def3d39c14e268bcd4003aae8fade ] Abort instead of returning a new reset control for a reset controller device that is going to have its module unloaded. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 61fc41317666 ("reset: Add reset controller API") Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210607082615.15160-1-p.zabel@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: BCM5301X: Fixup SPI bindingRafał Miłecki2021-07-201-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d5aede3e6dd1b8ca574600a1ecafe1e580c53f2f ] 1. Reorder interrupts 2. Fix typo: s/spi_lr_overhead/spi_lr_overread/ 3. Rename node: s/spi-nor@0/flash@0/ This fixes: arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi@18029200: interrupt-names: 'oneOf' conditional failed, one must be fixed: ['spi_lr_fullness_reached', 'spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted'] is too long Additional items are not allowed ('spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted' were unexpected) 'mspi_done' was expected 'spi_l1_intr' was expected 'mspi_halted' was expected 'spi_lr_fullness_reached' was expected 'spi_lr_session_aborted' was expected 'spi_lr_impatient' was expected 'spi_lr_session_done' was expected 'spi_lr_overread' was expected From schema: Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi-nor@0: $nodename:0: 'spi-nor@0' does not match '^flash(@.*)?$' From schema: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* dt-bindings: i2c: at91: fix example for scl-gpiosNicolas Ferre2021-07-201-1/+1
| | | | | | | | | | | | | [ Upstream commit 92e669017ff1616ba7d8ba3c65f5193bc2a7acbe ] The SCL gpio pin used by I2C bus for recovery needs to be configured as open drain, so fix the binding example accordingly. In relation with fix c5a283802573 ("ARM: dts: at91: Configure I2C SCL gpio as open drain"). Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Fixes: 19e5cef058a0 ("dt-bindings: i2c: at91: document optional bus recovery properties") Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scmi: Reset Rx buffer to max size during async commandsCristian Marussi2021-07-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0cb7af474e0dbb2f500c67aa62b6db9fafa74de2 ] During an async commands execution the Rx buffer length is at first set to max_msg_sz when the synchronous part of the command is first sent. However once the synchronous part completes the transport layer waits for the delayed response which will be processed using the same xfer descriptor initially allocated. Since synchronous response received at the end of the xfer will shrink the Rx buffer length to the effective payload response length, it needs to be reset again. Raise the Rx buffer length again to max_msg_sz before fetching the delayed response to ensure full response is read correctly from the shared memory. Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: moved reset to scmi_handle_response as it could race with do_xfer_with_response] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* soc: mtk-pm-domains: Fix the clock prepared issueWeiyi Lu2021-07-201-23/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f0fce06e345dc4f75c1cdd21840780f5fe2df1f3 ] In this new power domain driver, when adding one power domain it will prepare the dependent clocks at the same. So we only do clk_bulk_enable/disable control during power ON/OFF. When system suspend, the pm runtime framework will forcely power off power domains. However, the dependent clocks are disabled but kept prepared. In MediaTek clock drivers, PLL would be turned ON when we do clk_bulk_prepare control. Clock hierarchy: PLL --> DIV_CK --> CLK_MUX (may be dependent clocks) --> SUBSYS_CG (may be dependent clocks) It will lead some unexpected clock states during system suspend. This patch will fix by doing prepare_enable/disable_unprepare on dependent clocks at the same time while we are going to power on/off any power domain. Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains") Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: chun-jie.chen <chun-jie.chen@mediatek.com> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210601035905.2970384-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* soc: mtk-pm-domains: do not register smi node as sysconHsin-Yi Wang2021-07-201-3/+8
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit eed6ff1bb2da65067d928f4ab322c7d75f944fa4 ] Mediatek requires mmsys clocks to be unprepared during suspend, otherwise system has chances to hang. syscon_regmap_lookup_by_phandle_optional() will attach and prepare the first clock in smi node, leading to additional prepare to the clock which is not balanced with the prepare/unprepare pair in resume/suspend callbacks. If a power domain node requests an smi node and the smi node's first clock is an mmsys clock, it will results in an unstable suspend resume. Fixes: f414854c8843 ("soc: mediatek: pm-domains: Add SMI block as bus protection block") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: chun-jie.chen <chun-jie.chen@mediatek.com> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210601035905.2970384-2-hsinyi@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: tegra: Fix error return code in tegra210_bpmp_init()Zhen Lei2021-07-201-1/+1
| | | | | | | | | | | | | | [ Upstream commit 7fea67710e9f6a111a2c9440576f2396ccd92d57 ] When call irq_get_irq_data() to get the IRQ's irq_data failed, an appropriate error code -ENOENT should be returned. However, we directly return 'err', which records the IRQ number instead of the error code. Fixes: 139251fc2208 ("firmware: tegra: add bpmp driver for Tegra210") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: qcom: c630: Add no-hpd to DSI bridge nodeStephen Boyd2021-07-201-0/+2
| | | | | | | | | | | | | | | | | | | | [ Upstream commit c0dcfe6a784fdf7fcc0fdc74bfbb06e9f77de964 ] We should indicate that we're not using the HPD pin on this device, per the binding document. Otherwise if code in the future wants to enable HPD in the bridge when this property is absent we'll be enabling HPD when it isn't supposed to be used. Presumably this board isn't using hpd on the bridge. Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Steev Klimaszewski <steev@kali.org> Fixes: 956e9c85f47b ("arm64: dts: qcom: c630: Define eDP bridge and panel") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210324231424.2890039-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: qcom: trogdor: Add no-hpd to DSI bridge nodeStephen Boyd2021-07-201-0/+2
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5f551b5ce55575b14c26933fe9b49365ea246b3d ] We should indicate that we're not using the HPD pin on this device, per the binding document. Otherwise if code in the future wants to enable HPD in the bridge when this property is absent we'll be wasting power powering hpd when we don't use it on trogdor boards. We didn't notice this before because the kernel driver blindly disables hpd, but that won't be true for much longer. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210324025534.1837405-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoMMarek Vasut2021-07-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 1cebcf9932ab76102e8cfc555879574693ba8956 ] The Microchip LAN8710Ai PHY requires XTAL1/CLKIN external clock to be enabled when the nRST is toggled according to datasheet Microchip LAN8710A/LAN8710Ai DS00002164B page 35 section 3.8.5.1 Hardware Reset: " A Hardware reset is asserted by driving the nRST input pin low. When driven, nRST should be held low for the minimum time detailed in Section 5.5.3, "Power-On nRST & Configuration Strap Timing," on page 59 to ensure a proper transceiver reset. During a Hardware reset, an external clock must be supplied to the XTAL1/CLKIN signal. " This is accidentally fulfilled in the current setup, where ETHCK_K is used to supply both PHY XTAL1/CLKIN and is also fed back through eth_clk_fb to supply ETHRX clock of the DWMAC. Hence, the DWMAC enables ETHRX clock, that has ETHCK_K as parent, so ETHCK_K clock are also enabled, and then the PHY reset toggles. However, this is not always the case, e.g. in case the PHY XTAL1/CLKIN clock are supplied by some other clock source than ETHCK_K or in case ETHRX clock are not supplied by ETHCK_K. In the later case, ETHCK_K would be kept disabled, while ETHRX clock would be enabled, so the PHY would not be receiving XTAL1/CLKIN clock and the reset would fail. Improve the DT by adding the PHY clock phandle into the PHY node, which then also requires moving the PHY reset GPIO specifier in the same place and that then also requires correct PHY reset GPIO timing, so add that too. A brief note regarding the timing, the datasheet says the reset should stay asserted for at least 100uS and software should wait at least 200nS after deassertion. Set both delays to 500uS which should be plenty. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: r8a7796[01]: Fix OPP table entry voltagesGeert Uytterhoeven2021-07-202-6/+6
| | | | | | | | | | | | | | | | | | [ Upstream commit 659b38203f04f5c3d1dc60f1a3e54b582ad3841c ] Correct the voltages in the "Power Optimized" (<= 1.5 GHz) Cortex-A57 operating point table entries for the R-Car M3-W and M3-W+ SoCs from 0.82V to 0.83V, as per the R-Car Gen3 EC Manual Errata for Revision 0.53. Based on a patch for R-Car M3-W in the BSP by Takeshi Kihara <takeshi.kihara.df@renesas.com>. Fixes: da7e3113344fda50 ("arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices") Fixes: f51746ad7d1ff6b4 ("arm64: dts: renesas: Add Renesas R8A77961 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/b9e9db907514790574429b83d070c823b36085ef.1619699909.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: renesas: Add missing opp-suspend propertiesGeert Uytterhoeven2021-07-203-0/+3
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 44b615ac9fab16d1552cd8360454077d411e3c35 ] Tag the highest "Power Optimized" (1.5 GHz) Cortex-A57 operating point table entries for the RZ/G2M, R-Car M3-W and M3-W+ SoCs with the "opp-suspend" property. This makes sure the system will enter suspend in the same performance state as it will be resumed by the firmware later, avoiding state inconsistencies after resume. Based on a patch for R-Car M3-W in the BSP by Takeshi Kihara <takeshi.kihara.df@renesas.com>. Fixes: 800037e815b91d8c ("arm64: dts: renesas: r8a774a1: Add operating points") Fixes: da7e3113344fda50 ("arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices") Fixes: f51746ad7d1ff6b4 ("arm64: dts: renesas: Add Renesas R8A77961 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/45a061c3b0463aac7d10664f47c4afdd999da50d.1619699721.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: ti: j7200-main: Enable USB2 PHY RX sensitivity workaroundRoger Quadros2021-07-201-0/+1
| | | | | | | | | | | | | | | [ Upstream commit a2894d85f44ba3f2bdf5806c8dc62e2ec40c1c09 ] Enable work around feature built into the controller to address issue with RX Sensitivity for USB2 PHY. Fixes: 6197d7139d12 ("arm64: dts: ti: k3-j7200-main: Add USB controller") Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210512153308.5840-1-a-govindraju@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: qcom: sdm845-oneplus-common: guard rmtfs-memCaleb Connolly2021-07-201-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e60fd5ac1f6851be5b2c042b39584bfcf8a66f57 ] The rmtfs_mem region is a weird one, downstream allocates it dynamically, and supports a "qcom,guard-memory" property which when set will reserve 4k above and below the rmtfs memory. A common from qcom 4.9 kernel msm_sharedmem driver: /* * If guard_memory is set, then the shared memory region * will be guarded by SZ_4K at the start and at the end. * This is needed to overcome the XPU limitation on few * MSM HW, so as to make this memory not contiguous with * other allocations that may possibly happen from other * clients in the system. */ When the kernel tries to touch memory that is too close the rmtfs region it may cause an XPU violation. Such is the case on the OnePlus 6 where random crashes would occur usually after boot. Reserve 4k above and below the rmtfs_mem to avoid hitting these XPU Violations. This doesn't entirely solve the random crashes on the OnePlus 6/6T but it does seem to prevent the ones which happen shortly after modem bringup. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210502014146.85642-4-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-14 09:03:32 +0000