public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: Semi Malinen <semi.malinen@ge.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-aspeed@lists.ozlabs.org,
	David Daney <david.daney@cavium.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	alsa-devel@alsa-project.org, Peter Tyser <ptyser@xes-inc.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Fabio Estevam <festevam@gmail.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Michal Simek <michal.simek@xilinx.com>,
	Marek Behun <marek.behun@nic.cz>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Joel Stanley <joel@jms.id.au>,
	Uwe
Subject: Re: [PATCH 00/62] Add definition for GPIO direction
Date: Tue, 5 Nov 2019 14:20:42 +0200	[thread overview]
Message-ID: <20191105122042.GO32742@smile.fi.intel.com> (raw)
In-Reply-To: <cover.1572875541.git.matti.vaittinen@fi.rohmeurope.com>

On Tue, Nov 05, 2019 at 12:09:10PM +0200, Matti Vaittinen wrote:
> The patch series adds definitions for GPIO line directions.
> 
> For occasional GPIO contributor like me it is always a pain to remember
> whether 1 or 0 was used for GPIO direction INPUT/OUTPUT. Judging the
> fact that I removed few comments like:
> 
> /* Return 0 if output, 1 if input */
> /* This means "out" */
> return 1; /* input */
> return 0; /* output */
> 
> it seems at least some others may find it hard to remember too. Adding
> defines for these values helps us who really have good - but short
> duration - memory :]
> 
> Please also see the last patch. It adds warning prints to be emitted
> from gpiolib if other than defined values are used. This patch can be
> dropped out if there is a reason for that to still be allowed.
> 
> This idea comes from RFC series for ROHM BD71828 PMIC and was initially
> discussed with Linus Walleij here:
> https://lore.kernel.org/lkml/c06725c3dd34118a324907137758d8b85b3d4043.camel@fi.rohmeurope.com/
> but as this has no dependencies to BD71828 work (which probably takes a
> while) I decided to make it independent series.
> 
> Patches are compile-tested only. I have no HW to really test them. Thus I'd
> appreciate carefull review. This work is mainly about converting zeros
> and ones to the new defines but it wouldn't be first time I get it wrong
> in one of the patches :)

For all patches I have been Cc'ed to, NAK.

I don't see the advantages now since all known hardware uses the single bit to
describe direction (even for Intel where we have separate gating for in and out
buffers the direction we basically rely on the bit that enables out buffer).

So, that said the direction is always 1 bit and basically 0/1 value. Which one
is in and which one is out just a matter of an agreement we did.

I would also like to see bloat-o-meter statistics before and after your patch.
My guts tell me that the result will be not in the favour of yours solution.

-- 
With Best Regards,
Andy Shevchenko

  parent reply	other threads:[~2019-11-05 12:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 10:09 [PATCH 00/62] Add definition for GPIO direction Matti Vaittinen
2019-11-05 10:42 ` [PATCH 62/62] gpiolib: Nag for INPUT direction values other than GPIO_LINE_DIRECTION_IN Matti Vaittinen
2019-11-05 10:54 ` [PATCH 00/62] Add definition for GPIO direction Vaittinen, Matti
2019-11-05 12:20 ` Andy Shevchenko [this message]
2019-11-05 12:54   ` Vaittinen, Matti
2019-11-05 13:10     ` Uwe Kleine-König
2019-11-05 13:30       ` Vaittinen, Matti
2019-11-05 13:36         ` Uwe Kleine-König
2019-11-05 14:00           ` Vaittinen, Matti
2019-11-05 14:59             ` Uwe Kleine-König
2019-11-05 15:06               ` Vaittinen, Matti
2019-11-05 15:17               ` andriy.shevchenko
2019-11-05 13:30       ` andriy.shevchenko
2019-11-05 13:40         ` Uwe Kleine-König
2019-11-05 14:28           ` andriy.shevchenko
2019-11-05 13:11     ` andriy.shevchenko
2019-11-05 13:54       ` Vaittinen, Matti
2019-11-05 14:32         ` andriy.shevchenko
2019-11-05 13:10 ` [RESEND PATCH 01/62] gpio: " Matti Vaittinen

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=20191105122042.GO32742@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=alexandre.torgue@st.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=david.daney@cavium.com \
    --cc=f.fainelli@gmail.com \
    --cc=festevam@gmail.com \
    --cc=joel@jms.id.au \
    --cc=jonathanh@nvidia.com \
    --cc=khilman@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=ludovic.desroches@microchip.com \
    --cc=marek.behun@nic.cz \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=michal.simek@xilinx.com \
    --cc=ptyser@xes-inc.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=semi.malinen@ge.com \
    --cc=thierry.reding@gmail.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