Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1250360 > unrolled thread

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

Started byMaxime Ripard <maxime.ripard@free-electrons.com>
First post2015-10-19 08:10 +0200
Last post2015-10-20 06:10 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB  based AXP223 PMIC Maxime Ripard <maxime.ripard@free-electrons.com> - 2015-10-19 08:10 +0200
    Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB  based AXP223 PMIC Chen-Yu Tsai <wens@csie.org> - 2015-10-19 08:30 +0200
      Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB  based AXP223 PMIC Maxime Ripard <maxime.ripard@free-electrons.com> - 2015-10-19 20:50 +0200
        Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB  based AXP223 PMIC Chen-Yu Tsai <wens@csie.org> - 2015-10-20 06:10 +0200

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

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2015-10-19 08:10 +0200
SubjectRe: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC
Message-ID<qlbNU-49Z-11@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

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@free-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@csie.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?

Maxime

> AFAIK the same goes for the I2C version.

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

[toc] | [next] | [standalone]


#1250369

FromChen-Yu Tsai <wens@csie.org>
Date2015-10-19 08:30 +0200
Message-ID<qlc7g-4wB-19@gated-at.bofh.it>
In reply to#1250360
On Mon, Oct 19, 2015 at 2:02 PM, Maxime Ripard
<maxime.ripard@free-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@free-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@csie.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.

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.

Hope this clears it up.


Regards
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1251001

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2015-10-19 20:50 +0200
Message-ID<qlnFo-4ut-19@gated-at.bofh.it>
In reply to#1250369

[Multipart message — attachments visible in raw view] — view raw

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@free-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@free-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@csie.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

[toc] | [prev] | [next] | [standalone]


#1251288

FromChen-Yu Tsai <wens@csie.org>
Date2015-10-20 06:10 +0200
Message-ID<qlwpk-Jq-13@gated-at.bofh.it>
In reply to#1251001
On Tue, Oct 20, 2015 at 2:48 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> 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@free-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@free-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@csie.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.

Ok. I have no problem with building them as modules. I was just following
what the original driver did.

It seems half the mfd driver can be built as modules, while the other
half can only be built-in. I don't know what the criteria is here.

>> 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.

I guess I'll do a follow up patch for sunxi-rsb?

Regards
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web