From: Gregory Bean <gbean@codeaurora.org>
To: Daniel Walker <dwalker@codeaurora.org>
Cc: Gregory Bean <gbean@codeaurora.org>,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] msm: gpio: Add irq support to v2 gpiolib.
Date: Tue, 23 Nov 2010 15:08:05 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1011231456380.17082@gbean-linux.qualcomm.com> (raw)
In-Reply-To: <1290534717.4165.43.camel@m0nster>
>> +static inline void set_gpio_bits(unsigned n, void __iomem *reg)
>> +{
>> + writel(readl(reg) | n, reg);
>> +}
>> +
>> +static inline void clr_gpio_bits(unsigned n, void __iomem *reg)
>> +{
>> + writel(readl(reg) & ~n, reg);
>> +}
>
> It seems these functions actually accept output from BIT(). It would be
> safer to force these to accept the bit number then use BIT() inside this
> function to translate. That way you wouldn't use "unsigned n" for the
> argument you would use a named enum for the argument.
I don't think that will work well, because there are cases where we want
to set or clear more than one bit at a time. Making these functions
take a bit number as an argument would restrict them to setting or clearing
only one bit at a time, forcing users to call them multiple times to set
or clear more than one bit, meaning lots of readl & writel calls for
compount bit-changes.
>> +static struct msm_gpio_dev msm_gpio = {
>> + .gpio_chip = {
>> + .base = 0,
>
> I guess it's fine to do "offset - chip->base" if base is always zero,
> but why do subtraction at all.
If the chip is ever moved, not accounting for the base would produce an error.
I know that 'speculative coding' is frowned upon, but isn't removing an
addition (as you pointed out, the subtraction is a bug) because this instance
of the chip is at offset zero a little over the top?
>> + set_gpio_bits(INTR_RAW_STATUS_EN | INTR_ENABLE, GPIO_INTR_CFG(gpio));
>
> I's just break this into two calls, or make another helper that to set
> that accepts the mask and have set_gpio_bits call that. This here you
> would just use the other helper. like set_gpio_bits calls
> set_gpio_bits_mask() and you call the mask version here.
Why make two readl/writel call pairs, or have one version of a helper which
can set a single bit and another version which can set more than one
at a time? That seems really complicated.
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-11-23 23:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 19:52 [PATCH v4 1/2] msm: gpio: Add v2 gpio support to MSM SoCs Gregory Bean
2010-11-18 19:52 ` [PATCH v4 2/2] msm: gpio: Add irq support to v2 gpiolib Gregory Bean
2010-11-18 19:59 ` Janakiram Sistla
2010-11-18 20:30 ` Gregory Bean
2010-11-18 20:39 ` Janakiram Sistla
2010-11-18 20:59 ` Gregory Bean
2010-11-18 22:02 ` Janakiram Sistla
2010-11-19 18:37 ` Gregory Bean
2010-11-19 18:49 ` Janakiram Sistla
2010-11-19 19:00 ` Gregory Bean
2010-11-19 19:09 ` Janakiram Sistla
2010-11-19 20:27 ` Gregory Bean
2010-11-23 17:51 ` Daniel Walker
2010-11-23 23:08 ` Gregory Bean [this message]
2010-11-24 0:44 ` Daniel Walker
2010-11-18 19:56 ` [PATCH v4 1/2] msm: gpio: Add v2 gpio support to MSM SoCs Janakiram Sistla
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=alpine.DEB.2.00.1011231456380.17082@gbean-linux.qualcomm.com \
--to=gbean@codeaurora.org \
--cc=dwalker@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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