linux-kernel - Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC

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: <20151019184826.GX2711@lukather>
Date:	Mon, 19 Oct 2015 20:48:26 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Chen-Yu Tsai <wens@...e.org>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Hans de Goede <hdegoede@...hat.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	devicetree <devicetree@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB
 based AXP223 PMIC

On Mon, Oct 19, 2015 at 02:20:29PM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 19, 2015 at 2:02 PM, Maxime Ripard
> <maxime.ripard@...e-electrons.com> wrote:
> > On Fri, Oct 16, 2015 at 02:46:23PM +0800, Chen-Yu Tsai wrote:
> >> On Fri, Oct 16, 2015 at 2:41 PM, Maxime Ripard
> >> <maxime.ripard@...e-electrons.com> wrote:
> >> > On Thu, Oct 15, 2015 at 12:32:19AM +0800, Chen-Yu Tsai wrote:
> >> >> The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
> >> >> It is functionally identical to AXP221; only the regulator default
> >> >> voltage/status and the external host interface are different.
> >> >>
> >> >> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
> >> >> ---
> >> >>  drivers/mfd/Kconfig        | 12 ++++++
> >> >>  drivers/mfd/Makefile       |  1 +
> >> >>  drivers/mfd/axp20x-core.c  |  2 +
> >> >>  drivers/mfd/axp20x-rsb.c   | 93 ++++++++++++++++++++++++++++++++++++++++++++++
> >> >>  include/linux/mfd/axp20x.h |  1 +
> >> >>  5 files changed, 109 insertions(+)
> >> >>  create mode 100644 drivers/mfd/axp20x-rsb.c
> >> >>
> >> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >> >> index 9ba3feb3f2fc..6e5edb61d42e 100644
> >> >> --- a/drivers/mfd/Kconfig
> >> >> +++ b/drivers/mfd/Kconfig
> >> >> @@ -84,6 +84,7 @@ config MFD_BCM590XX
> >> >>  config MFD_AXP20X
> >> >>       bool "X-Powers AXP series PMICs"
> >> >>       select MFD_AXP20X_I2C
> >> >> +     select MFD_AXP20X_RSB
> >> >>
> >> >>  config MFD_AXP20X_CORE
> >> >>       bool
> >> >> @@ -102,6 +103,17 @@ config MFD_AXP20X_I2C
> >> >>         components like regulators or the PEK (Power Enable Key) under the
> >> >>         corresponding menus.
> >> >>
> >> >> +config MFD_AXP20X_RSB
> >> >> +     bool "X-Powers AXP series RSB PMICs"
> >> >> +     select MFD_AXP20X_CORE
> >> >> +     depends on SUNXI_RSB=y
> >> >
> >> > Do we need that? Even if the bus is compiled as a module, the driver
> >> > will not be probed before that, will it?
> >>
> >> There's a compile/link dependency on the __devm_regmap_init_sunxi_rsb().
> >
> > If it's exported, everything should be fine, no?
> >
> >> And both drivers are bool, i.e. can't be compiled as a module. What we
> >> don't want is enabling MFD_AXP20X_RSB without SUNXI_RSB.
> >
> > What would really be the issue here? The driver wouldn't be probed,
> > and that's it. Or am I missing something?
> 
> The RSB bus / slave device functions have been merged into the RSB driver
> itself. Enabling MFD_AXP20X_RSB without enabling SUNXI_RSB means that RSB
> bus/device related functions are not compiled, i.e. link error:
> 
> drivers/built-in.o: In function `axp20x_rsb_probe':
> /home/wens/sunxi/linux/drivers/mfd/axp20x-rsb.c:64: undefined
> reference to `__devm_regmap_init_sunxi_rsb'
> drivers/built-in.o: In function `axp20x_rsb_driver_init':
> /home/wens/sunxi/linux/drivers/mfd/axp20x-rsb.c:89: undefined
> reference to `sunxi_rsb_driver_register'
> Makefile:927: recipe for target 'vmlinux' failed
>
> The dependency is like "depends on I2C=y" for the I2C version.
> 
> If you're asking about why "=y", I guess it's because MFD_AXP20X_RSB is bool,
> and if the depended on symbol is a tristate, which it actually is for I2c,
> we'd want it to be compiled in, and not built as a module, or again we'd get
> a undefined reference link error.

Yeah, but my point was more why not have both the RSB driver and MFD
as a module? The part where RSB is a module and the driver is
statically built doesn't make sense (and I don't think a depends on
allow that), but having both make sense.

> Would it make sense to have SUNXI_RSB as a tristate symbol, i.e. can be built
> as a module? I'm nore sure. For multi-platform kernels, probably? Currently it
> isn't.

Yes, it's better for multi-platform / distro kernels.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)