From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] arm: sunxi: Add AXP20X_ADC
Date: Mon, 24 Jul 2017 10:10:13 +0200 [thread overview]
Message-ID: <20170724081013.uyfaetzkj5iz7uhj@flea> (raw)
In-Reply-To: <be7d4295-8759-f57e-a600-358c7344251c@free-electrons.com>
On Mon, Jul 24, 2017 at 08:43:56AM +0200, Quentin Schulz wrote:
> Hi all,
>
> I've been Cc'ed by Chen-Yu I think, thanks for the heads-up.
>
> On 22/07/2017 04:19, Chen-Yu Tsai wrote:
> > On Sat, Jul 22, 2017 at 12:20 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> The APX20X_POWER option, that is a dependency of the USB controllers
> >> depends on IIO and AXP20X_ADC. Add it so that we can get a working USB
> >> back.
> >
> > The statement is only half true. AXP20X_POWER can fall back to reading
> > the ADC registers directly if AXP20X_ADC is not enabled.
>
> For any PMIC using "x-powers,axp202-usb-power-supply" compatible, that
> is true, the others imperatively use IIO channels as there was no prior
> support to this driver.
>
> The switch between reading IIO channels or directly reading the
> registers is done at probe by checking IS_ENABLED(AXP20X_ADC)
> (IS_ENABLED returns 1 when Kconfig is set to y or m). The goal was to
> not break the existing system when users would update to a newer kernel
> (as they may not have selected AXP20X_ADC).
>
> Since there is no hard dependency between AXP20X_ADC and AXP20X_POWER, I
> think we may have a problem when AXP20X_ADC is built as a module. Then
> AXP20X_POWER probing is deferred since it waits for the IIO channels.
> Also, if you do a modprobe on AXP20X_POWER it'll not probe AXP20X_ADC
> because the dependency is not declared. I don't know if there is a way
> to declare this dependency programatically only when AXP20X_ADC is built
> as a module?
>
> > Is there a plan
> > to remove this feature?
> >
>
> As said above (and in the commit log[1]), I added the condition for
> backward compatibility so anyone could still use AXP20X_POWER without
> the ADC, but maybe that is irrelevant?
The only compatibility we care about is the DT one. We don't care
about config options.
> This could solve a bit of the "complexity" of the driver, now that
> we know we want to enforce AXP20X_ADC to be built with
> AXP20X_POWER. I'm obviously okay to remove this feature if my point
> of backward compatibility is irrelevant.
>
> But now, we still have the problem that AXP20X_ADC is not needed for
> AXP20X_POWER for AXP22X (and those that don't have voltage/current
> sensing). We don't really need to force AXP20X_ADC to be built when the
> user want AXP20X_POWER.
>
> 1) We force AXP20X_ADC to be built whenever AXP20X_POWER is built, even
> for PMICs that don't have any voltage/current sensing. This way, we can
> enforce the dependency in Kconfig and everything's easy,
That's backward. The dependency is from AXP20X_POWER to
AXP20X_ADC. That's it, we should express it as such.
> 2) We programmatically set the dependency between AXP20X_ADC and
> AXP20X_POWER depending on the compatible used (AXP20X set the
> dependency, not AXP22X).
Why not just adding a depends on?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170724/eca59c21/attachment.sig>
next prev parent reply other threads:[~2017-07-24 8:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 16:20 [PATCH 1/4] arm: multi_v7: Add AXP20X_POWER Maxime Ripard
2017-07-21 16:20 ` [PATCH 2/4] arm: sunxi: refresh the defconfig Maxime Ripard
2017-07-22 2:05 ` Chen-Yu Tsai
2017-07-24 8:12 ` Maxime Ripard
2017-07-21 16:20 ` [PATCH 3/4] arm: sunxi: Add AXP20X_ADC Maxime Ripard
2017-07-22 2:19 ` Chen-Yu Tsai
2017-07-24 6:43 ` Quentin Schulz
2017-07-24 7:48 ` Chen-Yu Tsai
2017-07-24 8:10 ` Maxime Ripard [this message]
2017-07-24 8:41 ` Quentin Schulz
2017-07-24 9:33 ` Maxime Ripard
2017-07-24 8:18 ` Maxime Ripard
2017-07-24 8:22 ` Chen-Yu Tsai
2017-07-24 9:44 ` Maxime Ripard
2017-07-24 8:47 ` Quentin Schulz
2017-07-21 16:20 ` [PATCH 4/4] arm: sunxi: Add additional power supplies Maxime Ripard
2017-07-22 2:20 ` Chen-Yu Tsai
2017-07-24 8:13 ` Maxime Ripard
2017-07-24 8:14 ` [PATCH 1/4] arm: multi_v7: Add AXP20X_POWER Chen-Yu Tsai
2017-07-25 14:30 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170724081013.uyfaetzkj5iz7uhj@flea \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox