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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Acked-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: NBartosz 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: NAlexandru Ardelean <aardelean@deviqon.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
[Bart: tweaked the commit message]
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NNeeli Srinivas <sneeli@xilinx.com>
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NNeeli Srinivas <sneeli@xilinx.com>
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NNeeli Srinivas <sneeli@xilinx.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

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

Switch to use gpiochip_get_desc() helper.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz 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: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fix the following gcc warning:

drivers/gpio/gpio-mxs.c:63:19: warning: kernel/sys_ni.cunused function
'is_imx28_gpio'.
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fix the following clang warning:

drivers/gpio/gpio-it87.c:128:20: warning: unused function 'superio_outw'
[-Wunused-function].
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Acked-by: NSimon Guinot <simon.guinot@sequanux.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fixed multiple bare uses of 'unsigned' without 'int'.
Fixed space around "*" operator.
Fixed function parameter alignment to opening parenthesis.
Reported by checkpatch.
Signed-off-by: NBarney Goette <barneygoette@gmail.com>
Acked-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Current implementation only supports DT, now add ACPI support.
Signed-off-by: NRan Wang <ran.wang_1@nxp.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Driver is neither dependent to PCI nor using MFD_CORE.
Replace those dependency and selection by dependency on LPC_ICH.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Since we are depended on LPC_SCH, which selects MFD_CORE,
we don't need to do it ourselves.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Since LPC_SCH provides GPIO functionality, GPIO_SCH should depend on
LPC_SCH to prevent kconfig warning and build errors:

WARNING: unmet direct dependencies detected for LPC_SCH
  Depends on [n]: HAS_IOMEM [=y] && PCI [=n]
  Selected by [y]:
  - GPIO_SCH [=y] && GPIOLIB [=y] && X86 [=y] && (X86 [=y] || COMPILE_TEST [=n]) && ACPI [=y]

and

../drivers/mfd/lpc_sch.c:204:1: warning: data definition has no type or storage class
 module_pci_driver(lpc_sch_driver);
 ^~~~~~~~~~~~~~~~~
../drivers/mfd/lpc_sch.c:204:1: error: type defaults to ‘int’ in declaration of ‘module_pci_driver’ [-Werror=implicit-int]
../drivers/mfd/lpc_sch.c:204:1: warning: parameter names (without types) in function declaration
../drivers/mfd/lpc_sch.c:197:26: warning: ‘lpc_sch_driver’ defined but not used [-Wunused-variable]
 static struct pci_driver lpc_sch_driver = {
                          ^~~~~~~~~~~~~~

Fixes: 6c46215d6b62 ("gpio: sch: Hook into ACPI GPE handler to catch GPIO edge events")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Like some other Bay and Cherry Trail SoC based devices the Dell Venue
10 Pro 5055 has an embedded-controller which uses ACPI GPIO events to
report events instead of using the standard ACPI EC interface for this.

The EC interrupt is only used to report battery-level changes and
it keeps doing this while the system is suspended, causing the system
to not stay suspended.

Add an ignore-wake quirk for the GPIO pin used by the EC to fix the
spurious wakeups from suspend.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Neither the ACPI description on Intel Minnowboard (v1) platform provides
the required information to establish a generic handling nor the hardware
capable of doing it. According to the data sheet the hardware can generate
SCI events. Therefore, we need to hook from the driver into GPE handler of
the ACPI subsystem in order to catch and report GPIO-related events.

Validated on the Inlel Minnowboard (v1) platform and Intel Galileo Gen 2.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>