Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 17 Nov 2022 09:22:31 -0500
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
Message-ID: <Y3ZDp6skghvMyaKv@fedora>
References: <cover.1668129763.git.william.gray@linaro.org>
 <1805d1ddb5bbce8e86164e66421ddde481cce4f9.1668129763.git.william.gray@linaro.org>
 <Y3DlsTAQMi6kKObJ@smile.fi.intel.com>
 <Y3DvUaA7YYAsypGv@fedora>
 <cc33aaa342ad60749d2f7c2a6d690733@walle.cc>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="enTNzqmh6/WJTuPZ"
Content-Disposition: inline
In-Reply-To: <cc33aaa342ad60749d2f7c2a6d690733@walle.cc>
Precedence: bulk


--enTNzqmh6/WJTuPZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 on=
ly
> > > > 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.
> > >=20
> > > 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.
> > >=20
> > > From the code perspective:
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >=20
> > 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.
>=20
> For the sl28cpld driver this shouldn't be a problem. So for that
> Acked-by: Michael Walle <michael@walle.cc>
>=20
> 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:
>=20
>  * MAY BE OMITTED if kernel won't allow direction changes
>=20
> So from a gpiolib/sysfs POV I'm not sure about this change. Does
> get_direction =3D=3D NULL means setting the direction isn't possible?
> OTHO there is a fat "MAY" :)
>=20
> Which brings me to the question of "why this change?". The commit
> message doesn't mention it. Just out of curiosity.
>=20
> -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

--enTNzqmh6/WJTuPZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCY3ZDpwAKCRC1SFbKvhIj
K+zwAP91upqRhQV1dEM30LJyPIHO0ZHSXcyFgPN/PzNpEzV9cAEAvGvb9qHtmdAk
xs3ibm0MRBsHFvbknnITdjEwBm27pg8=
=/k59
-----END PGP SIGNATURE-----

--enTNzqmh6/WJTuPZ--