From: "'Mika Westerberg'" <mika.westerberg@linux.intel.com>
To: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang@intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
Date: Mon, 22 Sep 2014 12:25:28 +0300 [thread overview]
Message-ID: <20140922092528.GM1786@lahna.fi.intel.com> (raw)
In-Reply-To: <50B33AC5ED75F74F991980326F1C438D0FBDB28B@PGSMSX108.gar.corp.intel.com>
On Mon, Sep 22, 2014 at 05:43:36AM +0000, Chang, Rebecca Swee Fun wrote:
> Replied inline. :)
>
> > -----Original Message-----
> > From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> > Sent: 18 September, 2014 7:17 PM
> > To: Chang, Rebecca Swee Fun
> > Cc: Linus Walleij; linux-gpio@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
> >
> > On Wed, Sep 17, 2014 at 04:49:03PM +0800, Chang Rebecca Swee Fun wrote:
> > > Consolidating similar algorithms into common functions to make GPIO
> > > SCH simpler and manageable.
> > >
> > > Signed-off-by: Chang Rebecca Swee Fun
> > > <rebecca.swee.fun.chang@intel.com>
> > > ---
> > > drivers/gpio/gpio-sch.c | 95 ++++++++++++++++++++++++++--------------------
> > -
> > > 1 file changed, 53 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c index
> > > 99720c8..2189c22 100644
> > > --- a/drivers/gpio/gpio-sch.c
> > > +++ b/drivers/gpio/gpio-sch.c
> > > @@ -43,6 +43,8 @@ struct sch_gpio {
> > >
> > > #define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
> > >
> > > +static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int
> > > +val);
> > > +
> >
> > Is it possible to move the sch_gpio_set() function here instead of forward
> > declaring it?
>
> Yes, it is possible. There is a reason I submitted the code in this
> structure. By putting the sch_gpio_set() function below will makes the
> diff patch looks neat and easy for review. If it doesn't make sense
> to make the patch for easy reviewing, I can change by moving the
> function above.
I think that we are interested in the end result (e.g) the driver and if
we can avoid forward declarations the better.
> >
> > > static unsigned sch_gpio_offset(struct sch_gpio *sch, unsigned gpio,
> > > unsigned reg)
> > > {
> > > @@ -63,94 +65,89 @@ static unsigned sch_gpio_bit(struct sch_gpio *sch,
> > unsigned gpio)
> > > return gpio % 8;
> > > }
> > >
> > > -static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
> > > +static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio,
> > > +unsigned reg)
> >
> > I don't see much value in doing this.
> >
> > To me sch_gpio_enable(sch, gpio) is more intuitive than sch_gpio_enable(sch,
> > gpio, GEN). Why do I need to pass register to enable function in the first place?
> > It should know better how to enable the GPIO, right?
> >
> > Same goes for others.
>
> The register values are required when it comes to IRQ handling. By
> passing in the registers values, we can make full use of the
> algorithms without introducing extra/similar algorithms to compute
> other register offset values.
> For example, we have other offset values to handle such as:-
> GTPE 0x0C
> GTNE 0x10
> GGPE 0x14
> GSMI 0x18
> GTS 0x1C
> CGNMIEN 0x40
> RGNMIEN 0x44
Well, can we at least call it something else than sch_gpio_enable()?
Perhaps sch_gpio_set_value() or so?
next prev parent reply other threads:[~2014-09-22 9:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 8:49 [PATCH 0/3] Enable Quark X1000 support in gpio-sch Chang Rebecca Swee Fun
2014-09-17 8:49 ` [PATCH 1/3] gpio: sch: Consolidate similar algorithms Chang Rebecca Swee Fun
2014-09-18 11:17 ` Mika Westerberg
2014-09-22 5:43 ` Chang, Rebecca Swee Fun
2014-09-22 9:25 ` 'Mika Westerberg' [this message]
2014-09-24 0:55 ` Chang, Rebecca Swee Fun
2014-09-24 9:50 ` 'Mika Westerberg'
2014-09-26 1:35 ` Chang, Rebecca Swee Fun
2014-09-17 8:49 ` [PATCH 2/3] gpio: sch: Add support for Intel Quark X1000 SoC Chang Rebecca Swee Fun
2014-09-18 11:22 ` Mika Westerberg
2014-09-22 0:16 ` Chang, Rebecca Swee Fun
2014-09-17 8:49 ` [PATCH 3/3] gpio: sch: Enable IRQ support for Quark X1000 Chang Rebecca Swee Fun
2014-09-18 11:31 ` Mika Westerberg
2014-09-26 9:14 ` Chang, Rebecca Swee Fun
2014-09-26 9:18 ` 'Mika Westerberg'
2014-09-26 9:36 ` Chang, Rebecca Swee Fun
2014-10-15 6:55 ` Linus Walleij
2014-09-23 15:33 ` [PATCH 0/3] Enable Quark X1000 support in gpio-sch Linus Walleij
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=20140922092528.GM1786@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rebecca.swee.fun.chang@intel.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 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).