linux-kernel - Re: [PATCH v5 1/2] dt-bindings: regulator: add support for MT6392

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: <CAOwMV_xUWea81rKFE=zD4xWL3rZ5G8cpWm5xJHT_AX=_frLDRQ@mail.gmail.com>
Date:   Tue, 27 Oct 2020 22:16:22 +0100
From:   Fabien Parent <fparent@...libre.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Rob Herring <robh+dt@...nel.org>, lgirdwood@...il.com,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v5 1/2] dt-bindings: regulator: add support for MT6392

Hi Mark,

On Mon, Oct 26, 2020 at 9:36 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Oct 26, 2020 at 07:38:14PM +0100, Fabien Parent wrote:
> > On Mon, Oct 26, 2020 at 6:24 PM Mark Brown <broonie@...nel.org> wrote:
>
> > > >         .name = "mt6392-regulator",
> > > >         .of_compatible = "mediatek,mt6392-regulator"
>
> > > This is still unneeded, it's just a reflection of Linux implementation
> > > details and should be removed.   The MFD can just register the child
> > > without supplying a compatible and things will continue to work just as
> > > well.
>
> > I'm not exactly sure how it is supposed to work. mfd_add_devices seems
> > to register devices based on of_compatible or acpi_match from the
> > mfd_cell. This platform does not have ACPI so I don't understand how
>
> It should also support unconditionally registering devices, if it no
> longer does so that's a regression in the framework which should be
> fixed.  Looking at mfd_add_devices() I can't see an issue though, both
> ACPI and DT information is optional - the entire DT section in
> mfd_add_device() will be skipped if no of_compatible is specified in the
> cell.  Are you *sure* that the regulator driver isn't running?

You are correct, the regulator driver is running and probes
successfully. From my investigation it seems the failure when removing
the compatible string from the MFD and the DTS is because the
regulator driver does not have a of_node matched since the compatible
is gone. Because of that all the regulators registered by the driver
are not linked to the regulator definitions in the device tree. And
all the drivers that tries to acquire a regulator get -EPROBE_DEFER
because of it.