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().
Reported-by: Matti Vaittinen <[email protected]>
Signed-off-by: Michael Walle <[email protected]>
---
Btw, I'm not sure how to handle this "was part of another patch by another
author" thing. Should I leave the Sob and just add mine? I certainly don't
want to take credit for work Matti had done. This patch isn't huge, but
still ;)
drivers/gpio/gpio-regmap.c | 7 +------
include/linux/gpio/regmap.h | 6 +++++-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index 134cedf151a7..583cd1cdead8 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -178,12 +178,6 @@ static int gpio_regmap_direction_output(struct gpio_chip *chip,
return gpio_regmap_set_direction(chip, offset, true);
}
-void gpio_regmap_set_drvdata(struct gpio_regmap *gpio, void *data)
-{
- gpio->driver_data = data;
-}
-EXPORT_SYMBOL_GPL(gpio_regmap_set_drvdata);
-
void *gpio_regmap_get_drvdata(struct gpio_regmap *gpio)
{
return gpio->driver_data;
@@ -226,6 +220,7 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config
return ERR_PTR(-ENOMEM);
gpio->parent = config->parent;
+ gpio->driver_data = config->drvdata;
gpio->regmap = config->regmap;
gpio->ngpio_per_reg = config->ngpio_per_reg;
gpio->reg_stride = config->reg_stride;
diff --git a/include/linux/gpio/regmap.h b/include/linux/gpio/regmap.h
index 334dd928042b..a9f7b7faf57b 100644
--- a/include/linux/gpio/regmap.h
+++ b/include/linux/gpio/regmap.h
@@ -37,6 +37,9 @@ struct regmap;
* offset to a register/bitmask pair. If not
* given the default gpio_regmap_simple_xlate()
* is used.
+ * @drvdata: (Optional) Pointer to driver specific data which is
+ * not used by gpio-remap but is provided "as is" to the
+ * driver callback(s).
*
* The ->reg_mask_xlate translates a given base address and GPIO offset to
* register and mask pair. The base address is one of the given register
@@ -78,13 +81,14 @@ struct gpio_regmap_config {
int (*reg_mask_xlate)(struct gpio_regmap *gpio, unsigned int base,
unsigned int offset, unsigned int *reg,
unsigned int *mask);
+
+ void *drvdata;
};
struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config);
void gpio_regmap_unregister(struct gpio_regmap *gpio);
struct gpio_regmap *devm_gpio_regmap_register(struct device *dev,
const struct gpio_regmap_config *config);
-void gpio_regmap_set_drvdata(struct gpio_regmap *gpio, void *data);
void *gpio_regmap_get_drvdata(struct gpio_regmap *gpio);
#endif /* _LINUX_GPIO_REGMAP_H */
--
2.20.1
On Fri, Jun 4, 2021 at 1:04 PM Michael Walle <[email protected]> wrote:
> 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().
>
> Reported-by: Matti Vaittinen <[email protected]>
> Signed-off-by: Michael Walle <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
> Btw, I'm not sure how to handle this "was part of another patch by another
> author" thing. Should I leave the Sob and just add mine?
Ideally just stack Sign-offs it is called the "delivery path".
Yours,
Linus Walleij
Am 2021-06-05 00:00, schrieb Linus Walleij:
>> Btw, I'm not sure how to handle this "was part of another patch by
>> another
>> author" thing. Should I leave the Sob and just add mine?
>
> Ideally just stack Sign-offs it is called the "delivery path".
Even if it is just a subset of the original patch?
-michael
On Sat, Jun 5, 2021 at 12:03 AM Michael Walle <[email protected]> wrote:
> Am 2021-06-05 00:00, schrieb Linus Walleij:
>
> >> Btw, I'm not sure how to handle this "was part of another patch by
> >> another
> >> author" thing. Should I leave the Sob and just add mine?
> >
> > Ideally just stack Sign-offs it is called the "delivery path".
>
> Even if it is just a subset of the original patch?
Yeah it's just an indication of whose hands typed thes characters.
Something with copyright law actually, nothing to do with actual
attribution. See (11) here:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
Author: should reflect the person who wrote the majority of the
code however.
Yours,
Linus Walleij