public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox