Hi Mark, On Tue, Dec 05, 2023 at 04:13:41PM +0000, Mark Brown wrote: > On Sun, Dec 03, 2023 at 02:53:13PM +0300, Dmitry Baryshkov wrote: > > > Each of connectors and CRTCs used by the DRM device provides debugfs > > directory, which is used by several standard debugfs files and can > > further be extended by the driver. Add such generic debugfs directories > > for encoder. > > Today's -next fails to boot an imx_v6_v7_defconfig on at least the UDOO > dual and quad platforms, based on i.MX6DL and i.MX6Q respectively. > multi_v7_defconfig looks fine on the same boards, it's just the i.MX > specific config that's failing. Nothing else in my CI appears impacted. > We get a NULL pointer defererence while bringing up the display > subsystem: > > [ 1.392715] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops 0xc0f9a490) > [ 1.400013] imx-drm display-subsystem: bound 120000.hdmi (ops 0xc0f9af80) > [ 1.407193] 8<--- cut here --- > [ 1.410256] Unable to handle kernel NULL pointer dereference at virtual address 00000010 when read > > ... > > [ 1.891882] drm_debugfs_encoder_add from drm_encoder_register_all+0x20/0x60 > [ 1.898954] drm_encoder_register_all from drm_modeset_register_all+0x34/0x70 > [ 1.906116] drm_modeset_register_all from drm_dev_register+0x140/0x288 > [ 1.912765] drm_dev_register from imx_drm_bind+0xd0/0x128 > [ 1.918284] imx_drm_bind from try_to_bring_up_aggregate_device+0x164/0x1c4 > [ 1.925275] try_to_bring_up_aggregate_device from __component_add+0x90/0x13c > > Full log at: > > https://lava.sirena.org.uk/scheduler/job/308781 > > A bisect identfied this patch (in -next as caf525ed45b4960b4) as being > the commit that introduced the issue, bisect log below. I've not done > any other investigation but the commit does seem plausibly related to > the backtrace in the oops. I think it's the same issue than the one fixed by: https://lore.kernel.org/all/20231205130631.3456986-1-m.szyprowski@xxxxxxxxxxx/ Maxime
Attachment:
signature.asc
Description: PGP signature
