Re: [PATCH v1 2/2] gpio: merrifield: Convert to use acpi_dev_get_first_match()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 13-07-18 14:45, Andy Shevchenko wrote:
On Thu, 2018-07-12 at 21:18 +0200, Hans de Goede wrote:
Hi,

On 12-07-18 19:23, Andy Shevchenko wrote:
acpi_dev_get_first_match_name() is deprecated because it leaks
a reference count.

Convert the driver to use acpi_dev_get_first_match() instead.

-static const char *mrfld_gpio_get_pinctrl_dev_name(void)
+static const char *mrfld_gpio_get_pinctrl_dev_name(struct
mrfld_gpio *priv)
   {
-	const char *dev_name =
acpi_dev_get_first_match_name("INTC1002", NULL, -1);
-	return dev_name ? dev_name : "pinctrl-merrifield";
+	struct acpi_device *adev;
+	const char *dev_name;
+
+	adev = acpi_dev_get_first_match("INTC1002", NULL, -1);
+	if (!adev)
+		return "pinctrl-merrifield";
+
+	dev_name = devm_kstrdup(priv->dev, acpi_dev_name(adev),
GFP_KERNEL);
+	put_device(&adev->dev);
+	return dev_name;
   }

Hmm, this looks complicated(ish)

Yes, I agree. Though as I told this is dictated by nature of
bus_find_device(). Moreover, we can't cover all, especially single time
used, cases by introducing yet another acpi_dev_get_first_match_*() type
of API.

  maybe add a new
devm_acpi_dev_get_first_match_name() which takes a dev for the
devm_kstrdup and do all this inside there.

Yes, that would make sense because of existing users. But in many cases
this memory would be used just for one time.

True.

Basically for users you
mentioned below we don't need to do any allocations till we have a
reference to struct device.

Another possibility is to provide a buffer to the function. (I tried to
mock up and had been unsatisfied with the result, though)

Right, I considered suggesting the same thing (pass in a buffer)
but that did not feel right to me either.

  There are
quite a few users of acpi_dev_get_first_match_name() under
sound/soc/intel/boards and converting them all like this will
be cumbersome.

Yes, and I don't like to blow them up. But I don't see any better
solution for now.

  IMHO we need a better API then the acpi_dev_get_first_match()
you are proposing.

I'm all hears.

Take into account the flexibility of new API as well. (Locally I used to
have prototyping something which actually requires handle to be
returned)

Ok, so all things considered I think we should just stay with
acpi_dev_get_first_match() as you suggested and just live with
the call sites getting some extra lines of code.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux