linux-kernel - Re: mt6358-regulator does not probe automatically on MT8183 and MT8186 Chromebooks

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: <44580fb7-a0ab-41c9-a4e7-fe053742883a@gmail.com>
Date: Sun, 22 Dec 2024 00:30:57 +0300
From: Alper Nebi Yasak <alpernebiyasak@...il.com>
To: Mark Brown <broonie@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: mt6358-regulator does not probe automatically on MT8183 and
 MT8186 Chromebooks

Hi,

On 2024-12-21 18:38 +03:00, Alper Nebi Yasak wrote:
> Hello,
> 
> I'm left with one small problem trying to boot Debian on MT8183 and 
> MT8186 Chromebooks (Cozmo and Magneton respectively). I see a lot of 
> probe deferrals and get dropped into an initramfs shell. All of them 
> get resolved if I run `modprobe mt6358-regulator`, after which I can 
> exit the initramfs shell to continue booting.
> 
> It has been happening for a long time, still unsolved as of v6.12 and 
> next-20241220. I am using `softdep mediatek-drm pre: mt6358-regulator`
> and so on in /etc/modprobe.d/ to trigger it to probe, as a workaround. 
> 
> But I would like if it was solved upstream so distro kernels can work 
> "out of the box". Any ideas why isn't it probing automatically, and how
> to make it so it works?
> 
> More info from a serial connection below (on mt8183-kukui-jacuzzi-cozmo):
> 
> [...]

I found this patch [1] from Matthias, sent around 2021 about adding an
OF match table to the driver, which fixes this problem for my boards.

[1]
https://lore.kernel.org/linux-mediatek/20210112100659.19350-1-matthias.bgg@kernel.org/T/#u


There on 2021-01-12 13:52, Mark Brown wrote:
> As previously discussed it'd be better to fix the binding document to
> deprecate the requirement for the compatible and remove the usage from
> the MFD.

This doesn't seem to have happened in the last almost-four years, so
please reconsider resending/applying the patch.