kernel/linux.git/drivers/soc, branch linux-5.11.y

soc: mediatek: pm-domains: Add a power domain names for mt8192

2021-05-19T08:30:01+00:00

commit 3edc01bc53c639b1c98f57e7f1c026aae6a25a62 upstream. Add the power domains names for the mt8192 SoC. Fixes: a49d5e7a89d6 ("soc: mediatek: pm-domains: Add support for mt8192") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-3-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman

soc: mediatek: pm-domains: Add a power domain names for mt8183

2021-05-19T08:30:01+00:00

commit e57b8112258ed46dff23b49d6e400f54a8dbf1c3 upstream. Add the power domains names for the mt8183 SoC. This removes the debugfs errors like the following: debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! Fixes: eb9fa767fbe1 ("soc: mediatek: pm-domains: Add support for mt8183") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-2-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman

soc: mediatek: pm-domains: Add a meaningful power domain name

2021-05-19T08:30:00+00:00

commit 022b02b4505ecea5eda02b18683531e49f7d8eb7 upstream. Add the power domains names to the power domain struct so we have meaningful name for every power domain. This also removes the following debugfs error message. [ 2.242068] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.249949] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.257784] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! ... Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210225175000.824661-1-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman

soc: aspeed: fix a ternary sign expansion bug

2021-05-14T08:49:51+00:00

[ Upstream commit 5ffa828534036348fa90fb3079ccc0972d202c4a ] The intent here was to return negative error codes but it actually returns positive values. The problem is that type promotion with ternary operations is quite complicated. "ret" is an int. "copied" is a u32. And the snoop_file_read() function returns long. What happens is that "ret" is cast to u32 and becomes positive then it's cast to long and it's still positive. Fix this by removing the ternary so that "ret" is type promoted directly to long. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Dan Carpenter Signed-off-by: Joel Stanley Reviewed-by: Patrick Venture Link: https://lore.kernel.org/r/YIE90PSXsMTa2Y8n@mwanda Link: https://lore.kernel.org/r/20210423000919.1249474-1-joel@jms.id.au' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin

soc: qcom: mdt_loader: Detect truncated read of segments

2021-05-14T08:49:46+00:00

[ Upstream commit 0648c55e3a21ccd816e99b6600d6199fbf39d23a ] Given that no validation of how much data the firmware loader read in for a given segment truncated segment files would best case result in a hash verification failure, without any indication of what went wrong. Improve this by validating that the firmware loader did return the amount of data requested. Fixes: 445c2410a449 ("soc: qcom: mdt_loader: Use request_firmware_into_buf()") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107232526.716989-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

soc: qcom: mdt_loader: Validate that p_filesz < p_memsz

2021-05-14T08:49:46+00:00

[ Upstream commit 84168d1b54e76a1bcb5192991adde5176abe02e3 ] The code validates that segments of p_memsz bytes of a segment will fit in the provided memory region, but does not validate that p_filesz bytes will, which means that an incorrectly crafted ELF header might write beyond the provided memory region. Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107233119.717173-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

soc: qcom: pdr: Fix error return code in pdr_register_listener

2021-05-14T08:49:45+00:00

[ Upstream commit 769738fc49bb578e05d404b481a9241d18147d86 ] Fix to return the error code -EREMOTEIO from pdr_register_listener rather than 0. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Link: https://lore.kernel.org/r/20201125065034.154217-1-miaoqinglang@huawei.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

soc/tegra: regulators: Fix locking up when voltage-spread is out of range

2021-05-14T08:49:24+00:00

commit ef85bb582c41524e9e68dfdbde48e519dac4ab3d upstream. Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. Fixes: 783807436f36 ("soc/tegra: regulators: Add regulators coupler for Tegra30") Cc: stable@vger.kernel.org Reported-by: Peter Geis Tested-by: Peter Geis # Ouya T30 Tested-by: Matt Merhar # Ouya T30 Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman

soc/tegra: pmc: Fix completion of power-gate toggling

2021-05-12T06:37:15+00:00

[ Upstream commit c45e66a6b9f40f2e95bc6d97fbf3daa1ebe88c6b ] The SW-initiated power gate toggling is dropped by PMC if there is contention with a HW-initiated toggling, i.e. when one of CPU cores is gated by cpuidle driver. Software should retry the toggling after 10 microseconds on Tegra20/30 SoCs, hence add the retrying. On Tegra114+ the toggling method was changed in hardware, the TOGGLE_START bit indicates whether PMC is busy or could accept the command to toggle, hence handle that bit properly. The problem pops up after enabling dynamic power gating of 3D hardware, where 3D power domain fails to turn on/off "randomly". The programming sequence and quirks are documented in TRMs, but PMC driver obliviously re-used the Tegra20 logic for Tegra30+, which strikes back now. The 10 microseconds and other timeouts aren't documented in TRM, they are taken from downstream kernel. Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commit;h=311dd1c318b70e93bcefec15456a10ff2b9eb0ff Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=commit;h=7f36693c47cb23730a6b2822e0975be65fb0c51d Tested-by: Peter Geis # Ouya T30 Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar # Ouya T30 Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

soc: qcom: geni: shield geni_icc_get() for ACPI boot

2021-04-28T11:41:49+00:00

[ Upstream commit 0c9fdcdba68208270ae85d39600ea97da1718344 ] Currently, GENI devices like i2c-qcom-geni fails to probe in ACPI boot, if interconnect support is enabled. That's because interconnect driver only supports DT right now. As interconnect is not necessarily required for basic function of GENI devices, let's shield geni_icc_get() call, and then all other ICC calls become nop due to NULL icc_path, so that GENI devices keep working for ACPI boot. Reviewed-by: Bjorn Andersson Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210114112928.11368-1-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin