[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y3UHrAQjOnUh4frh@smile.fi.intel.com>
Date: Wed, 16 Nov 2022 17:54:20 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Michael Walle <michael@...le.cc>
Cc: William Breathitt Gray <william.gray@...aro.org>,
robert.marko@...tura.hr, linus.walleij@...aro.org, brgl@...ev.pl,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
broonie@...nel.org
Subject: Re: [PATCH v2 1/4] gpio: regmap: Always set gpio_chip get_direction
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@...ux.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@...le.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.
Sysfs shouldn't be considered nowadays as anything but deprecated and
not-to-use interface. Hence, I don't care what it tells there.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists