All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Matt Ranostay <mranostay@gmail.com>,
	Gregor Boirie <gregor.boirie@parrot.com>,
	Sanchayan Maity <maitysanchayan@gmail.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jeff White <Jeff.White@zii.aero>,
	Chris Healy <Chris.Healy@zii.aero>
Subject: Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio
Date: Wed, 24 May 2017 20:38:08 +0100	[thread overview]
Message-ID: <20170524203808.34aec03a@kernel.org> (raw)
In-Reply-To: <5eec10c5-9e13-b0fc-fe40-a8b74a4fdbb0@cogentembedded.com>

On Wed, 24 May 2017 14:27:50 +0300
Vladimir Barinov <vladimir.barinov@cogentembedded.com> wrote:

> On 23.05.2017 11:18, Nikita Yushchenko wrote:
> >>> Reset GPIO is active low.
> >>>
> >>> Currently driver uses gpiod_set_value(1) to clean reset, which depends
> >>> on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.
> >>>
> >>> This fixes driver to use _raw version of gpiod_set_value() to enforce
> >>> active-low semantics despite of what's written in device tree. Allowing
> >>> device tree to override that only opens possibility for errors and does
> >>> not add any value.
> >>>
> >>> Additionally, use _cansleep version to make things work with i2c-gpio
> >>> and other sleeping gpio drivers.  
> >> The reset gpio comes from platform hence it should be handled by DTS.
> >>
> >> In driver the gpio should not be raw.
> >>
> >> Even the hi8435 is active low but platform may invert signal (f.e. by
> >> adding trigger on the circuit path).  
> > I see.  However - isn't this pure theoretic?  Does such case exist?  
> I assure you that this is frequently used.
> 
> Simply search google for "simple voltage level shifter"
> It might be on PNP or NPN transistor, hence logic might be inverted.
> 
> >
> > In vast majority of cases, GPIO polarity is chip-specific, not
> > chip-use-specific.  Thus this knowlege belongs to driver and not to
> > device tree describing particular chip usage.  Having this always
> > defined at usage side is IMO major source of errors.  
> GPIO comes from SoC then "circuit path" and finally chip reset input.
> 
> What do you propose if h/w circuit path has simple voltage level shifter 
> on transistor. How to differentiate PNP and NPN cases?
> 
> Regards,
> Vladimir
> 

Hmm. Ah well, I clearly jumped too fast on this set and should have
left it for a while longer (I rushed a little as I'm away next weekend
and the cycle is moving towards rc3)

Sorry about that.

Anyhow, I am tempted to queue a revert of this patch.  The level
shifting case hadn't occurred to me (oops).

Thoughts?

I'm travelling at the end of this week, so may be the middle
of next before I can do anything about this one.

Jonathan

  reply	other threads:[~2017-05-24 19:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 14:47 [PATCH 1/4] iio: hi8435: add raw access Nikita Yushchenko
2017-05-19 14:48 ` [PATCH 2/4] iio: hi8435: avoid garbage event at first enable Nikita Yushchenko
2017-05-20 16:34   ` Jonathan Cameron
2017-05-22 18:20   ` Vladimir Barinov
2017-05-23  7:21     ` Nikita Yushchenko
2017-05-19 14:48 ` [PATCH 3/4] iio: hi8435: make in_voltage_sensing_mode_available visible Nikita Yushchenko
2017-05-20 16:35   ` Jonathan Cameron
2017-05-22 18:21   ` Vladimir Barinov
2017-05-19 14:48 ` [PATCH 4/4] iio: hi8435: cleanup reset gpio Nikita Yushchenko
2017-05-20 16:37   ` Jonathan Cameron
2017-05-22 18:27   ` Vladimir Barinov
2017-05-23  8:18     ` Nikita Yushchenko
2017-05-24 11:27       ` Vladimir Barinov
2017-05-24 19:38         ` Jonathan Cameron [this message]
2017-05-25  6:27           ` Nikita Yushchenko
2017-05-28 15:42             ` Jonathan Cameron
2017-05-29  7:57               ` Nikita Yushchenko
2017-05-29 17:08             ` Linus Walleij
2017-05-20 16:33 ` [PATCH 1/4] iio: hi8435: add raw access Jonathan Cameron
2017-05-22 17:27   ` Vladimir Barinov

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=20170524203808.34aec03a@kernel.org \
    --to=jic23@kernel.org \
    --cc=Chris.Healy@zii.aero \
    --cc=Jeff.White@zii.aero \
    --cc=gregor.boirie@parrot.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maitysanchayan@gmail.com \
    --cc=mranostay@gmail.com \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=pmeerw@pmeerw.net \
    --cc=vladimir.barinov@cogentembedded.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 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.