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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8f9ae0f1-130f-482c-b0a2-d5a403639099@gmail.com>
Date: Fri, 23 May 2025 15:58:10 +0300
From: Alper Nebi Yasak <alpernebiyasak@...il.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Mark Brown <broonie@...nel.org>
Cc: Matthias Brugger <matthias.bgg@...il.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

Hello again,

On 2024-12-23 14:21 +03:00, AngeloGioacchino Del Regno wrote:
> Il 21/12/24 16:38, Alper Nebi Yasak ha scritto:
>> 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):
>>
> 
> It's a bit odd, thanks for reporting.
> 
> I'll check that next year........ (which is really in 2 weeks anyway, but it's fun
> to say)

I couldn't manage to ping you for this, let alone look further into it
until now. It has been a while, I assume it's still not fixed, do you
need me to test again?

> Btw, that softdep is obviously not right, but I think I shouldn't even have pointed
> that out; still, better safe than sorry, anyway.

Yep, that was just a debug trick I use. My current workaround is using
CONFIG_MFD_MT6397=y and CONFIG_REGULATOR_MT6358=y like everyone else (as
in the defconfig).


On 2024-12-23 19:00 +03:00, Mark Brown wrote:
> As indicated in that thread the MFD should register the regulator
> function driver with the name "mt6358-regulator" used by the driver,
> then the existing MODULE_DEVICE_TABLE() will DTRT.

As far as I can see, mt6397-core.c is doing a devm_mfd_add_devices()
call with the necessary data, roughly paraphrasing:

> static const struct mfd_cell mt6358_devs[] = {
>  [...]
> 	}, {
> 		.name = "mt6358-regulator",
> 		.of_compatible = "mediatek,mt6358-regulator"
> 	}, {
>  [...]
> };
> 
> static const struct chip_data mt6358_core = {
> 	.cid_addr = MT6358_SWCID,
> 	.cid_shift = 8,
> 	.cells = mt6358_devs,
> 	.cell_size = ARRAY_SIZE(mt6358_devs),
> 	.irq_init = mt6358_irq_init,
> };
> 
> static int mt6397_probe(struct platform_device *pdev)
> {
> 	int ret;
> 	unsigned int id = 0;
> 	struct mt6397_chip *pmic;
> 	const struct chip_data *pmic_core;
>  [...]
> 	pmic_core = of_device_get_match_data(&pdev->dev);
> 	if (!pmic_core)
> 		return -ENODEV;
>  [...]
> 	ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
> 				   pmic_core->cells, pmic_core->cell_size,
> 				   NULL, 0, pmic->irq_domain);
>  [...]
> 	return ret;
> }
> 
> static const struct of_device_id mt6397_of_match[] = {
>  [...]
> 	}, {
> 		.compatible = "mediatek,mt6358",
> 		.data = &mt6358_core,
> 	}, {
>  [...]
> };
> MODULE_DEVICE_TABLE(of, mt6397_of_match);
> 
> static const struct platform_device_id mt6397_id[] = {
> 	{ "mt6397", 0 },
> 	{ },
> };
> MODULE_DEVICE_TABLE(platform, mt6397_id);
> 
> static struct platform_driver mt6397_driver = {
> 	.probe = mt6397_probe,
> 	.driver = {
> 		.name = "mt6397",
> 		.of_match_table = mt6397_of_match,
> 	},
> 	.id_table = mt6397_id,
> };
> 
> module_platform_driver(mt6397_driver);

It has more things like "mt6359-auxadc" and "mtk-pmic-keys", that also
list compatibles in the non-mfd driver's MODULE_DEVICE_TABLE(of, ...).
See `git grep -C5 '\"mediatek,mt63..\+-' -- drivers/`.

Maybe if the target driver isn't available by the time MFD registers it,
it doesn't try again later? And so people have added the compatibles to
subdevices to let them get another chance to probe?