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: <f0595a07-c722-4eec-88b3-a7a60142e449@leemhuis.info>
Date: Thu, 4 Dec 2025 15:44:55 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: "angelogioacchino.delregno@...labora.com"
 <angelogioacchino.delregno@...labora.com>,
 Matthias Brugger <matthias.bgg@...il.com>
Cc: Evans Jahja <evansjahja13@...il.com>, linux-mediatek@...ts.infradead.org,
 linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: [REGRESSION] mt8183-kukui: dts: changes in dts caused display to
 no longer initialize - Was: Re: mt8183-kukui: drm/mediatek: dts: Invalid
 display hw pipeline when probing mediatek-drm

Lo!

Matthias, AngeloGioacchino, have you maybe looked into regression that
seems to be caused by 72d63fa0563f8 ("arm64: dts: mediatek: mt8183:
Migrate to display controller OF graph")?

Evans Jahja, just to be sure: I suppose it still happens with 6.18
final? And have you tried if reverting the change fixes this ("fix the
issue just by using the dts from the other version" might have changed
other things as well, that's why I'm asking)

Ciao, Thorsten

On 11/28/25 03:59, Evans Jahja wrote:
> Hi,
> 
> There has been a regression in the dts for my system
> mt8183-kukui-krane, where changes in dts/mediatek/mt8183.dtsi broke my
> machine.
> 
> The display works under v6.17.9 but is broken in v6.18-rc7. I was able
> to replicate / fix the issue just by using the dts from the other
> version.
> 
>> On Wed, Nov 26, 2025 at 3:01 AM Evans Jahja <evansjahja13@...il.com> wrote:
>>>
>>> Hi,
>>>
>>> I have a Lenovo IdeaPad Duet Chromebook CT-X636F, detected as Mediatek
>>> krane sku176 board. (mt8183-kukui-krane)
>>>
>>> The display failed to initialize on the mainline kernel (linux
>>> 6.18-rc7). Using the same config, on stable (linux 6.17.9) the display
>>> works fine.
>>>
>>> config: https://bugzilla.kernel.org/show_bug.cgi?id=220803
>>>
>>> With the system on mainline kernel, I was able to check the serial
>>> console, the error on dmesg looks like this:
>>>
>>> [    6.513400] mediatek-drm mediatek-drm.18.auto: Building display
>>> pipeline for MMSYS 0
>>> [    6.514983] mediatek-drm mediatek-drm.18.auto: Display HW Pipeline
>>> built with 9 components.
>>> [    6.515009] mediatek-drm mediatek-drm.18.auto: Invalid display hw
>>> pipeline. Last component: 38 (ret=-2)
>>> [    6.524422] mediatek-drm mediatek-drm.18.auto: probe with driver
>>> mediatek-drm failed with error -22
>>>
>>> Temporarily modifying mtk_drm_drv.c by commenting calls to
>>> mtk_drm_of_ddp_path_build_one CRTC_EXT and CRTC_THIRD allows the
>>> display to function even on mainline. I was also able to add some
>>> logging and determine that building the HW pipeline for CRTC_MAIN
>>> works, but because building CRTC_EXT fails, the entire display would
>>> not initialize.
>>>
> 
> I think this is the issue:
> https://lkml.org/lkml/2025/9/12/1242
> 
> On Wed, Nov 26, 2025 at 2:06 PM Evans Jahja <evansjahja13@...il.com> wrote:
>>
>> Hi Angelo, I was able to isolate the problem further to the dts. After
>> bisecting the arch/arm64/boot/dts/mediatek/ and building the dts, it
>> seems like this is the first commit that introduced the issue on my
>> device.
>>
>> commit e72d63fa0563f8a6e98c10fed3a9ce74dc0536e6 (HEAD)
>> Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> Date:   Thu Jul 24 10:39:08 2025 +0200
>>
>>     arm64: dts: mediatek: mt8183: Migrate to display controller OF graph
>>
>> I am linking my full bisect log here:
>>
>> https://bugzilla.kernel.org/attachment.cgi?id=308962&action=edit
> 
> where we're unconditionally adding mmsys_ep_ext.
> 
> The issue seems to be caused by the recent addition of CRTC_EXT on the
> base mt8183
> 
> Please kindly take a look. Apologies for any mistake, this is my first issue.
> 
> Evans Jahja
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ