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] [thread-next>] [day] [month] [year] [list]
Message-ID: <vhbngoyykm3n2rqcxoabkimt5mzamsqy4talluzy2gt3ddtbfg@4ouxfz57s5uz>
Date: Tue, 1 Jul 2025 14:04:02 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Lee Jones <lee@...nel.org>
Cc: Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Yassine Oudjana <y.oudjana@...tonmail.com>, 
	NĂ­colas F. R. A. Prado <nfraprado@...labora.com>, Fabien Parent <fparent@...libre.com>, Reported-by: 
	Louis-Alexis Eyraud <louisalexis.eyraud@...labora.com>, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org;
Subject: Re: [PATCH] MFD: mt6397: do not use generic name for keypad
 sub-devices

On Tue, Jul 01, 2025 at 11:58:11AM +0100, Lee Jones wrote:
> On Mon, 30 Jun 2025, Dmitry Torokhov wrote:
> 
> > Do not use "mtk-pmic-keys" when creating sub-device for the keypad to
> > make sure the keypad driver will only bind to the sub-device if it has
> > support for the variant/has matching compatible.
> > 
> > Reported-by: Louis-Alexis Eyraud <louisalexis.eyraud@...labora.com>
> > Fixes: 6e31bb8d3a63 ("mfd: mt6397: Add initial support for MT6328")
> > Fixes: de58cee8c6b8 ("mfd: mt6397-core: Add MT6357 PMIC support")
> > Fixes: 4a901e305011 ("mfd: mt6397-core: Add resources for PMIC keys for MT6359")
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > ---
> > 
> > This is not tested so if someone with hardware could try it out that
> > would be great. I *think* it should work...
> 
> My suspicion is that this will not work.  Providing compatible strings
> here is only for device to node matching.  I do not believe the drivers
> will probe using them.

Actually it should. If we check the drivers for "mt6323-rtc" you will
see that MFD core defines a sub-device with this name and similar
compatible, but the RTC platform driver only lists compatible:

dtor@...r-ws:~/kernel/work $ git grep mt6323-rtc -- drivers/
drivers/mfd/mt6397-core.c:              .name = "mt6323-rtc",
drivers/mfd/mt6397-core.c:              .of_compatible = "mediatek,mt6323-rtc",
drivers/rtc/rtc-mt6397.c:       { .compatible = "mediatek,mt6323-rtc", .data = &mt6397_rtc_data },

Driver name that is defined in drivers/rtc/rtc-mt6397.c is "mt6397-rtc"
not "mt6323-rtc". 

And if we look into MFD core we can see how it works: mfd_add_device()
scans the main (parent) device tree node children, locates devices with
matching compatibles, and calls mfd_match_of_node_to_dev() for them. The
latter essentially copies/assigns device tree node to the platform
device that is being created, compatibles and all. From that point
normal binding rules will work and they take into account OF
compatibles; we no longer need to have matching platform driver name to
match.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ