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
next prev parent reply other threads:[~2015-02-17 11:54 UTC|newest]
Thread overview: 36+ 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 ` [PATCH 01/11] mfd: add the Berlin controller driver Antoine Tenart
2015-02-16 12:48 ` Lee Jones
2015-02-17 9:20 ` Antoine Tenart
2015-02-17 11:54 ` Lee Jones [this message]
2015-02-18 8:40 ` Antoine Tenart
2015-02-18 9:09 ` Lee Jones
2015-02-18 9:22 ` Antoine Tenart
2015-02-18 10:40 ` Lee Jones
2015-02-18 10:51 ` Antoine Tenart
2015-02-18 11:10 ` Sebastian Hesselbarth
2015-02-18 11:58 ` Lee Jones
2015-02-18 13:09 ` Sebastian Hesselbarth
2015-02-18 15:06 ` Lee Jones
2015-02-18 15:07 ` Lee Jones
2015-02-18 15:06 ` Arnd Bergmann
2015-02-18 15:59 ` Sebastian Hesselbarth
2015-02-18 16:15 ` Arnd Bergmann
2015-02-18 16:26 ` Lee Jones
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 ` [PATCH 03/11] ARM: berlin: select MFD_BERLIN_CTRL Antoine Tenart
2015-02-11 16:15 ` [PATCH 04/11] reset: berlin: convert to a platform driver Antoine Tenart
2015-02-11 16:15 ` [PATCH 05/11] Documentation: bindings: move the Berlin reset documentation Antoine Tenart
2015-02-11 16:15 ` [PATCH 06/11] pinctrl: berlin: use the regmap provided by syscon Antoine Tenart
2015-03-05 9:38 ` Linus Walleij
2015-02-11 16:15 ` [PATCH 07/11] pinctrl: berlin: use proper compatibles Antoine Tenart
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-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-18 10:29 ` Sebastian Hesselbarth
2015-02-18 10:33 ` Antoine Tenart
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 ` [PATCH 11/11] ARM: berlin: rework chip and system controller nodes for BG2Q 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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).