Replace usage of strncpy() with strscpy() to remove -Wstringop-truncation
warnings.

The structures being populated are zeroed, to prevent stack leakage as
they are returned to userspace, so strscpy() performs the equivalent
function without the warnings.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Set the value of the line info offset in gpio_desc_to_lineinfo(), rather
than relying on it being passed in the info.  This makes the function
behave as you would expect from the name - it generates the line info
corresponding to a given GPIO desc.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Let's move the code preparing the device properties into a separate
routine. This has the advantage of simplifying the error handling and
makes the indentation less deep.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

GPIO line names are currently created by the driver from the chip label.
We'll want to support custom formats for line names (for instance: to
name all lines the same) for user-space tests so create them in the
module init function and pass them to the driver using the standard
'gpio-line-names' property.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

While we do check the "chip-name" property in probe(), we never actually
use it. Let's pass the chip label to the driver using device properties
as we'll want to allow users to define their own once dynamically
created chips are supported.

The property is renamed to "chip-label" to not cause any confusion with
the actual chip name which is of the form: "gpiochipX".

If the "chip-label" property is missing, let's do what most devices in
drivers/gpio/ do and use dev_name().
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The driver actually supports 4 properties but we only ever set up up to
three. This will change however in upcoming patches so increase the
number of really (as in: the number the property array can hold)
supported properties to 4.
Reported-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

There's a return; at the end of a void function. This is not needed so
remove it.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

We don't need a custom logging helper. Let's use the standard pr_fmt()
macro which allows us to use all pr_*() routines with custom format.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Drop the definition for the driver name. Let's use KBUILD_MODNAME for
the log format and use the "gpio-mockup" value directly in the only
place where it's relevant: in the name of the device.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This module doesn't need gpio/consumer.h - it's a provider. It also
doesn't use any symbols from init.h so let's remove both includes.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Some Layerscape/QoriQ SoCs have input buffers which needs to be enabled
first. This was done in two different ways in the driver. Unify it.

This was tested on a LS1028A SoC.
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

If the module init function fails after creating the debugs directory,
it's never removed. Add proper cleanup calls to avoid this resource
leak.

Fixes: 9202ba23 ("gpio: mockup: implement event injecting over debugfs")
Cc: <stable@vger.kernel.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Change config to tristate, add module device table, module author,
description and license to support module build for i.MX GPIO driver.

As this is a SoC GPIO module, it provides common functions for most
of the peripheral devices, such as GPIO pins control, secondary
interrupt controller for GPIO pins IRQ etc., without GPIO driver, most
of the peripheral devices will NOT work properly, so GPIO module is
similar with clock, pinctrl driver that should be loaded ONCE and
never unloaded.

Since MXC GPIO driver needs to have init function to register syscore
ops once, here still use subsys_initcall(), NOT module_platform_driver().
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1600320829-1453-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's possible for a GPIO chip to not have a parent device (whose
properties we inspect for 'gpio-line-names'). In this case we should
simply return from devprop_gpiochip_set_names(). Add an appropriate
check for this use-case.

Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Reported-by: NAnders Roxell <anders.roxell@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NAnders Roxell <anders.roxell@linaro.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that devprop_gpiochip_set_names() is only used in a single place
inside drivers/gpio/gpiolib.c, there's no need anymore for it to be
exported or to even live in its own source file. Pull this function into
the core source file for gpiolib.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() & of_fwnode_handle()
in ACPI and OF GPIO code respectively). Let's just switch to using the
generic device properties.

This allows us to pull the code setting line names directly into
gpiochip_add_data_with_key() instead of handling it separately for
ACPI and OF.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.

ida_simple_get(ida, 0, 0, gfp) is equivalent to
ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to
ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID
larger than INT_MAX.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

On tc35894, have to disable direct keypad interrupts to make
it as general purpose interrupts functionality work.
if not, after chip reset, IRQST(0x91) will always 0x20,
IRQN always low level, can't be clear.

Configure DIRECTx to enable general purpose gpio mode,
else read GPIOMISx register always zero in irq routine.

verified on tc35894, need more test on other tc3589x.
Signed-off-by: Ndillon min <dillon.minfei@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Since the resource managed version of gpiochip_add_data() will handle the
GPIO-chip data automated cleanup we can freely remove the DW APB GPIO
driver code responsible for that. After doing so the DW APB GPIO driver
removal callback can be also fully discarded since there is nothing left
to be done for it. All the cleanups are now performed by means of the
device managed framework.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-11-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The kernel clock framework provides the resource managed version of
the clk_bulk_get() method. The only thing which needs to be also automated
is the clocks disable/unprepare procedure executed on the device removal.
It can be implemented by means of the custom action definition. After that
the clocks acquisition and release will be purely managed by the device
resources interface.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-10-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The reset control interface provides the resource managed version of
the reset_control_get() method. The only thing which needs to be also
automated is the reset lane assertion on the device removal. It can be
implemented by means of the custom action definition. After that the reset
control will be purely managed by the device resources interface.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-9-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since GPIOlib-based IRQ-chip interface is now utilized there is no need
in calling the methods acpi_gpiochip_{request,free}_interrupts() here.
They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove()
anyway.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-8-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since GPIOlib-based IRQ-chip interface is now utilized there is no need in
setting up a custom GPIO-to-IRQ mapping method. GPIO-lib defines the
standard mapping method - gpiochip_to_irq(), which will be used anyway no
matter whether the custom to_irq callback is specified or not.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-7-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO-lib provides a ready-to-use interface to initialize an IRQ-chip on
top of a GPIO chip. It's better from maintainability and readability
point of view to use one instead of supporting a hand-written Generic
IRQ-chip-based implementation. Moreover the new implementation won't
cause much functional overhead but will provide a cleaner driver code.
All of that makes the DW APB GPIO driver conversion pretty much justified
especially seeing a tendency of the other GPIO drivers getting converted
too.

Here is what we do in the framework of this commit to convert the driver
to using the GPIO-lib-based IRQ-chip interface:

1) IRQ ack, mask and unmask callbacks are locally defined instead of
using the Generic IRQ-chip ones.

2) An irq_chip structure instance is embedded into the dwapb_gpio
private data. Note we can't have a static instance of that structure since
GPIO-lib will add some hooks into it by calling gpiochip_set_irq_hooks().
A warning about that would have been printed by the GPIO-lib code if we
used a single irq_chip structure instance for multiple DW APB GPIO
controllers.

3) Initialize the gpio_irq_chip structure embedded into the gpio_chip
descriptor. By default there is no IRQ enabled so any event raised will be
handled by the handle_bad_irq() IRQ flow handler. If DW APB GPIO IP-core
is synthesized to have non-shared reference IRQ-lines, then as before the
hierarchical and cascaded cases are distinguished by checking how many
parental IRQs are defined. (Note irq_set_chained_handler_and_data() won't
initialize IRQs, which descriptors couldn't be found.) If DW APB GPIO IP
is used on a platform with shared IRQ line, then we simply won't let the
GPIO-lib to initialize the parental IRQs, but will handle them locally in
the driver.

4) Discard linear IRQ-domain and Generic IRQ-chip initialization, since
GPIO-lib IRQ-chip interface will create a new domain and accept a standard
IRQ-chip structure pointer based on the setting we provided in the
gpio_irq_chip structure.

5) Manually select a proper IRQ flow handler directly in the
irq_set_type() callback by calling irq_set_handler_locked() method, since
an ordinary (not Generic) irq_chip descriptor is now utilized. Note this
shalln't give any regression

6) Alter CONFIG_GPIO_DWAPB kernel config to select
CONFIG_GPIOLIB_IRQCHIP instead of CONFIG_GENERIC_IRQ_CHIP.

Note neither 4) nor 5) shall cause a regression of commit 6a2f4b7d
("gpio: dwapb: use a second irq chip"), since the later isn't properly
used here anyway.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-6-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add a new macro DWAPB_MAX_GPIOS which defines the maximum possible number
of GPIO lines corresponding to the maximum DW APB GPIO controller port
width. Use the new macro instead of number literal 32 where it's
applicable.
Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-5-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

For better readability let's group all the IRQ handlers in a single place
of the driver instead of having them scatter around all over the file.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-4-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Indeed generic GPIO DT-schema implies that number of GPIOs should be
described by the "ngpios" property located under a GPIO-provider DT node.
In that case it's redundant to have a vendor-specific "snps,nr-gpios"
property describing the same setting. Moreover it might be errors prone.

Since commit 93d2e432 ("of: platform: Batch fwnode parsing when adding
all top level devices") the fwnode parsing is resumed after the vast
majority of the platform devices are added. Implicitly that commit
activates re-parsing of the whole device tree GPIOs-phandle properties
detected having "-gpio/-gpios" suffixes. Since the vendor-specific number
of GPIOs property is defined with "-gpios" suffix, then of_link_property()
will consider it as a suffix-property with "#gpio-cells" structure, which
obviously it doesn't have. As a result for two DW APB GPIO controllers
we'll have the next errors printed.

OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle
OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-table
OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle
OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-table

See, the kernel fwnode parsing procedure even tried to resolve the phandle
ID, which it thought was the opp-table DT-node, while in fact it was just
a number "32". What would happen if that magic number actually referred to
a GPIO DT-node with "#gpio-cells" property defined?..

In order to fix the problem let's mark the "snps,nr-gpios" property as
deprecated and add the generic "ngpios" property support with the same
purpose as the deprecated one. That and the errors log above shall
motivate the platform developer to convert the DW APB GPIO DT-nodes to
using the standard number of GPIOs property.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200730152808.2955-3-Sergey.Semin@baikalelectronics.ruSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Sparse can't see locking scheme used in ->get_multiple() and
->set_multiple() callbacks.
  CHECK   .../drivers/gpio/gpio-aggregator.c
  .../spinlock.h:409:9: warning: context imbalance in 'gpio_fwd_get_multiple' - unexpected unlock
  .../spinlock.h:409:9: warning: context imbalance in 'gpio_fwd_set_multiple' - unexpected unlock

Refactor them to have better readability and make Sparse happy.

Code size impact is +52 bytes with arm-linux-gnueabihf-gcc 7.5.0.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Ar10 (xr300) has 3 and grx390 (xrx330) has 4 built-in GPHY. PHY LEDs are
connected via STP. STP is a peripheral controller used to drive external
shift register cascades. The hardware is able to allow the GPHY to drive
some GPIO of the cascade automatically.This patch allows for this on ar10
and grx390.

Tested on D-Link DWR-966 with OpenWRT.
Signed-off-by: NAleksander Jan Bajkowski <olek2@wp.pl>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

There is logically better to request IRQ when we initialise all structures.
Align the driver with the rest on the same matter.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200728125504.27786-3-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

It appears that all, but request_irq(), calls in the driver are device managed.
In unlikely case of devm_gpiochip_add_data() failure the IRQ left requested.
Free IRQ on error path by switching to devm_request_threaded_irq() API.

Byproduct of this change is a drop of ->remove() callback completely.

Fixes: 945e72db ("gpio: crystalcove: Use irqchip template")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200728125504.27786-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is logically better to request IRQ when we initialise all structures.
Align the driver with the rest on the same matter.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200728125504.27786-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 959bc7b2 ("gpio: Automatically add lockdep keys") documents
in its commits message its intention to "create a unique class key for
each driver".

It does so by having gpiochip_add_data add in-place the definition of
two static lockdep classes for LOCKDEP use. That way, every caller of
the macro adds their gpiochip with unique lockdep classes.

There are many indirect callers of gpiochip_add_data, however, via
use of devm_gpiochip_add_data. devm_gpiochip_add_data has external
linkage and all its users will share the same lockdep classes, which
probably is not intended.

Fix this by replicating the gpio_chip_add_data statics-in-macro for
the devm_ version as well.

Fixes: 959bc7b2 ("gpio: Automatically add lockdep keys")
Signed-off-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.deSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>