From: Ray Jui <rjui@broadcom.com>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Grant Likely <grant.likely@linaro.org>,
Christian Daudt <bcm@fixthebug.org>,
Matt Porter <mporter@linaro.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Scott Branden <sbranden@broadcom.com>,
Dmitry Torokhov <dtor@google.com>,
Anatol Pomazau <anatol@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
bcm-kernel-feedback-list <bcm-kern>
Subject: Re: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support
Date: Mon, 9 Mar 2015 12:40:30 -0700 [thread overview]
Message-ID: <54FDF72E.2010806@broadcom.com> (raw)
In-Reply-To: <1425929442.2317.39.camel@tiscali.nl>
On 3/9/2015 12:30 PM, Paul Bolle wrote:
> Ray Jui schreef op ma 09-03-2015 om 12:00 [-0700]:
>> I think it depends on how you see it. Based on this logic, then one can
>> also argue comments in the code will be pre-processed away and are not
>> needed. They at least serve the same documentation purpose in a way.
>
> So why not make them comments? And even that might not be needed:
> - MODULE_LICENSE() only summarizes, in just a few words, what takes a
> few paragraphs in the customary comment at the top of a file;
> - MODULE_DESCRIPTION() repeats what, in general, has been said in the
> Kconfig entry for that driver and in the git commit explanation;
> - and I'm not sure what the benefit is of MODULE_AUTHOR() in the first
> place (even for actually modular drivers).
>
>> So
>> far I haven't seen other people complaining that having these module
>> based macros in the driver are confusing when the Kconfig has a bool.
>
> Perhaps that's just because review doesn't spot all issues. Patch
> bandwidth exceeding review bandwidth and all that.
I don't see this as an "issue" to be quite honest. By saying that, I at
least agree with you that these are not information that's mandatory to
be in the driver given what we already have. MODULE_LICENSE is covered
by license header. MODULE_DESCRIPTION is covered by descriptions in
Kconfig. MODULE_AUTHOR is much less important than what's in the
MAINTAINERS list.
Since I have to submit a new patch series to address the "ngpios" issue
that Linus mentioned in the other email, I don't mind removing all these
MODULE_* macros in the driver all together.
>
> Anyhow, right now there's another thread discussing the questions my
> review comments raise. Eg, "The Kconfig symbol is bool, there is module
> related code in the driver, why note make the Kconfig symbol tristate
> (and the driver modular)?". I think that is one of the questions mixing
> built-in and modular semantics raises.
>
>
> Paul Bolle
>
Thanks,
Ray
WARNING: multiple messages have this Message-ID (diff)
From: rjui@broadcom.com (Ray Jui)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support
Date: Mon, 9 Mar 2015 12:40:30 -0700 [thread overview]
Message-ID: <54FDF72E.2010806@broadcom.com> (raw)
In-Reply-To: <1425929442.2317.39.camel@tiscali.nl>
On 3/9/2015 12:30 PM, Paul Bolle wrote:
> Ray Jui schreef op ma 09-03-2015 om 12:00 [-0700]:
>> I think it depends on how you see it. Based on this logic, then one can
>> also argue comments in the code will be pre-processed away and are not
>> needed. They at least serve the same documentation purpose in a way.
>
> So why not make them comments? And even that might not be needed:
> - MODULE_LICENSE() only summarizes, in just a few words, what takes a
> few paragraphs in the customary comment at the top of a file;
> - MODULE_DESCRIPTION() repeats what, in general, has been said in the
> Kconfig entry for that driver and in the git commit explanation;
> - and I'm not sure what the benefit is of MODULE_AUTHOR() in the first
> place (even for actually modular drivers).
>
>> So
>> far I haven't seen other people complaining that having these module
>> based macros in the driver are confusing when the Kconfig has a bool.
>
> Perhaps that's just because review doesn't spot all issues. Patch
> bandwidth exceeding review bandwidth and all that.
I don't see this as an "issue" to be quite honest. By saying that, I at
least agree with you that these are not information that's mandatory to
be in the driver given what we already have. MODULE_LICENSE is covered
by license header. MODULE_DESCRIPTION is covered by descriptions in
Kconfig. MODULE_AUTHOR is much less important than what's in the
MAINTAINERS list.
Since I have to submit a new patch series to address the "ngpios" issue
that Linus mentioned in the other email, I don't mind removing all these
MODULE_* macros in the driver all together.
>
> Anyhow, right now there's another thread discussing the questions my
> review comments raise. Eg, "The Kconfig symbol is bool, there is module
> related code in the driver, why note make the Kconfig symbol tristate
> (and the driver modular)?". I think that is one of the questions mixing
> built-in and modular semantics raises.
>
>
> Paul Bolle
>
Thanks,
Ray
WARNING: multiple messages have this Message-ID (diff)
From: Ray Jui <rjui@broadcom.com>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
"Kumar Gala" <galak@codeaurora.org>,
Grant Likely <grant.likely@linaro.org>,
Christian Daudt <bcm@fixthebug.org>,
Matt Porter <mporter@linaro.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Scott Branden <sbranden@broadcom.com>,
Dmitry Torokhov <dtor@google.com>,
Anatol Pomazau <anatol@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support
Date: Mon, 9 Mar 2015 12:40:30 -0700 [thread overview]
Message-ID: <54FDF72E.2010806@broadcom.com> (raw)
In-Reply-To: <1425929442.2317.39.camel@tiscali.nl>
On 3/9/2015 12:30 PM, Paul Bolle wrote:
> Ray Jui schreef op ma 09-03-2015 om 12:00 [-0700]:
>> I think it depends on how you see it. Based on this logic, then one can
>> also argue comments in the code will be pre-processed away and are not
>> needed. They at least serve the same documentation purpose in a way.
>
> So why not make them comments? And even that might not be needed:
> - MODULE_LICENSE() only summarizes, in just a few words, what takes a
> few paragraphs in the customary comment at the top of a file;
> - MODULE_DESCRIPTION() repeats what, in general, has been said in the
> Kconfig entry for that driver and in the git commit explanation;
> - and I'm not sure what the benefit is of MODULE_AUTHOR() in the first
> place (even for actually modular drivers).
>
>> So
>> far I haven't seen other people complaining that having these module
>> based macros in the driver are confusing when the Kconfig has a bool.
>
> Perhaps that's just because review doesn't spot all issues. Patch
> bandwidth exceeding review bandwidth and all that.
I don't see this as an "issue" to be quite honest. By saying that, I at
least agree with you that these are not information that's mandatory to
be in the driver given what we already have. MODULE_LICENSE is covered
by license header. MODULE_DESCRIPTION is covered by descriptions in
Kconfig. MODULE_AUTHOR is much less important than what's in the
MAINTAINERS list.
Since I have to submit a new patch series to address the "ngpios" issue
that Linus mentioned in the other email, I don't mind removing all these
MODULE_* macros in the driver all together.
>
> Anyhow, right now there's another thread discussing the questions my
> review comments raise. Eg, "The Kconfig symbol is bool, there is module
> related code in the driver, why note make the Kconfig symbol tristate
> (and the driver modular)?". I think that is one of the questions mixing
> built-in and modular semantics raises.
>
>
> Paul Bolle
>
Thanks,
Ray
next prev parent reply other threads:[~2015-03-09 19:40 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 0:35 [PATCH v5 0/8] Add pinctrl support to Broadcom Cygnus SoC Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` [PATCH v5 1/8] pinctrl: bcm: consolidate Broadcom pinctrl drivers Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
[not found] ` <1425515756-321-2-git-send-email-rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-03-09 16:20 ` Linus Walleij
2015-03-09 16:20 ` Linus Walleij
2015-03-09 16:20 ` Linus Walleij
2015-03-05 0:35 ` [PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 8:03 ` Paul Bolle
2015-03-05 8:03 ` Paul Bolle
2015-03-09 16:28 ` Linus Walleij
2015-03-09 16:28 ` Linus Walleij
2015-03-09 16:28 ` Linus Walleij
2015-03-09 18:40 ` Paul Bolle
2015-03-09 18:40 ` Paul Bolle
2015-03-09 18:40 ` Paul Bolle
2015-03-09 19:00 ` Ray Jui
2015-03-09 19:00 ` Ray Jui
2015-03-09 19:00 ` Ray Jui
2015-03-09 19:30 ` Paul Bolle
2015-03-09 19:30 ` Paul Bolle
2015-03-09 19:30 ` Paul Bolle
2015-03-09 19:40 ` Ray Jui [this message]
2015-03-09 19:40 ` Ray Jui
2015-03-09 19:40 ` Ray Jui
2015-03-09 19:53 ` Paul Bolle
2015-03-09 19:53 ` Paul Bolle
2015-03-09 19:53 ` Paul Bolle
2015-03-09 16:26 ` Linus Walleij
2015-03-09 16:26 ` Linus Walleij
2015-03-09 16:26 ` Linus Walleij
2015-03-05 0:35 ` [PATCH v5 4/8] ARM: dts: enable IOMUX for Broadcom Cygnus Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-09 16:29 ` Linus Walleij
2015-03-09 16:29 ` Linus Walleij
2015-03-09 16:29 ` Linus Walleij
2015-03-05 0:35 ` [PATCH v5 5/8] pinctrl: Cygnus: define Broadcom Cygnus GPIO/PINCONF binding Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-09 16:30 ` Linus Walleij
2015-03-09 16:30 ` Linus Walleij
2015-03-09 16:30 ` Linus Walleij
2015-03-09 16:41 ` Ray Jui
2015-03-09 16:41 ` Ray Jui
2015-03-09 16:41 ` Ray Jui
[not found] ` <1425515756-321-1-git-send-email-rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-03-05 0:35 ` [PATCH v5 2/8] pinctrl: Broadcom Cygnus pinctrl device tree binding Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-09 16:22 ` Linus Walleij
2015-03-09 16:22 ` Linus Walleij
2015-03-09 16:22 ` Linus Walleij
2015-03-05 0:35 ` [PATCH v5 6/8] pinctrl: cygnus: add gpio/pinconf driver Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 8:11 ` Paul Bolle
2015-03-05 8:11 ` Paul Bolle
2015-03-05 8:36 ` Paul Bolle
2015-03-05 8:36 ` Paul Bolle
2015-03-05 8:36 ` Paul Bolle
2015-03-05 17:13 ` Ray Jui
2015-03-05 17:13 ` Ray Jui
2015-03-05 17:13 ` Ray Jui
2015-03-09 16:41 ` Linus Walleij
2015-03-09 16:41 ` Linus Walleij
2015-03-09 16:41 ` Linus Walleij
2015-03-09 18:47 ` Paul Bolle
2015-03-09 18:47 ` Paul Bolle
2015-03-09 18:47 ` Paul Bolle
2015-03-05 0:35 ` [PATCH v5 7/8] ARM: dts: enable GPIO for Broadcom Cygnus Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` [PATCH v5 8/8] ARM: dts: cygnus: enable GPIO based hook detection Ray Jui
2015-03-05 0:35 ` Ray Jui
2015-03-05 0:35 ` Ray Jui
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=54FDF72E.2010806@broadcom.com \
--to=rjui@broadcom.com \
--cc=anatol@google.com \
--cc=arnd@arndb.de \
--cc=bcm@fixthebug.org \
--cc=dtor@google.com \
--cc=f.fainelli@gmail.com \
--cc=galak@codeaurora.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mporter@linaro.org \
--cc=pawel.moll@arm.com \
--cc=pebolle@tiscali.nl \
--cc=robh+dt@kernel.org \
--cc=sbranden@broadcom.com \
--cc=swarren@wwwdotorg.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.