From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753273AbbJSSsb (ORCPT ); Mon, 19 Oct 2015 14:48:31 -0400 Received: from down.free-electrons.com ([37.187.137.238]:57554 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751194AbbJSSs3 (ORCPT ); Mon, 19 Oct 2015 14:48:29 -0400 Date: Mon, 19 Oct 2015 20:48:26 +0200 From: Maxime Ripard To: Chen-Yu Tsai Cc: Samuel Ortiz , Lee Jones , Liam Girdwood , Mark Brown , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Hans de Goede , linux-arm-kernel , devicetree , linux-kernel , linux-sunxi Subject: Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC Message-ID: <20151019184826.GX2711@lukather> References: <1444840342-9233-1-git-send-email-wens@csie.org> <1444840342-9233-4-git-send-email-wens@csie.org> <20151016064159.GG2711@lukather> <20151019060226.GQ2711@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qn4G1eBrv+t66M9q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Qn4G1eBrv+t66M9q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > 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 > >> 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 SoC= s. > >> >> 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 > >> >> --- > >> >> 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) un= der the > >> >> corresponding menus. > >> >> > >> >> +config MFD_AXP20X_RSB > >> >> + bool "X-Powers AXP series RSB PMICs" > >> >> + select MFD_AXP20X_CORE > >> >> + depends on SUNXI_RSB=3Dy > >> > > >> > 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? >=20 > 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: >=20 > 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=3Dy" for the I2C version. >=20 > If you're asking about why "=3Dy", 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 b= uilt > as a module? I'm nore sure. For multi-platform kernels, probably? Current= ly it > isn't. Yes, it's better for multi-platform / distro kernels. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --Qn4G1eBrv+t66M9q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWJTr6AAoJEBx+YmzsjxAgjCYQAK6MeoiWI516on005Lt15CqO Zs0bcV5J0UqGuflyKaL3nuDAptooRcUQ13XPLvKm7N64ZqX1f4VivA4msYpmjAvS RmAX22jrj8l6DRNomNYksmnsuatzG25ZPB4wOGhfStzC2/5j1V49lj8WIYgMmi62 plW0BR24JpuvH9apc7PLGuiEVvXjrMI16XatytHA5qKidccC/MoxWqeigKrtRGLW pRzEmSGubLYhGtUCmHAN+svNVuBI0gwHIGqiZEdEmm1GJ+nBoPfAg61K2MEKW7S5 dABlgMu8FIuM63zUNYx7ilXREfLSda2FphTv/niNrwHmeWB560SK1MmcyTowtpsF KzFA5yPBEM1Eu/VBvM9Bbw5MkRmG2gOat81f2RJN8YTreY51B1GCfafo08ujRXRI 6UaRp0FkcE+PqGoX1U4uDIdyj7CJ1c0GxFrpwCF/PAA/tywqr2DFFZKLSSo/VrsP ucVyY6DAhYtcrL1B1y8o71SNfjUyqAkdRNOZaDiamhkQin7mdqXKZK5BbBD6+Lbl 1YOX2MErXuJ3z9LGTDRXNAxP3WBMYMjUPoe9lVmao0u3KnDX/oPsPv0K17bZohgn P/XunI5GckxucEpiNu78Xri4BqXyQOSjC28jQfzPVgvAtVAaKJC/gl9JkKqGv6uW 7oU2wD7cV2xotj9NTMeN =Yd5/ -----END PGP SIGNATURE----- --Qn4G1eBrv+t66M9q--