[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190108103203.GA3643@basecamp>
Date: Tue, 8 Jan 2019 05:32:03 -0500
From: Brian Masney <masneyb@...tation.org>
To: Stephen Boyd <sboyd@...nel.org>
Cc: andy.gross@...aro.org, bjorn.andersson@...aro.org,
lee.jones@...aro.org, linus.walleij@...aro.org,
marc.zyngier@....com, shawnguo@...nel.org, dianders@...omium.org,
linux-gpio@...r.kernel.org, nicolas.dechesne@...aro.org,
niklas.cassel@...aro.org, david.brown@...aro.org,
robh+dt@...nel.org, mark.rutland@....com, thierry.reding@...il.com,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/5] mfd: qcom-spmi-pmic: use devm_mfd_add_devices
instead of devm_of_platform_populate
On Mon, Jan 07, 2019 at 01:41:30PM -0800, Stephen Boyd wrote:
> Now this seems worse. We have gotten by without having to explicitly
> list all the devices that are inside the PMIC as mfd cells. But now, to
> avoid creating the irqs before the hierarchy is installed, we have to
> undo all of that and rely on the difference in behavior of
> of_platform_populate() and mfd_add_devices(). That's pretty obscure to
> figure out.
>
> I'd prefer we drop this patch and keep disassociating virqs and
> reassociating them in the gpio driver. Then we can remove the interrupts
> properties in all the DTS files and finally remove the disassociate and
> reassociating code in the gpio driver when all the DT files are cleaned
> up. It makes things less confusing that way and doesn't require updates
> to this driver.
You are right that we can get this working without this patch. The issue
that I experienced was caused by the interrupts property on the
spmi-gpio node. I thought that I tested this with that configuration but
I obviously didn't.
qcom-pm8941.dtsi and qcom-pma8084.dtsi are the only two in-tree users of
spmi-gpio. I'll include the fix for qcom-pma8084.dtsi as well.
Brian
Powered by blists - more mailing lists