MIME-Version: 1.0
In-Reply-To: <20170321110804.qlyqqiuunrpuklqu@sirena.org.uk>
References: <20170321045341.4833-1-lintonrjeremy@gmail.com>
 <20170321045341.4833-3-lintonrjeremy@gmail.com> <20170321110804.qlyqqiuunrpuklqu@sirena.org.uk>
From: Jeremy Linton <lintonrjeremy@gmail.com>
Date: Tue, 21 Mar 2017 15:23:50 -0500
Message-ID: <CAEFTgiwN18jBdxhbK31SrpzOnC9R_HWxBRM3xD0WhhEJ1a-pBA@mail.gmail.com>
Subject: Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
        puck.chen@hisilicon.com, lee.jones@linaro.org
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1473
Lines: 34

Hi,

On Tue, Mar 21, 2017 at 6:08 AM, Mark Brown <broonie@kernel.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.