public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: Ryan Mallon <ryan@bluewatersys.com>
Cc: linux-kernel@vger.kernel.org, Alek Du <alek.du@intel.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	David Brownell <dbrownell@users.sourceforge.net>,
	Eric Miao <eric.y.miao@gmail.com>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Joe Perches <joe@perches.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH v3 1/4] gpiolib: Add "unknown" direction support
Date: Thu, 17 Feb 2011 18:33:44 -0600	[thread overview]
Message-ID: <1297989224.965.18483.camel@petert> (raw)
In-Reply-To: <4D5DB833.4070902@bluewatersys.com>

On Fri, 2011-02-18 at 13:07 +1300, Ryan Mallon wrote:
> On 02/18/2011 12:03 PM, Peter Tyser wrote:
> > Previously, gpiolib would unconditionally flag all GPIO pins as inputs,
> > regardless of their true state.  This resulted in all GPIO output pins
> > initially being incorrectly identified as "input" in the GPIO sysfs.
> > 
> > Since the direction of GPIOs is not known prior to having their
> > direction set, instead set the default direction to "unknown" to prevent
> > user confusion.  A pin with an "unknown" direction can not be written or
> > read via sysfs; it must first be configured as an input or output before
> > it can be used.
> > 
> > While we're playing with the direction flag in/out defines, rename them to
> > a more descriptive FLAG_DIR_* format.
> > 
> > Cc: Alek Du <alek.du@intel.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Cc: David Brownell <dbrownell@users.sourceforge.net>
> > Cc: Eric Miao <eric.y.miao@gmail.com>
> > Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > Cc: Joe Perches <joe@perches.com>
> > Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > Change since V1:
> > - This patch is new and is based on feedback from Alan to support a new
> >   "unknown" direction.
> > - Rename FLAG_IS_OUT to FLAG_DIR_OUT, and add FLAG_DIR_IN
> > 
> > Change since V2:
> > - None
> > 
> >  drivers/gpio/gpiolib.c |   91 ++++++++++++++++++++++++++---------------------
> >  1 files changed, 50 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 649550e..eb74311 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -49,13 +49,14 @@ struct gpio_desc {
> >  	unsigned long		flags;
> >  /* flag symbols are bit numbers */
> >  #define FLAG_REQUESTED	0
> > -#define FLAG_IS_OUT	1
> > -#define FLAG_RESERVED	2
> > -#define FLAG_EXPORT	3	/* protected by sysfs_lock */
> > -#define FLAG_SYSFS	4	/* exported via /sys/class/gpio/control */
> > -#define FLAG_TRIG_FALL	5	/* trigger on falling edge */
> > -#define FLAG_TRIG_RISE	6	/* trigger on rising edge */
> > -#define FLAG_ACTIVE_LOW	7	/* sysfs value has active low */
> > +#define FLAG_DIR_OUT	1	/* pin is an output */
> > +#define FLAG_DIR_IN	2	/* pin is an input */
> > +#define FLAG_RESERVED	3
> > +#define FLAG_EXPORT	4	/* protected by sysfs_lock */
> > +#define FLAG_SYSFS	5	/* exported via /sys/class/gpio/control */
> > +#define FLAG_TRIG_FALL	6	/* trigger on falling edge */
> > +#define FLAG_TRIG_RISE	7	/* trigger on rising edge */
> > +#define FLAG_ACTIVE_LOW	8	/* sysfs value has active low */
> 
> This patch really shouldn't renumber all (and rename some) of the flags.
> Patches should ideally do one thing only, so if you want to rename
> FLAG_IS_OUT to FLAG_DIR_OUT that should be done in a separate patch.
> Same goes for the renumbering, it should be a separate patch to adding
> the support for "unknown" direction.

As far as the renaming of FLAG_IS_* to FLAG_DIR_*, I can see it either
way.  I had to touch nearly all the flags with the patch anyway, so
reasoned it was OK to tweak the name at the same time since they would
be reviewed as part of the larger change.  There's only once instance
(the chunk at line 297) where the change consisted only of a rename -
all other locations had functional changes as well.

For the renumbering, it seems pretty trivial and didn't think it was
worth a unique patch just for it.

Anyway, doesn't matter too much to me.  If the powers that be want this
to be split up (or changed to an enum?) let me know.

Best,
Peter


  reply	other threads:[~2011-02-18  0:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 23:03 [PATCH v3 1/4] gpiolib: Add "unknown" direction support Peter Tyser
2011-02-17 23:03 ` [PATCH v3 2/4] gpiolib: Add ability to get GPIO pin direction Peter Tyser
2011-02-18  8:57   ` Uwe Kleine-König
2011-02-18 17:36     ` Peter Tyser
2011-02-18 18:49       ` Uwe Kleine-König
2011-02-18 20:27         ` Peter Tyser
2011-02-17 23:03 ` [PATCH v3 3/4] gpio: pca953x: Implement get_direction() hook Peter Tyser
2011-02-17 23:03 ` [PATCH v3 4/4] gpio: Add support for Intel ICHx/3100/Series[56] GPIO Peter Tyser
2011-02-18 17:58   ` Vincent Palatin
2011-02-18 20:28     ` Peter Tyser
2011-02-18  0:07 ` [PATCH v3 1/4] gpiolib: Add "unknown" direction support Ryan Mallon
2011-02-18  0:33   ` Peter Tyser [this message]
2011-02-18  8:51 ` Uwe Kleine-König

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=1297989224.965.18483.camel@petert \
    --to=ptyser@xes-inc.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alek.du@intel.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=eric.y.miao@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan@bluewatersys.com \
    --cc=sameo@linux.intel.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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