linux-stable.git/drivers/soc, branch v6.8.2

soc: fsl: dpio: fix kcalloc() argument order

2024-03-26T22:17:32+00:00

[ Upstream commit 72ebb41b88f9d7c10c5e159e0507074af0a22fe2 ]

A previous bugfix added a call to kcalloc(), which starting in gcc-14
causes a harmless warning about the argument order:

drivers/soc/fsl/dpio/dpio-service.c: In function 'dpaa2_io_service_enqueue_multiple_desc_fq':
drivers/soc/fsl/dpio/dpio-service.c:526:29: error: 'kcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
  526 |         ed = kcalloc(sizeof(struct qbman_eq_desc), 32, GFP_KERNEL);
      |                             ^~~~~~
drivers/soc/fsl/dpio/dpio-service.c:526:29: note: earlier argument should specify number of elements, later size of each element

Since the two are only multiplied, the order does not change the
behavior, so just fix it now to shut up the compiler warning.

Dmity independently came up with the same fix.

Fixes: 5c4a5999b245 ("soc: fsl: dpio: avoid stack usage warning")
Reported-by: Dmitry Antipov 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Sasha Levin

soc: qcom: llcc: Check return value on Broadcast_OR reg read

2024-03-26T22:16:43+00:00

[ Upstream commit ceeaddc19a90039861564d8e1078b778a8f95101 ]

Commit c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support")
introduced a new 4.1 if statement in llcc_update_act_ctrl() without
considering that ret might be overwritten. So, add return value check
after Broadcast_OR register read in llcc_update_act_ctrl().

Fixes: c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support")
Signed-off-by: Unnathi Chalicheemala 
Reviewed-by: Elliot Berman 
Reviewed-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20240212183515.433873-1-quic_uchalich@quicinc.com
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

soc: qcom: socinfo: rename PM2250 to PM4125

2024-03-26T22:16:34+00:00

[ Upstream commit 5155e48128826d0c5999dc9f47aa746df54da448 ]

It seems, the only actual mentions of PM2250 can be found are related to
the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a
PMIC name. Rename PM2250 to PM4125 to follow the documentation.

Fixes: 082f9bc60f33 ("soc: qcom: spmi-pmic: add more PMIC SUBTYPE IDs")
Fixes: 112d96fd2927 ("soc: qcom: socinfo: Add some PMICs")
Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20240128-pm2250-pm4125-rename-v2-1-d51987e9f83a@linaro.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

Merge tag 'drm-misc-fixes-2024-02-29' of https://anongit.freedesktop.org/git/drm/drm-misc into drm-fixes

2024-03-01T03:13:06+00:00

A reset fix for host1x, a resource leak fix and a probe fix for aux-hpd,
a use-after-free fix and a boot fix for a pmic_glink qcom driver in
drivers/soc, a fix for the simpledrm/tegra transition, a kunit fix for
the TTM tests, a font handling fix for fbcon, two allocation fixes and a
kunit test to cover them for drm/buddy

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20240229-angelic-adorable-teal-fbfabb@houat

Merge drm/drm-fixes into drm-misc-fixes

2024-02-26T14:23:00+00:00

Sima needs a more recent release to apply a patch.

Signed-off-by: Maxime Ripard

soc: qcom: pmic_glink: Fix boot when QRTR=m

2024-02-23T15:03:52+00:00

We need to bail out before adding/removing devices if we are going to
-EPROBE_DEFER. Otherwise boot can get stuck in a probe deferral loop due
to a long-standing issue in driver core (see commit fbc35b45f9f6 ("Add
documentation on meaning of -EPROBE_DEFER")).

Deregistering the altmode child device can potentially also trigger bugs
in the DRM bridge implementation, which does not expect bridges to go
away.

[DB: slightly fixed commit message by adding the word 'commit']
Suggested-by: Dmitry Baryshkov 
Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20231213210644.8702-1-robdclark@gmail.com
[ johan: rebase on 6.8-rc4, amend commit message and mention DRM ]
Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
Cc:       # 6.3
Cc: Bjorn Andersson 
Signed-off-by: Johan Hovold 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Neil Armstrong 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20240217150228.5788-5-johan+linaro@kernel.org

soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free

2024-02-23T15:03:46+00:00

A recent DRM series purporting to simplify support for "transparent
bridges" and handling of probe deferrals ironically exposed a
use-after-free issue on pmic_glink_altmode probe deferral.

This has manifested itself as the display subsystem occasionally failing
to initialise and NULL-pointer dereferences during boot of machines like
the Lenovo ThinkPad X13s.

Specifically, the dp-hpd bridge is currently registered before all
resources have been acquired which means that it can also be
deregistered on probe deferrals.

In the meantime there is a race window where the new aux bridge driver
(or PHY driver previously) may have looked up the dp-hpd bridge and
stored a (non-reference-counted) pointer to the bridge which is about to
be deallocated.

When the display controller is later initialised, this triggers a
use-after-free when attaching the bridges:

	dp -> aux -> dp-hpd (freed)

which may, for example, result in the freed bridge failing to attach:

	[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16

or a NULL-pointer dereference:

	Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
	...
	Call trace:
	  drm_bridge_attach+0x70/0x1a8 [drm]
	  drm_aux_bridge_attach+0x24/0x38 [aux_bridge]
	  drm_bridge_attach+0x80/0x1a8 [drm]
	  dp_bridge_init+0xa8/0x15c [msm]
	  msm_dp_modeset_init+0x28/0xc4 [msm]

The DRM bridge implementation is clearly fragile and implicitly built on
the assumption that bridges may never go away. In this case, the fix is
to move the bridge registration in the pmic_glink_altmode driver to
after all resources have been looked up.

Incidentally, with the new dp-hpd bridge implementation, which registers
child devices, this is also a requirement due to a long-standing issue
in driver core that can otherwise lead to a probe deferral loop (see
commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).

[DB: slightly fixed commit message by adding the word 'commit']
Fixes: 080b4e24852b ("soc: qcom: pmic_glink: Introduce altmode support")
Fixes: 2bcca96abfbf ("soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE")
Cc:       # 6.3
Cc: Bjorn Andersson 
Cc: Dmitry Baryshkov 
Signed-off-by: Johan Hovold 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20240217150228.5788-4-johan+linaro@kernel.org

Merge tag 'riscv-soc-drivers-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes

2024-02-23T12:53:54+00:00

RISC-V SoC driver fixes for v6.8-rc6

A fix for a kconfig symbol whose help text has been unhelpful since its
introduction.

Signed-off-by: Conor Dooley 

* tag 'riscv-soc-drivers-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  soc: microchip: Fix POLARFIRE_SOC_SYS_CTRL input prompt

Link: https://lore.kernel.org/r/20240221-irate-outrage-cf7f96f83074@spud
Signed-off-by: Arnd Bergmann

soc: apple: mailbox: error pointers are negative integers

2024-01-30T19:34:49+00:00

In an entirely unrelated discussion where I pointed out a stupid thinko
of mine, Rasmus piped up and noted that that obvious mistake already
existed elsewhere in the kernel tree.

An "error pointer" is the negative error value encoded as a pointer,
making the whole "return error or valid pointer" use-case simple and
straightforward.  We use it all over the kernel.

But the key here is that errors are _negative_ error numbers, not the
horrid UNIX user-level model of "-1 and the value of 'errno'".

The Apple mailbox driver used the positive error values, and thus just
returned invalid normal pointers instead of actual errors.

Of course, the reason nobody ever noticed is that the errors presumably
never actually happen, so this is fixing a conceptual bug rather than an
actual one.

Reported-by: Rasmus Villemoes 
Link: https://lore.kernel.org/all/5c30afe0-f9fb-45d5-9333-dd914a1ea93a@prevas.dk/
Signed-off-by: Linus Torvalds

soc: microchip: Fix POLARFIRE_SOC_SYS_CTRL input prompt

2024-01-22T16:39:40+00:00

The symbol's prompt should be a one-line description, instead of just
duplicating the symbol name.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Conor Dooley