All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Breathitt Gray <william.gray@linaro.org>
To: Michael Walle <michael@walle.cc>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	robert.marko@sartura.hr, linus.walleij@linaro.org, brgl@bgdev.pl,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	broonie@kernel.org
Subject: Re: [PATCH v2 1/4] gpio: regmap: Always set gpio_chip get_direction
Date: Thu, 17 Nov 2022 09:22:31 -0500	[thread overview]
Message-ID: <Y3ZDp6skghvMyaKv@fedora> (raw)
In-Reply-To: <cc33aaa342ad60749d2f7c2a6d690733@walle.cc>

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

On Wed, Nov 16, 2022 at 04:41:30PM +0100, Michael Walle wrote:
> Am 2022-11-13 14:21, schrieb William Breathitt Gray:
> > On Sun, Nov 13, 2022 at 02:40:17PM +0200, Andy Shevchenko wrote:
> > > On Thu, Nov 10, 2022 at 08:55:50PM -0500, William Breathitt Gray
> > > wrote:
> > > > If you only have reg_dat_base set, then it is input-only; if you only
> > > > have reg_set_base set, then it is output-only. Thus, we can always set
> > > > gpio_chip get_direction to gpio_regmap_get_direction and return
> > > > GPIO_LINE_DIRECTION_IN/GPIO_LINE_DIRECTION_OUT given the respective
> > > > register base addresses configuration.
> > > 
> > > Seems legit to me. Have you checked if we have any gpio-regmap
> > > drivers that
> > > have something like this in their configuration already? In such
> > > cases we need
> > > to be sure they behave as expected.
> > > 
> > > From the code perspective:
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > I see gpio-sl28cpld has two device types SL28CPLD_GPO (output-only) and
> > SL28CPLD_GPI (input-only); gpio-tn48m similarly has two device types
> > TN48M_GPO (output-only) and TN48M_GPI (input-only). It doesn't look like
> > the change in this patch will cause problems for them, but I'll let
> > Michael Walle and Robert Marko comment if they see issues here.
> 
> For the sl28cpld driver this shouldn't be a problem. So for that
> Acked-by: Michael Walle <michael@walle.cc>
> 
> But back when I wrote gpio-regmap the bgpio served as a blue print.
> There is the same handling. If you look at gpiolib-sysfs.c there
> is a comment about the direction property:
> 
>  * MAY BE OMITTED if kernel won't allow direction changes
> 
> So from a gpiolib/sysfs POV I'm not sure about this change. Does
> get_direction == NULL means setting the direction isn't possible?
> OTHO there is a fat "MAY" :)
> 
> Which brings me to the question of "why this change?". The commit
> message doesn't mention it. Just out of curiosity.
> 
> -michael

Currently, the 104-idi-48 module implements a get_direction() callback
that is executed in situations such as gpiod_get_direction() which
aren't necessarily related to sysfs. In this patch series, the
104-idi-48 module is migrated to the gpio_regmap API, but loses this
get_direction() support because it's an input-only configuration. The
purpose of this patch is to prevent that regression by supporting
get_direction() for input-only/output-only configurations.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2022-11-17 14:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  1:55 [PATCH v2 0/4] Migrate i8255 GPIO drivers to regmap API William Breathitt Gray
2022-11-11  1:55 ` [PATCH v2 1/4] gpio: regmap: Always set gpio_chip get_direction William Breathitt Gray
2022-11-13 12:40   ` Andy Shevchenko
2022-11-13 13:21     ` William Breathitt Gray
2022-11-16 11:34       ` Robert Marko
2022-11-16 15:41       ` Michael Walle
2022-11-16 15:54         ` Andy Shevchenko
2022-11-17 14:22         ` William Breathitt Gray [this message]
2022-11-17 14:36           ` Michael Walle
2022-11-11  1:55 ` [PATCH v2 2/4] regmap-irq: Add handle_mask_sync() callback William Breathitt Gray
2022-11-13 12:42   ` Andy Shevchenko
2022-11-13 13:08     ` William Breathitt Gray
2022-11-13 13:11       ` Andy Shevchenko
2022-11-15 17:14   ` Mark Brown
2022-11-17 15:00     ` William Breathitt Gray
2022-11-22  1:00       ` William Breathitt Gray
2022-11-11  1:55 ` [PATCH v2 3/4] gpio: 104-idi-48: Migrate to regmap API William Breathitt Gray
2022-11-11  1:55 ` [PATCH v2 4/4] gpio: i8255: " William Breathitt Gray
2022-11-13 12:52   ` Andy Shevchenko
2022-11-13 14:07     ` William Breathitt Gray
2022-11-13 14:13       ` William Breathitt Gray
2022-11-14 13:14         ` Andy Shevchenko
2022-11-17 16:18   ` Michael Walle
2022-11-17 16:21     ` Mark Brown
2022-11-17 16:30       ` Michael Walle
2022-11-18 11:51         ` Mark Brown
2022-11-20 16:57           ` William Breathitt Gray

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=Y3ZDp6skghvMyaKv@fedora \
    --to=william.gray@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=robert.marko@sartura.hr \
    /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.