IDT 79RC3243x SoCs integrated a gpio controller, which handles up
to 32 gpios. All gpios could be used as an interrupt source.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Drop gpio_regmap_set_drvdata() and instead add it to the configuration
data passed to gpio_regmap_register().

gpio_regmap_set_drvdata() can't really be used in a race free way. This
is because the gpio_regmap object which is needed by _set_drvdata() is
returned by gpio_regmap_register(). On the other hand, the callbacks
which use the drvdata might already be called right after the
gpiochip_add() call in gpio_regmap_register(). Therefore, we have to
provide the drvdata early before we call gpiochip_add().
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Drop unused headers and drop the rest.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Tested-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Slightly simplify the devm_gpio_regmap_register() by using the
devm_add_action_or_reset().
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

We have open coded variant of fwnode_irq_get() in dwapb_get_irq().
Replace it with a simple call.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

For more than 15 years we may not get into ->irq_set_type()
without any meaningful type provided.

Drop redundant check in dwapb_irq_set_type().

See the commit e76de9f8 ("[PATCH] genirq: add SA_TRIGGER support")
out of curiosity.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Fixed multiple bare uses of 'unsigned' without int.
Reported by checkpatch.
Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Switch to bitmap_alloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Split fastpath array to two, i.e. for mask and for bits.
At the same time declare them as bitmaps.

This makes code better to read and gives a clue about use of
bitmap API.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Convert the OMAP GPIO Device Tree binding documentation to json-schema.
The GPIO hogs node names defined to end with a 'hog' suffix.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.

This change isn't removing the 'DT probe failed' message, as some may find
it useful as a reason for the failed probe. But that can be part of another
change if needed.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The tegra186_gpio_remove hook simply does a return 0.
Not defining it yields pretty much the same result.
So, this can be removed.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The handling of the return value from devm_gpiochip_add_data() is a bit
redundant. It prints messages on error and success cases.
While the success message may be useful, it is more in the area of log
spam, and these can be printed with other forms of kernel logging.

This change does a direct return with devm_gpiochip_add_data() in the probe
function.

The platform_set_drvdata() is needed, as this driver uses the stored
private date in the PM suspend/resume routines.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

This also means that the 'err' label can be removed and all goto statements
replaced with direct returns (with error codes).
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information.
Since the driver doesn't do that, it's not useful to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The sysfs_emit() function was introduced to make it less ambiguous
which function is preferred when writing to the output buffer in
a "show" callback [1].

Convert the GPIO library sysfs interface from sprintf() to sysfs_emit()
accordingly, as the latter is aware of the PAGE_SIZE buffer and correctly
returns the number of bytes written into the buffer.

No functional change intended.

[1] Documentation/filesystems/sysfs.rst
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

We have for some time the assign_bit() API to replace open coded

	if (foo)
		set_bit(n, bar);
	else
		clear_bit(n, bar);

Use this API in GPIO library code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The platform_set_drvdata() call is only useful if we need to retrieve back
the private information. Since the driver doesn't do that, it's not useful
to have it.

If this is removed, we can also just do a direct return on
devm_gpiochip_add_data(). We don't need to print that this call failed as
there are other ways to log/see this during probe.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The IRQ is registered via devm_request_threaded_irq(), making the driver
only partially device-managed. This changeset converts the entire driver
to using only devres APIs.

This change also removes platform_set_drvdata() since the information is
never retrieved to be used in the driver.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
[Bart: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

In IRQ handler interrupts are already disabled, hence no need
to repeat it. Even in the threaded case, it is not a problem
because IRQ framework keeps interrupt disabled there as well.
Remove disabling IRQ part in the handler.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neeli Srinivas <sneeli@xilinx.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

It seems that Xilinx GPIO driver operates with bit arrays longer than 32 and
thus can leverage bitmap APIs for that. It makes code better to understand.

The ->probe() function is modified to try read properties for both channels
since is_dual check makes only sense for the amount of pins used for the second
channel. On top of that kzalloc() guarantees zero initial values for the fields
in the private data structure, hence drop unneeded conditionals and assignments.

The change is inspired by Syed Nayyar Waris' ideas about bitmap API extension.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neeli Srinivas <sneeli@xilinx.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

With the new helpers, i.e. xgpio_read_chan() / xgpio_write_chan(),
the code is easier to read and maintain. No functional changes
intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neeli Srinivas <sneeli@xilinx.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Currently the bitmap_remap() and bitmap_bitremap() are available
only for CONFIG_NUMA=y case, while some users may benefit out of it
and being independent to NUMA code. Make them available to users
by moving out of ifdeffery and exporting for modules.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neeli Srinivas <sneeli@xilinx.com>
Acked-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpiochip_get_desc() already does the check, drop a duplicate in
gpiochip_is_requested().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>