All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org,  linux-kernel@vger.kernel.org,
	 Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 01/10] gpiolib: provide gpiochip_dup_line_label()
Date: Wed, 29 Nov 2023 16:45:11 +0100	[thread overview]
Message-ID: <CAMRc=Mc6ce_gThRfZ78DzHGWdTAO-abY=Ythbd4KRHQ=Yfd_mw@mail.gmail.com> (raw)
In-Reply-To: <ZWdRUosYLAzXQrTT@smile.fi.intel.com>

On Wed, Nov 29, 2023 at 3:57 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Nov 29, 2023 at 03:24:02PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > gpiochip_is_requested() not only has a misleading name but it returns
> > a pointer to a string that is freed when the descriptor is released.
> >
> > Provide a new helper meant to replace it, which returns a copy of the
> > label string instead.
>
> ...
>
> > +/**
> > + * gpiochip_dup_line_label - Get a copy of the consumer label.
> > + * @gc: GPIO chip controlling this line.
> > + * @offset: Hardware offset of the line.
> > + *
> > + * Returns:
> > + * Pointer to a copy of the consumer label if the line is requested or NULL
> > + * if it's not. If a valid pointer was returned, it must be freed using
> > + * kfree(). In case of a memory allocation error, the function returns %ENOMEM.
>
> kfree_const() ? (see below)
>
> > + * Must not be called from atomic context.
> > + */
> > +char *gpiochip_dup_line_label(struct gpio_chip *gc, unsigned int offset)
> > +{
> > +     const char *label;
> > +     char *cpy;
>
> Why not "copy"?
>
> > +
> > +     label = gpiochip_is_requested(gc, offset);
> > +     if (!label)
> > +             return NULL;
>
> > +     cpy = kstrdup(label, GFP_KERNEL);
>
> You probably want to have kstrdup_const(). However, I haven't checked
> if we have such use cases.

I thought about it but I'm thinking that it would be confusing to
users and lead to bugs. This is not used very much and only for
debugfs output. Let's keep it simple.

>
> > +     if (!cpy)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     return cpy;
> > +}
>
> So, how does this differ from the previous one? You need to hold a reference
> to the descriptor before copying and release it after.
>

The last patch reworks it to hold the obsolete gpio_lock and the
upcoming changes will make this perform the copy under the descriptor
lock and return it once it's released.

Bart

> --
> With Best Regards,
> Andy Shevchenko
>
>

  reply	other threads:[~2023-11-29 15:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 14:24 [PATCH 00/10] gpio/pinctrl: replace gpiochip_is_requested() with a safer interface Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 01/10] gpiolib: provide gpiochip_dup_line_label() Bartosz Golaszewski
2023-11-29 14:57   ` Andy Shevchenko
2023-11-29 15:45     ` Bartosz Golaszewski [this message]
2023-11-29 14:24 ` [PATCH 02/10] gpio: wm831x: use gpiochip_dup_line_label() Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 03/10] gpio: wm8994: " Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 04/10] gpio: stmpe: " Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 05/10] pinctrl: abx500: " Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 06/10] pinctrl: nomadik: " Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 07/10] pinctrl: baytrail: " Bartosz Golaszewski
2023-11-29 14:51   ` Andy Shevchenko
2023-11-29 14:24 ` [PATCH 08/10] pinctrl: sppctl: " Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 09/10] gpiolib: use gpiochip_dup_line_label() in for_each helpers Bartosz Golaszewski
2023-11-29 14:43   ` Bartosz Golaszewski
2023-11-29 14:52     ` Andy Shevchenko
2023-11-29 20:55       ` Bartosz Golaszewski
2023-11-29 14:24 ` [PATCH 10/10] gpiolib: remove gpiochip_is_requested() Bartosz Golaszewski

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='CAMRc=Mc6ce_gThRfZ78DzHGWdTAO-abY=Ythbd4KRHQ=Yfd_mw@mail.gmail.com' \
    --to=brgl@bgdev.pl \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.