linux-kernel - Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count

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: <CAEFTgiwN18jBdxhbK31SrpzOnC9R_HWxBRM3xD0WhhEJ1a-pBA@mail.gmail.com>
Date:   Tue, 21 Mar 2017 15:23:50 -0500
From:   Jeremy Linton <lintonrjeremy@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
        puck.chen@...ilicon.com, lee.jones@...aro.org
Subject: Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count

Hi,

On Tue, Mar 21, 2017 at 6:08 AM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, Mar 20, 2017 at 11:53:41PM -0500, Jeremy Linton wrote:
>
>> +     if (!try_module_get(parent->driver->owner)) {
>> +             dev_err(&pdev->dev, "unable to get parent module\n");
>> +             return -ENODEV;
>> +     }
>> +
>
> If this makes sense it should be being done in the driver core, not open
> coded in individual drivers.

Well, this is only really required for the drivers that are oddly
split like these two. It doesn't appear to be necessary for say the
max77* regulators which consume the pmic node, and register
regulators.

I don't understand why it was done this way, and I'm not sure that
this driver shouldn't be triggered based on 'hi655x-regulator' device
(which is being registered by the hi655x-pmic/mfd driver). The only
thing I know for sure, is that its broken in its current
configuration.

Initially I tried a variation on the previous patch, which instead of
trying to double consume the hi655x-pmic platform device, it tried to
consume the hi655x-regulator, but for whatever reason that didn't
work. At least part of the problem with that solution is that depmod
(and therefore tools which are building the initrd) don't understand
the driver relationships here, so simply saying that dw_mmc_k3 is
required for boot doesn't result in the correct set of drivers being
put in the initrd, as one would expect if there were simple symbol
dependencies.