From: Marijn Suijten <marijn.suijten@somainline.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Brian Masney <bmasney@redhat.com>
Subject: Re: [PATCH v1 1/1] gpiolib: Unify access to the device properties
Date: Sun, 20 Nov 2022 20:16:22 +0100 [thread overview]
Message-ID: <20221120191622.kngdz462bmns7fwe@SoMainline.org> (raw)
In-Reply-To: <20221116141728.72491-1-andriy.shevchenko@linux.intel.com>
On 2022-11-16 16:17:28, Andy Shevchenko wrote:
> Some of the functions are using struct fwnode_handle, some struct device
> pointer. In the GPIO library the firmware node of the GPIO device is the
> same as GPIO node of the GPIO chip. Due to this fact we may use former
> to access properties everywhere in the code.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I presume this is a more complete version of [1], as this also happens
to address the crash on MSM [1], hence:
Tested-by: Marijn Suijten <marijn.suijten@somainline.org>
Just in case, this seems to depend on [3] or it fails to apply cleanly
because of the `const` change on `fwnode` (consider this irrelevant if
it has already been applied, I'm still on -next-20221115 for this
integration branch).
[1]: https://lore.kernel.org/all/Y3S62i7OzocP5QrT@orome/
[2]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/
[3]: https://lore.kernel.org/linux-gpio/20221031-gpiolib-swnode-v3-0-0282162b0fa4@gmail.com/
- Marijn
> ---
> drivers/gpio/gpiolib.c | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 51afdc6ac919..c163b354e727 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -367,12 +367,12 @@ static int gpiochip_set_desc_names(struct gpio_chip *gc)
> static int devprop_gpiochip_set_names(struct gpio_chip *chip)
> {
> struct gpio_device *gdev = chip->gpiodev;
> - const struct fwnode_handle *fwnode = dev_fwnode(&gdev->dev);
> + struct device *dev = &gdev->dev;
> const char **names;
> int ret, i;
> int count;
>
> - count = fwnode_property_string_array_count(fwnode, "gpio-line-names");
> + count = device_property_string_array_count(dev, "gpio-line-names");
> if (count < 0)
> return 0;
>
> @@ -385,7 +385,7 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
> * gpiochips.
> */
> if (count <= chip->offset) {
> - dev_warn(&gdev->dev, "gpio-line-names too short (length %d), cannot map names for the gpiochip at offset %u\n",
> + dev_warn(dev, "gpio-line-names too short (length %d), cannot map names for the gpiochip at offset %u\n",
> count, chip->offset);
> return 0;
> }
> @@ -394,10 +394,9 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
> if (!names)
> return -ENOMEM;
>
> - ret = fwnode_property_read_string_array(fwnode, "gpio-line-names",
> - names, count);
> + ret = device_property_read_string_array(dev, "gpio-line-names", names, count);
> if (ret < 0) {
> - dev_warn(&gdev->dev, "failed to read GPIO line names\n");
> + dev_warn(dev, "failed to read GPIO line names\n");
> kfree(names);
> return ret;
> }
> @@ -448,10 +447,11 @@ static unsigned long *gpiochip_allocate_mask(struct gpio_chip *gc)
>
> static unsigned int gpiochip_count_reserved_ranges(struct gpio_chip *gc)
> {
> + struct device *dev = &gc->gpiodev->dev;
> int size;
>
> /* Format is "start, count, ..." */
> - size = fwnode_property_count_u32(gc->fwnode, "gpio-reserved-ranges");
> + size = device_property_count_u32(dev, "gpio-reserved-ranges");
> if (size > 0 && size % 2 == 0)
> return size;
>
> @@ -472,6 +472,7 @@ static int gpiochip_alloc_valid_mask(struct gpio_chip *gc)
>
> static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
> {
> + struct device *dev = &gc->gpiodev->dev;
> unsigned int size;
> u32 *ranges;
> int ret;
> @@ -484,7 +485,7 @@ static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
> if (!ranges)
> return -ENOMEM;
>
> - ret = fwnode_property_read_u32_array(gc->fwnode, "gpio-reserved-ranges", ranges, size);
> + ret = device_property_read_u32_array(dev, "gpio-reserved-ranges", ranges, size);
> if (ret) {
> kfree(ranges);
> return ret;
>
> base-commit: 40059212f99c31f26c69763e560325e59eac02c6
> --
> 2.35.1
>
next prev parent reply other threads:[~2022-11-20 19:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 14:17 Andy Shevchenko
2022-11-16 14:41 ` Andy Shevchenko
2022-11-17 15:54 ` Brian Masney
2022-11-20 19:16 ` Marijn Suijten [this message]
2022-11-21 8:27 ` Andy Shevchenko
2022-11-25 18:30 ` Andy Shevchenko
2022-11-28 18:01 ` Bartosz Golaszewski
2022-11-28 18:11 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221120191622.kngdz462bmns7fwe@SoMainline.org \
--to=marijn.suijten@somainline.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bmasney@redhat.com \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®