lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdX+baSFtX-U-w4CBSqMsceDS+RoQY55qs=SmyydK6BLVA@mail.gmail.com>
Date: Tue, 17 Dec 2024 14:42:07 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	Kieran Bingham <kieran.bingham+renesas@...asonboard.com>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, 
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, 
	LUU HOAI <hoai.luu.ub@...esas.com>, Jagan Teki <jagan@...rulasolutions.com>, 
	Sam Ravnborg <sam@...nborg.org>, Biju Das <biju.das.jz@...renesas.com>, 
	dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, linux-clk@...r.kernel.org, 
	Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>, 
	Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add
 DisplayPort support

CC Saravana

On Tue, Dec 17, 2024 at 2:29 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Mon, Dec 16, 2024 at 2:33 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> > <tomi.valkeinen@...asonboard.com> wrote:
> > > From: Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>
> > >
> > > Add support for the mini DP output on the Gray Hawk board.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
> > > Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
> >
> > Thanks for your patch, which is now commit b1000645dc29701f
> > ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
> > in renesas-devel/renesas-dts-for-v6.14.
> >
> > Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
> > v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
> > when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
> > is not available, the ti_sn65dsi86.bridge part fails to probe with
> > -EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
> > driver must do something critical, as resuming from s2idle now hangs.
> > I haven't identified yet where exactly it hangs.
> >
> > As a result, s2idle is broken in current renesas-devel, which only
> > has the DTS changes.  Perhaps I should drop the DTS until the issue
> > is resolved?
> >
> > However, I suspect White Hawk has the same issue (if
> > CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
> > Hawk is currently not available for kernel testing.
>
> Confirmed on White Hawk by Tomi and me.
>
> When the hang occurs, magic sysrq no longer works. However, the system
> still prints "nfs server not responding" once in a while, so I added
> calls to various sysrq print functions to rpc_check_timeout().
> This revealed that the system is blocked on wait_for_completion()
> in dpm_wait_for_superior(), called from device_resume_noirq().
> Printing the actual device and parent gives:
>
>     platform fed80000.dsi-encoder: PM: device_resume_noirq
>     platform fed80000.dsi-encoder: PM: dpm_wait_for_superior: parent fed80000.dsi-encoder

So it's waiting for itself, i.e. deadlock :-(

When the DSI driver is available:

    rcar-mipi-dsi fed80000.dsi-encoder: PM: device_resume_noirq:627
    rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:280
    rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:296:
parent fed80000.dsi-encoder

still waiting for itself, but it does continue!
Note that the fed80000.dsi-encoder block is now bound, and
"rcar-mipi-dsi" is printed instead of "platform".

fw_devlink issue?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ