All of lore.kernel.org
 help / color / mirror / Atom feed
From: antoine.tenart@free-electrons.com (Antoine Tenart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] mfd: add the Berlin controller driver
Date: Tue, 17 Feb 2015 10:20:20 +0100	[thread overview]
Message-ID: <20150217092020.GC4507@kwain> (raw)
In-Reply-To: <20150216124808.GC14545@x1>

Lee,

On Mon, Feb 16, 2015 at 12:48:08PM +0000, Lee Jones wrote:
> On Wed, 11 Feb 2015, Antoine Tenart wrote:
> 
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -840,6 +840,11 @@ config STMPE_SPI
> >  	  This is used to enable SPI interface of STMPE
> >  endmenu
> >  
> > +config MFD_BERLIN_CTRL
> > +	bool
> 
> Missing description.
> Why can't this driver be built as a module?

Well, this mfd driver registers various devices as the pinctrl and the
reset driver. I think we want the pinctrl driver to always be
registered.

IMHO we want this driver to always be selected when using a Berlin SoC.

> 
> > +	select MFD_CORE
> > +	select MFD_SYSCON
> 
> Missing help.
> 
> >  config MFD_STA2X11
> >  	bool "STMicroelectronics STA2X11"
> >  	depends on STA2X11
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 53467e211381..adf60e85df20 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -179,3 +179,5 @@ obj-$(CONFIG_MFD_DLN2)		+= dln2.o
> >  
> >  intel-soc-pmic-objs		:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
> >  obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
> > +
> > +obj-$(CONFIG_MFD_BERLIN_CTRL)	+= berlin-ctrl.o
> > diff --git a/drivers/mfd/berlin-ctrl.c b/drivers/mfd/berlin-ctrl.c
> > new file mode 100644
> > index 000000000000..e3ce6f069f16
> > --- /dev/null
> > +++ b/drivers/mfd/berlin-ctrl.c
> > @@ -0,0 +1,180 @@
> > +/*
> > + * Copyright (C) 2015 Marvell Technology Group Ltd.
> > + *
> > + * Antoine Tenart <antoine.tenart@free-electrons.com>
> 
> Author: Antoine Tenart <antoine.tenart@free-electrons.com>

Hmmm, okay.

> 
> > +
> > +#include <linux/mfd/core.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> 
> kernel.h?

Is there a reason to add this header here?

> > +/*
> > + * BG2 devices
> > + */
> > +static const struct mfd_cell berlin2_ctrl_chip_ctrl_subdevs[] = {
> > +	{
> > +		.name		= "berlin2-soc-pinctrl",
> > +		.of_compatible	= "marvell,berlin2-soc-pinctrl",
> > +	},
> > +	{
> > +		.name		= "berlin2-reset",
> > +		.of_compatible	= "marvell,berlin2-reset",
> > +	},
> > +};
> > +
> > +static const struct mfd_cell berlin2_ctrl_system_ctrl_subdevs[] = {
> > +	{
> > +		.name		= "berlin2-system-pinctrl",
> > +		.of_compatible	= "marvell,berlin2-system-pinctrl",
> > +	},
> > +};
> > +
> > +static const struct berlin_ctrl_priv berlin2_ctrl_chip_ctrl_data = {
> > +	.devs	= berlin2_ctrl_chip_ctrl_subdevs,
> > +	.ndevs	= ARRAY_SIZE(berlin2_ctrl_chip_ctrl_subdevs),
> > +};
> > +
> > +static const struct berlin_ctrl_priv berlin2_ctrl_system_data = {
> > +	.devs	= berlin2_ctrl_system_ctrl_subdevs,
> > +	.ndevs	= ARRAY_SIZE(berlin2_ctrl_system_ctrl_subdevs),
> > +};
> > +
> > +
> 
> Superfluous '\n'

Sure.

> 
> > +
> > +static int berlin_ctrl_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	const struct of_device_id *match;
> > +	const struct berlin_ctrl_priv *priv;
> > +	int ret;
> > +
> > +	match = of_match_node(berlin_ctrl_of_match, dev->of_node);
> > +	if (!match)
> > +		return -EINVAL;
> > +
> > +	priv = match->data;
> > +
> > +	ret = mfd_add_devices(dev, 0, priv->devs, priv->ndevs, NULL, -1, NULL);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to add devices: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> 
> I'm not sure I see the point in this driver.  Why can't you just
> register these devices directly from DT?

All these devices share the same bank of registers and we previously
used a single node. But with many devices sharing a single node, this is
problematic to register all the devices from DT. Using this MFD driver
to do it is a proper solution in this case.

To provide a regmap to the devices' drivers we also use syscon on the
chip/system controller nodes.

> > +MODULE_LICENSE("GPL");
> 
> v2

"GPL" is a valid choice, quoting include/linux.module.h:

	"GPL"              [GNU Public License v2 or later]
	"GPL v2"           [GNU Public License v2]

Is there a reason you explicitly want to use GPLv2, and only GPLv2?

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Antoine Tenart <antoine.tenart@free-electrons.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>,
	sebastian.hesselbarth@gmail.com, sameo@linux.intel.com,
	jszhang@marvell.com, zmxu@marvell.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/11] mfd: add the Berlin controller driver
Date: Tue, 17 Feb 2015 10:20:20 +0100	[thread overview]
Message-ID: <20150217092020.GC4507@kwain> (raw)
In-Reply-To: <20150216124808.GC14545@x1>

Lee,

On Mon, Feb 16, 2015 at 12:48:08PM +0000, Lee Jones wrote:
> On Wed, 11 Feb 2015, Antoine Tenart wrote:
> 
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -840,6 +840,11 @@ config STMPE_SPI
> >  	  This is used to enable SPI interface of STMPE
> >  endmenu
> >  
> > +config MFD_BERLIN_CTRL
> > +	bool
> 
> Missing description.
> Why can't this driver be built as a module?

Well, this mfd driver registers various devices as the pinctrl and the
reset driver. I think we want the pinctrl driver to always be
registered.

IMHO we want this driver to always be selected when using a Berlin SoC.

> 
> > +	select MFD_CORE
> > +	select MFD_SYSCON
> 
> Missing help.
> 
> >  config MFD_STA2X11
> >  	bool "STMicroelectronics STA2X11"
> >  	depends on STA2X11
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 53467e211381..adf60e85df20 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -179,3 +179,5 @@ obj-$(CONFIG_MFD_DLN2)		+= dln2.o
> >  
> >  intel-soc-pmic-objs		:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
> >  obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
> > +
> > +obj-$(CONFIG_MFD_BERLIN_CTRL)	+= berlin-ctrl.o
> > diff --git a/drivers/mfd/berlin-ctrl.c b/drivers/mfd/berlin-ctrl.c
> > new file mode 100644
> > index 000000000000..e3ce6f069f16
> > --- /dev/null
> > +++ b/drivers/mfd/berlin-ctrl.c
> > @@ -0,0 +1,180 @@
> > +/*
> > + * Copyright (C) 2015 Marvell Technology Group Ltd.
> > + *
> > + * Antoine Tenart <antoine.tenart@free-electrons.com>
> 
> Author: Antoine Tenart <antoine.tenart@free-electrons.com>

Hmmm, okay.

> 
> > +
> > +#include <linux/mfd/core.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> 
> kernel.h?

Is there a reason to add this header here?

> > +/*
> > + * BG2 devices
> > + */
> > +static const struct mfd_cell berlin2_ctrl_chip_ctrl_subdevs[] = {
> > +	{
> > +		.name		= "berlin2-soc-pinctrl",
> > +		.of_compatible	= "marvell,berlin2-soc-pinctrl",
> > +	},
> > +	{
> > +		.name		= "berlin2-reset",
> > +		.of_compatible	= "marvell,berlin2-reset",
> > +	},
> > +};
> > +
> > +static const struct mfd_cell berlin2_ctrl_system_ctrl_subdevs[] = {
> > +	{
> > +		.name		= "berlin2-system-pinctrl",
> > +		.of_compatible	= "marvell,berlin2-system-pinctrl",
> > +	},
> > +};
> > +
> > +static const struct berlin_ctrl_priv berlin2_ctrl_chip_ctrl_data = {
> > +	.devs	= berlin2_ctrl_chip_ctrl_subdevs,
> > +	.ndevs	= ARRAY_SIZE(berlin2_ctrl_chip_ctrl_subdevs),
> > +};
> > +
> > +static const struct berlin_ctrl_priv berlin2_ctrl_system_data = {
> > +	.devs	= berlin2_ctrl_system_ctrl_subdevs,
> > +	.ndevs	= ARRAY_SIZE(berlin2_ctrl_system_ctrl_subdevs),
> > +};
> > +
> > +
> 
> Superfluous '\n'

Sure.

> 
> > +
> > +static int berlin_ctrl_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	const struct of_device_id *match;
> > +	const struct berlin_ctrl_priv *priv;
> > +	int ret;
> > +
> > +	match = of_match_node(berlin_ctrl_of_match, dev->of_node);
> > +	if (!match)
> > +		return -EINVAL;
> > +
> > +	priv = match->data;
> > +
> > +	ret = mfd_add_devices(dev, 0, priv->devs, priv->ndevs, NULL, -1, NULL);
> > +	if (ret) {
> > +		dev_err(dev, "Failed to add devices: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> 
> I'm not sure I see the point in this driver.  Why can't you just
> register these devices directly from DT?

All these devices share the same bank of registers and we previously
used a single node. But with many devices sharing a single node, this is
problematic to register all the devices from DT. Using this MFD driver
to do it is a proper solution in this case.

To provide a regmap to the devices' drivers we also use syscon on the
chip/system controller nodes.

> > +MODULE_LICENSE("GPL");
> 
> v2

"GPL" is a valid choice, quoting include/linux.module.h:

	"GPL"              [GNU Public License v2 or later]
	"GPL v2"           [GNU Public License v2]

Is there a reason you explicitly want to use GPLv2, and only GPLv2?

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2015-02-17  9:20 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-11 16:15 [PATCH 00/11] ARM: berlin: refactor chip and system controllers Antoine Tenart
2015-02-11 16:15 ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 01/11] mfd: add the Berlin controller driver Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-16 12:48   ` Lee Jones
2015-02-16 12:48     ` Lee Jones
2015-02-17  9:20     ` Antoine Tenart [this message]
2015-02-17  9:20       ` Antoine Tenart
2015-02-17 11:54       ` Lee Jones
2015-02-17 11:54         ` Lee Jones
2015-02-18  8:40         ` Antoine Tenart
2015-02-18  8:40           ` Antoine Tenart
2015-02-18  9:09           ` Lee Jones
2015-02-18  9:09             ` Lee Jones
2015-02-18  9:22             ` Antoine Tenart
2015-02-18  9:22               ` Antoine Tenart
2015-02-18 10:40               ` Lee Jones
2015-02-18 10:40                 ` Lee Jones
2015-02-18 10:51                 ` Antoine Tenart
2015-02-18 10:51                   ` Antoine Tenart
2015-02-18 11:10                 ` Sebastian Hesselbarth
2015-02-18 11:10                   ` Sebastian Hesselbarth
2015-02-18 11:58                   ` Lee Jones
2015-02-18 11:58                     ` Lee Jones
2015-02-18 13:09                     ` Sebastian Hesselbarth
2015-02-18 13:09                       ` Sebastian Hesselbarth
2015-02-18 15:06                       ` Lee Jones
2015-02-18 15:06                         ` Lee Jones
2015-02-18 15:07                         ` Lee Jones
2015-02-18 15:07                           ` Lee Jones
2015-02-18 15:06                       ` Arnd Bergmann
2015-02-18 15:06                         ` Arnd Bergmann
2015-02-18 15:59                         ` Sebastian Hesselbarth
2015-02-18 15:59                           ` Sebastian Hesselbarth
2015-02-18 16:15                           ` Arnd Bergmann
2015-02-18 16:15                             ` Arnd Bergmann
2015-02-18 16:26                           ` Lee Jones
2015-02-18 16:26                             ` Lee Jones
2015-02-18 10:27             ` Sebastian Hesselbarth
2015-02-18 10:27               ` Sebastian Hesselbarth
2015-02-11 16:15 ` [PATCH 02/11] Documentation: bindings: add the Berlin controller documentation Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 03/11] ARM: berlin: select MFD_BERLIN_CTRL Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 04/11] reset: berlin: convert to a platform driver Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 05/11] Documentation: bindings: move the Berlin reset documentation Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 06/11] pinctrl: berlin: use the regmap provided by syscon Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-03-05  9:38   ` Linus Walleij
2015-03-05  9:38     ` Linus Walleij
2015-02-11 16:15 ` [PATCH 07/11] pinctrl: berlin: use proper compatibles Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-03-05  9:39   ` Linus Walleij
2015-03-05  9:39     ` Linus Walleij
2015-02-11 16:15 ` [PATCH 08/11] Documentation: bindings: move the Berlin pinctrl documentation Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-03-05  9:41   ` Linus Walleij
2015-03-05  9:41     ` Linus Walleij
2015-02-11 16:15 ` [PATCH 09/11] ARM: berlin: rework chip and system controller nodes for BG2 Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-18 10:29   ` Sebastian Hesselbarth
2015-02-18 10:29     ` Sebastian Hesselbarth
2015-02-18 10:33     ` Antoine Tenart
2015-02-18 10:33       ` Antoine Tenart
2015-02-18 10:35       ` Sebastian Hesselbarth
2015-02-18 10:35         ` Sebastian Hesselbarth
2015-02-11 16:15 ` [PATCH 10/11] ARM: berlin: rework chip and system controller nodes for BG2CD Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart
2015-02-11 16:15 ` [PATCH 11/11] ARM: berlin: rework chip and system controller nodes for BG2Q Antoine Tenart
2015-02-11 16:15   ` Antoine Tenart

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=20150217092020.GC4507@kwain \
    --to=antoine.tenart@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.