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@xxxxxxxxxxxxxxx>
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@xxxxxxxx>
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
