All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: 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 11:54:48 +0000	[thread overview]
Message-ID: <20150217115447.GA3989@x1> (raw)
In-Reply-To: <20150217092020.GC4507@kwain>

On Tue, 17 Feb 2015, Antoine Tenart wrote:
> 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.

[...]

> > > +#include <linux/mfd/core.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > 
> > kernel.h?
> 
> Is there a reason to add this header here?

I guess not if you're not using any of its macros.  Although, I don't
recall every seeing s driver without it.  I guess you learn something
every day.

[...]

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

Tell me more.  What are the problems you encountered?

> To provide a regmap to the devices' drivers we also use syscon on the
> chip/system controller nodes.
> 
> > > +MODULE_LICENSE("GPL");

I wonder if these are actually useful if you're always going to be
built-in? 

> > > +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?

Yes, there is disparity between this and the comment in the file
header.  I don't mind which one you amend, but a change is required.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] mfd: add the Berlin controller driver
Date: Tue, 17 Feb 2015 11:54:48 +0000	[thread overview]
Message-ID: <20150217115447.GA3989@x1> (raw)
In-Reply-To: <20150217092020.GC4507@kwain>

On Tue, 17 Feb 2015, Antoine Tenart wrote:
> 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.

[...]

> > > +#include <linux/mfd/core.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > 
> > kernel.h?
> 
> Is there a reason to add this header here?

I guess not if you're not using any of its macros.  Although, I don't
recall every seeing s driver without it.  I guess you learn something
every day.

[...]

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

Tell me more.  What are the problems you encountered?

> To provide a regmap to the devices' drivers we also use syscon on the
> chip/system controller nodes.
> 
> > > +MODULE_LICENSE("GPL");

I wonder if these are actually useful if you're always going to be
built-in? 

> > > +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?

Yes, there is disparity between this and the comment in the file
header.  I don't mind which one you amend, but a change is required.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-02-17 11:54 UTC|newest]

Thread overview: 75+ 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
2015-02-17  9:20       ` Antoine Tenart
2015-02-17 11:54       ` Lee Jones [this message]
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-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-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-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=20150217115447.GA3989@x1 \
    --to=lee.jones@linaro.org \
    --cc=antoine.tenart@free-electrons.com \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=zmxu@marvell.com \
    /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.