Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Hardik Prakash <hardikprakash.official@gmail.com>
Cc: linux-i2c@vger.kernel.org, linux-gpio@vger.kernel.org,
	wsa@kernel.org, mario.limonciello@amd.com, brgl@bgdev.pl,
	basavaraj.natikar@amd.com, linusw@kernel.org, nathan@kernel.org,
	chaitanya.kumar.borah@intel.com
Subject: Re: [PATCH v9 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
Date: Thu, 18 Jun 2026 09:55:19 +0300	[thread overview]
Message-ID: <ajOWV3apVXOAHcYT@ashevche-desk.local> (raw)
In-Reply-To: <CANTFpSUSKwTj-z0E2w3C_8ue8wANE+dHtDKboZ1+rqwN98C3cA@mail.gmail.com>

On Thu, Jun 18, 2026 at 12:52:46AM +0530, Hardik Prakash wrote:
> On Wed, Jun 17, 2026 at 14:57, Andy Shevchenko wrote:

> > > +     if (!agpio->resource_source.string_length ||
> > > +         !agpio->resource_source.string_ptr)
> > > +             return 1;
> >
> > I'm wondering if we simply can move to strncmp() instead of this check
> >
> > > +     list_for_each_entry(ref, gpio_controllers, node) {
> > > +             if (!strcmp(ref->path, agpio->resource_source.string_ptr))
> >
> >                 if (!strncmp(ref->path, agpio->resource_source.string_ptr))
> 
> Could you clarify? strncmp() with n=string_length would protect the
> dedup check against a NULL or unterminated string_ptr, but we still
> need string_ptr to be non-NULL before passing it to kstrdup(). Should
> we keep a NULL/zero-length guard before kstrdup() and only replace the
> strcmp() in the dedup loop with strncmp()?

Ah, okay, you are talking about the first iteration when the list is empty and
we have to add it to the list.

So the question is, do we expect the resource_source not to be set at this point?
In other words is there any valid AML that interpreter decodes to the empty
resource_source? If so, can we ever have the following condition to be true?

	string_length != 0 && string_ptr == NULL

P.S. Do not top-post! Reply under the piece in question. Also remove
the context you are not replying to.

> On Wed, 17 Jun 2026 at 14:57, Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Wed, Jun 17, 2026 at 12:29:22PM +0530, Hardik Prakash wrote:

...

> > > +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
> > > +{
> > > +     struct list_head *gpio_controllers = data;
> > > +     struct acpi_resource_gpio *agpio;
> > > +     struct gpio_controller_ref *ref;
> > > +
> > > +     if (!acpi_gpio_get_irq_resource(ares, &agpio))
> > > +             return 1;
> >
> > > +     if (!agpio->resource_source.string_length ||
> > > +         !agpio->resource_source.string_ptr)
> > > +             return 1;
> >
> > I'm wondering if we simply can move to strncmp() instead of this check
> >
> > > +     /* Skip if we've already tracked this GPIO controller */
> > > +     list_for_each_entry(ref, gpio_controllers, node) {
> > > +             if (!strcmp(ref->path, agpio->resource_source.string_ptr))
> >
> >                 if (!strncmp(ref->path, agpio->resource_source.string_ptr))
> >
> >
> > > +                     return 1;
> > > +     }
> > > +
> > > +     ref = kzalloc(sizeof(*ref), GFP_KERNEL);
> > > +     if (!ref)
> > > +             return -ENOMEM;
> > > +
> > > +     ref->path = kstrdup(agpio->resource_source.string_ptr, GFP_KERNEL);
> > > +     if (!ref->path) {
> > > +             kfree(ref);
> > > +             return -ENOMEM;
> > > +     }
> > > +
> > > +     list_add_tail(&ref->node, gpio_controllers);
> > > +     return 1;
> > > +}

You haven't replied to the rest, I assume you agree with all the suggestions?

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-06-18  6:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17  6:59 [PATCH v9 0/2] i2c: designware: fix WACF2200 touchscreen probe ordering Hardik Prakash
2026-06-17  6:59 ` [PATCH v9 1/2] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound" Hardik Prakash
2026-06-17  6:59 ` [PATCH v9 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound Hardik Prakash
2026-06-17  9:27   ` Andy Shevchenko
2026-06-17 19:22     ` Hardik Prakash
2026-06-18  6:55       ` Andy Shevchenko [this message]
2026-06-18 10:39         ` Hardik Prakash
2026-06-17  8:03 ` [PATCH v9 0/2] i2c: designware: fix WACF2200 touchscreen probe ordering Andy Shevchenko
2026-06-17  8:04   ` 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=ajOWV3apVXOAHcYT@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=basavaraj.natikar@amd.com \
    --cc=brgl@bgdev.pl \
    --cc=chaitanya.kumar.borah@intel.com \
    --cc=hardikprakash.official@gmail.com \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=nathan@kernel.org \
    --cc=wsa@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox