linux-stable.git/drivers/soc, branch v5.16.9

Revert "ASoC: mediatek: Check for error clk pointer"

2022-02-08T17:35:11+00:00

This reverts commit e0bf3c9e05ca6837ac756ec7d9de70b44603da12 which is
commit 9de2b9286a6dd16966959b3cb34fc2ddfd39213e upstream

With this patch in the tree, Chromebooks running the affected hardware
no longer boot. Bisect points to this patch, and reverting it fixes
the problem.

An analysis of the code with this patch applied shows:

        ret = init_clks(pdev, clk);
        if (ret)
                return ERR_PTR(ret);
...
                for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
                        struct clk *c = clk[data->clk_id[j]];

                        if (IS_ERR(c)) {
                                dev_err(&pdev->dev, "%s: clk unavailable\n",
                                        data->name);
                                return ERR_CAST(c);
                        }

                        scpd->clk[j] = c;
                }

Not all clocks in the clk_names array have to be present. Only the clocks
in the data->clk_id array are actually needed. The code already checks if
the required clocks are available and bails out if not. The assumption that
all clocks have to be present is wrong, and commit 9de2b9286a6d needs to be
reverted.

Fixes: 9de2b9286a6d ("ASoC: mediatek: Check for error clk pointer")
Cc: Jiasheng Jiang 
Cc: Mark Brown 
Cc: James Liao 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Daniel Golle 
Link: https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

PM: AVS: qcom-cpr: Use div64_ul instead of do_div

2022-01-27T11:02:26+00:00

[ Upstream commit 92c550f9ffd2884bb5def52b5c0485a35e452784 ]

do_div() does a 64-by-32 division. Here the divisor is an unsigned long
which on some platforms is 64 bit wide. So use div64_ul instead of do_div
to avoid a possible truncation.

Reported-by: Zeal Robot 
Signed-off-by: Changcheng Deng 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20211125014311.45942-1-deng.changcheng@zte.com.cn
Signed-off-by: Sasha Levin

soc: ti: pruss: fix referenced node in error message

2022-01-27T11:02:16+00:00

[ Upstream commit 8aa35e0bb5eaa42bac415ad0847985daa7b4890c ]

So far, "(null)" is reported for the node that is missing clocks.

Signed-off-by: Jan Kiszka 
Acked-by: Suman Anna 
Signed-off-by: Nishanth Menon 
Link: https://lore.kernel.org/r/d6e24953-ea89-fd1c-6e16-7a0142118054@siemens.com
Signed-off-by: Sasha Levin

soc: imx: gpcv2: Synchronously suspend MIX domains

2022-01-27T11:02:16+00:00

[ Upstream commit f756f435f7dd823f2d4bd593ce1bf3168def1308 ]

In case the following power domain sequence happens, iMX8M Mini always hangs:
  gpumix:on -> gpu:on -> gpu:off -> gpu:on
This is likely due to another quirk of the GPC block. This situation can be
prevented by always synchronously powering off both the domain and MIX domain.
Make it so. This turns the aforementioned sequence into:
  gpumix:on -> gpu:on -> gpu:off -> gpumix:off -> gpumix:on -> gpu:on

Signed-off-by: Marek Vasut 
Cc: Frieder Schrempf 
Cc: Lucas Stach 
Cc: NXP Linux Team 
Cc: Peng Fan 
Cc: Shawn Guo 
Acked-by: Lucas Stach 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

ASoC: mediatek: Check for error clk pointer

2022-01-27T11:02:08+00:00

[ Upstream commit 9de2b9286a6dd16966959b3cb34fc2ddfd39213e ]

Yes, you are right and now the return code depending on the
init_clks().

Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform")
Signed-off-by: Jiasheng Jiang 
Link: https://lore.kernel.org/r/20211222015157.1025853-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

soc: imx: gpcv2: keep i.MX8MM VPU-H1 bus clock active

2022-01-27T11:01:33+00:00

[ Upstream commit 8361b8b29f9389084b679db854cf733375c64763 ]

Enable the vpu-h1 clock when the domain is active because reading
or writing to the VPU-H1 IP block cause the system to hang.

Fixes: 656ade7aa42a ("soc: imx: gpcv2: keep i.MX8M* bus clocks enabled")
Signed-off-by: Adam Ford 
Reviewed-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

Merge tag 'tegra-for-5.16-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes

2021-12-16T14:02:26+00:00

soc/tegra: Fixes for v5.16-rc6

This contains a single build fix without which ARM allmodconfig builds
are broken if -Werror is enabled.

* tag 'tegra-for-5.16-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  soc/tegra: fuse: Fix bitwise vs. logical OR warning

Link: https://lore.kernel.org/r/20211215162618.3568474-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann

soc/tegra: fuse: Fix bitwise vs. logical OR warning

2021-12-15T16:19:06+00:00

A new warning in clang points out two instances where boolean
expressions are being used with a bitwise OR instead of logical OR:

drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                reg = tegra_fuse_read_spare(i) |
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                               ||
drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                reg = tegra_fuse_read_spare(i) |
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                               ||
drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
2 warnings generated.

The motivation for the warning is that logical operations short circuit
while bitwise operations do not.

In this instance, tegra_fuse_read_spare() is not semantically returning
a boolean, it is returning a bit value. Use u32 for its return type so
that it can be used with either bitwise or boolean operators without any
warnings.

Fixes: 25cd5a391478 ("ARM: tegra: Add speedo-based process identification")
Link: https://github.com/ClangBuiltLinux/linux/issues/1488
Suggested-by: Michał Mirosław 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Thierry Reding

soc: imx: Register SoC device only on i.MX boards

2021-12-08T12:30:00+00:00

At the moment, using the ARM32 multi_v7_defconfig always results in two
SoCs being exposed in sysfs. This is wrong, as far as I'm aware the
Qualcomm DragonBoard 410c does not actually make use of a i.MX SoC. :)

  qcom-db410c:/sys/devices/soc0$ grep . *
  family:Freescale i.MX
  machine:Qualcomm Technologies, Inc. APQ 8016 SBC
  revision:0.0
  serial_number:0000000000000000
  soc_id:Unknown

  qcom-db410c:/sys/devices/soc1$ grep . *
  family:Snapdragon
  machine:APQ8016
  ...

This happens because imx_soc_device_init() registers the soc device
unconditionally, even when running on devices that do not make use of i.MX.
Arnd already reported this more than a year ago and even suggested a fix
similar to this commit, but for some reason it was never submitted.

Fix it by checking if the "__mxc_cpu_type" variable was actually
initialized by earlier platform code. On devices without i.MX it will
simply stay 0.

Cc: Peng Fan 
Fixes: d2199b34871b ("ARM: imx: use device_initcall for imx_soc_device_init")
Reported-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/CAK8P3a0hxO1TmK6oOMQ70AHSWJnP_CAq57YMOutrxkSYNjFeuw@mail.gmail.com/
Signed-off-by: Stephan Gerhold 
Reviewed-by: Fabio Estevam 
Reviewed-by: Peng Fan 
Signed-off-by: Shawn Guo

soc: imx: imx8m-blk-ctrl: Fix imx8mm mipi reset

2021-12-06T02:28:30+00:00

Most of the blk-ctrl reset bits are found in one register, however
there are two bits in offset 8 for pulling the MIPI DPHY out of reset
and one of them needs to be set when IMX8MM_DISPBLK_PD_MIPI_CSI is brought
out of reset or the MIPI_CSI hangs.

Since MIPI_DSI is impacted, add the additional one for MIPI_DSI too.

Fixes: 926e57c065df ("soc: imx: imx8m-blk-ctrl: add DISP blk-ctrl")
Signed-off-by: Adam Ford 
Reviewed-by: Fabio Estevam 
Reviewed-by: Lucas Stach 
Reviewed-by: Laurent Pinchart 
Tested by: Tim Harvey 
Signed-off-by: Shawn Guo