linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timo Teras <timo.teras@iki.fi>
To: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [PATCH] gpio: mcp23s08: support setting pullups from device tree data
Date: Tue, 15 Dec 2015 11:23:15 +0200	[thread overview]
Message-ID: <20151215112315.4e0f274b@vostro> (raw)
In-Reply-To: <1922527.uScxQGmYqz@ws-stein>

On Tue, 15 Dec 2015 09:09:04 +0100
Alexander Stein <alexander.stein@systec-electronic.com> wrote:

> On Monday 07 December 2015 09:22:59, Timo Teras wrote:
> > On Mon, 07 Dec 2015 07:53:08 +0100
> > Alexander Stein <alexander.stein@systec-electronic.com> wrote:
> >   
> > The other side is: Why would my gpio-keys input mapping
> > specification need know to what kind of GPIO input it is connected
> > to? What if I switch the GPIO expander - or the hardware schema?  I
> > need to edit 10 different places rather than one - places that are
> > about the high-level functionality, not the hardware. Normally the
> > pullup settings are hardware layout dependant, so GPIO
> > configuration would be the logical place.  
> 
> gpio-keys need to know this when selecting active low or active high.
> You usually need the corresponding pull up/down for this to work.

To me it looks active_low is just software invert. My understanding is
that pullups are practically always fixed configuration depending on how
the connection is physically wired. The only exception being that you
have development board where the physical wiring is subject to change.

> > One generally wants to configure pullups correctly for all GPIOs
> > regardless of if they are connected or not; or if the relevant
> > high-level gpio driver is loaded or not. And this should be done as
> > early as possible - even before the driver for that specific GPIO
> > pin functionality is loaded.  
> 
> This is also a valid point.
> 
> > Perphaps others have more arguments for the per-pin configuration?  
> 
> I get the impression both ways would be needed... which is kinda
> error-prone.

But yeah. If there's valid use cases for pullups to be changed, it
would justify both ways. But if needing to choose, I would prefer
specifying pullup register data in one place. Thus I chose that way
for the patch.

Perhaps this patch could be considered applied as-is then? Or is there
wishes to unify the OF property name?

Thanks,
Timo


      reply	other threads:[~2015-12-15  9:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 11:46 [PATCH] gpio: mcp23s08: support setting pullups from device tree data Timo Teräs
2015-12-07  6:53 ` Alexander Stein
2015-12-07  7:22   ` Timo Teras
2015-12-15  8:09     ` Alexander Stein
2015-12-15  9:23       ` Timo Teras [this message]

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=20151215112315.4e0f274b@vostro \
    --to=timo.teras@iki.fi \
    --cc=alexander.stein@systec-electronic.com \
    --cc=linux-gpio@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;
as well as URLs for NNTP newsgroup(s).