2019-07-17 07:10:01 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
|
|
|
|
|
#ifndef GPIOLIB_OF_H
|
|
|
|
|
#define GPIOLIB_OF_H
|
|
|
|
|
|
|
|
|
|
struct gpio_chip;
|
|
|
|
|
enum of_gpio_flags;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_OF_GPIO
|
|
|
|
|
struct gpio_desc *of_find_gpio(struct device *dev,
|
|
|
|
|
const char *con_id,
|
|
|
|
|
unsigned int idx,
|
|
|
|
|
unsigned long *lookupflags);
|
|
|
|
|
int of_gpiochip_add(struct gpio_chip *gc);
|
|
|
|
|
void of_gpiochip_remove(struct gpio_chip *gc);
|
|
|
|
|
int of_gpio_get_count(struct device *dev, const char *con_id);
|
2019-07-31 22:28:26 +00:00
|
|
|
bool of_gpio_need_valid_mask(const struct gpio_chip *gc);
|
gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default
There are multiple instances of GPIO device tree nodes of the form:
foo {
compatible = "acme,foo";
...
gpio0: gpio0@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
gpio1: gpio1@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
...
}
bazz {
my-gpios = <&gpio0 ...>;
}
Case 1: The driver for "foo" populates struct device for these gpio*
nodes and then probes them using a driver that binds with "acme,bar".
This driver for "acme,bar" then registers the gpio* nodes with gpiolib.
This lines up with how DT nodes with the "compatible" property are
typically converted to struct devices and then registered with driver
core to probe them. This also allows the gpio* devices to hook into all
the driver core capabilities like runtime PM, probe deferral,
suspend/resume ordering, device links, etc.
Case 2: The driver for "foo" doesn't populate struct devices for these
gpio* nodes before registering them with gpiolib. Instead it just loops
through its child nodes and directly registers the gpio* nodes with
gpiolib.
Drivers that follow case 2 cause problems with fw_devlink=on. This is
because fw_devlink will prevent bazz from probing until there's a struct
device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO
supplier). Once the struct device is available, fw_devlink will create a
device link with gpio0 device as the supplier and bazz device as the
consumer. After this point, since the gpio0 device will never bind to a
driver, the device link will prevent bazz device from ever probing.
Finding and refactoring all the instances of drivers that follow case 2
will cause a lot of code churn and it is not something that can be done
in one shot. In some instances it might not even be possible to refactor
them cleanly. Examples of such instances are [1] [2].
This patch works around this problem and avoids all the code churn by
simply setting the fwnode of the gpio_device and creating a stub driver
to bind to the gpio_device. This allows all the consumers to continue
probing when the driver follows case 2.
[1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
[2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/
Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-22 19:35:59 +00:00
|
|
|
void of_gpio_dev_init(struct gpio_chip *gc, struct gpio_device *gdev);
|
2019-07-17 07:10:01 +00:00
|
|
|
#else
|
|
|
|
|
static inline struct gpio_desc *of_find_gpio(struct device *dev,
|
|
|
|
|
const char *con_id,
|
|
|
|
|
unsigned int idx,
|
|
|
|
|
unsigned long *lookupflags)
|
|
|
|
|
{
|
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
}
|
|
|
|
|
static inline int of_gpiochip_add(struct gpio_chip *gc) { return 0; }
|
|
|
|
|
static inline void of_gpiochip_remove(struct gpio_chip *gc) { }
|
|
|
|
|
static inline int of_gpio_get_count(struct device *dev, const char *con_id)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2019-07-31 22:28:26 +00:00
|
|
|
static inline bool of_gpio_need_valid_mask(const struct gpio_chip *gc)
|
2019-07-17 07:10:01 +00:00
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default
There are multiple instances of GPIO device tree nodes of the form:
foo {
compatible = "acme,foo";
...
gpio0: gpio0@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
gpio1: gpio1@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};
...
}
bazz {
my-gpios = <&gpio0 ...>;
}
Case 1: The driver for "foo" populates struct device for these gpio*
nodes and then probes them using a driver that binds with "acme,bar".
This driver for "acme,bar" then registers the gpio* nodes with gpiolib.
This lines up with how DT nodes with the "compatible" property are
typically converted to struct devices and then registered with driver
core to probe them. This also allows the gpio* devices to hook into all
the driver core capabilities like runtime PM, probe deferral,
suspend/resume ordering, device links, etc.
Case 2: The driver for "foo" doesn't populate struct devices for these
gpio* nodes before registering them with gpiolib. Instead it just loops
through its child nodes and directly registers the gpio* nodes with
gpiolib.
Drivers that follow case 2 cause problems with fw_devlink=on. This is
because fw_devlink will prevent bazz from probing until there's a struct
device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO
supplier). Once the struct device is available, fw_devlink will create a
device link with gpio0 device as the supplier and bazz device as the
consumer. After this point, since the gpio0 device will never bind to a
driver, the device link will prevent bazz device from ever probing.
Finding and refactoring all the instances of drivers that follow case 2
will cause a lot of code churn and it is not something that can be done
in one shot. In some instances it might not even be possible to refactor
them cleanly. Examples of such instances are [1] [2].
This patch works around this problem and avoids all the code churn by
simply setting the fwnode of the gpio_device and creating a stub driver
to bind to the gpio_device. This allows all the consumers to continue
probing when the driver follows case 2.
[1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
[2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/
Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-22 19:35:59 +00:00
|
|
|
static inline void of_gpio_dev_init(struct gpio_chip *gc,
|
|
|
|
|
struct gpio_device *gdev)
|
|
|
|
|
{
|
|
|
|
|
}
|
2019-07-17 07:10:01 +00:00
|
|
|
#endif /* CONFIG_OF_GPIO */
|
|
|
|
|
|
2020-02-20 13:01:49 +00:00
|
|
|
extern struct notifier_block gpio_of_notifier;
|
|
|
|
|
|
2019-07-17 07:10:01 +00:00
|
|
|
#endif /* GPIOLIB_OF_H */
|