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>
We need to be able to translate GPIO resources in an ACPI device's _CRS
into GPIO descriptor array. Those are represented in _CRS as a pathname
to a GPIO device plus the pin's index number: the acpi_get_gpiod()
function is perfect for that purpose.
As it's currently only used internally within the GPIO layer, provide and
export a wrapper function that additionally holds a reference to the GPIO
device.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.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 e76de9f8eb ("[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>
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>
bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1)
which is not right, and this was caught by below usban check
UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14
Fixes: 59c3246834 ("gpio: wcd934x: Add support to wcd934x gpio controller")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@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>
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>
The wcove_gpio_dbg_show() uses one message to all possible error reads.
Split it to two for CTRL and IRQ registers.
While at it, switch to use dev_err() instead of pr_err().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Use ternary and rename parameter to 'type' in to_reg() to be in
the same style as to_ireg().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
IRQ framework provides special type and getter to transform Linux IRQ
to the hardware pin. Use that type and getter function instead of
direct access. No functional changes intended.
While at it, remove unneeded check in wcove_update_irq_ctrl() since
it is guaranteed that function will be called with valid parameter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
When hotplugging CPUs on Tegra186 and Tegra194 errors such as the
following are seen ...
IRQ63: set affinity failed(-22).
IRQ65: set affinity failed(-22).
IRQ66: set affinity failed(-22).
IRQ67: set affinity failed(-22).
Looking at the /proc/interrupts the above are all interrupts associated
with GPIOs. The reason why these error messages occur is because there
is no 'parent_data' associated with any of the GPIO interrupts and so
tegra186_irq_set_affinity() simply returns -EINVAL.
To understand why there is no 'parent_data' it is first necessary to
understand that in addition to the GPIO interrupts being routed to the
interrupt controller (GIC), the interrupts for some GPIOs are also
routed to the Tegra Power Management Controller (PMC) to wake up the
system from low power states. In order to configure GPIO events as
wake events in the PMC, the PMC is configured as IRQ parent domain
for the GPIO IRQ domain. Originally the GIC was the IRQ parent domain
of the PMC and although this was working, this started causing issues
once commit 64a267e9a4 ("irqchip/gic: Configure SGIs as standard
interrupts") was added, because technically, the GIC is not a parent
of the PMC. Commit c351ab7bf2 ("soc/tegra: pmc: Don't create fake
interrupt hierarchy levels") fixed this by severing the IRQ domain
hierarchy for the Tegra GPIOs and hence, there may be no IRQ parent
domain for the GPIOs.
The GPIO controllers on Tegra186 and Tegra194 have either one or six
interrupt lines to the interrupt controller. For GPIO controllers with
six interrupts, the mapping of the GPIO interrupt to the controller
interrupt is configurable within the GPIO controller. Currently a
default mapping is used, however, it could be possible to use the
set affinity callback for the Tegra186 GPIO driver to do something a
bit more interesting. Currently, because interrupts for all GPIOs are
have the same mapping and any attempts to configure the affinity for
a given GPIO can conflict with another that shares the same IRQ, for
now it is simpler to just remove set affinity support and this avoids
the above warnings being seen.
Cc: <stable@vger.kernel.org>
Fixes: c4e1f7d92c ("gpio: tegra186: Set affinity callback to parent")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Kernel doc validator complains:
.../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe(). Prototype was for xgpio_probe() instead
Correct as suggested by changing the name of the function in the doc..
Fixes: 749564ffd5 ("gpio/xilinx: Convert the driver to platform device interface")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neeli Srinivas <sneeli@xilinx.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
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>
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
binary size.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
