Unverified Commit 815b95be authored Sep 10, 2024 by openeuler-ci-bot Committed by Gitee Sep 10, 2024

!11469 OLK-6.6 Revert gpiolib bugfix

Merge Pull Request from: @lujunhuaHW 
 
Previous patch modified the standard used by acpi_gpiochip_find()
to match device nodes. Using the device node set in gc->gpiodev->d-
ev instead of gc->parent.

However, there is a situation in gpio-dwapb where the GPIO device
driver will set gc->fwnode for each port corresponding to a child
node under a GPIO device, so gc->gpiodev->dev will be assigned the
value of each child node in gpiochip_add_data().

gpio-dwapb.c:
128,31 static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
                               struct dwapb_port_property *pp,
                               unsigned int offs);
port->gc.fwnode = pp->fwnode;

693,39 static int dwapb_gpio_probe;
err = dwapb_gpio_add_port(gpio, &pdata->properties[i], i);

When other drivers request GPIO pin resources through the GPIO device
node provided by ACPI (corresponding to the parent node), the change
of the matching object to gc->gpiodev->dev in acpi_gpiochip_find()
only allows finding the value of each port (child node), resulting
in a failed request.

Reapply the condition of using gc->parent for match in acpi_gpio-
chip_find() in the code can compatible with the problem of gpio-dwapb,
and will not affect the two cases mentioned in the patch:
1. There is no setting for gc->fwnode.
2. The case that depends on using gc->fwnode for match.

ISSUE:https://gitee.com/openeuler/kernel/issues/IAQ1MS
 
 
Link:https://gitee.com/openeuler/kernel/pulls/11469

 

Signed-off-by: Zhang Peng <zhangpeng362@huawei.com>

parents db19e032 f8b15ad4

drivers/gpio/gpiolib-acpi.c

+17 −2

Original line number	Diff line number	Diff line
		@@ -128,8 +128,23 @@ static bool acpi_gpio_deferred_req_irqs_done;

		static int acpi_gpiochip_find(struct gpio_chip gc, void data)
		{
		return device_match_acpi_handle(&gc->gpiodev->dev, data) \|\|
		(gc->parent && device_match_acpi_handle(gc->parent, data));
		/* First check the actual GPIO device */
		if (device_match_acpi_handle(&gc->gpiodev->dev, data))
		return true;

		/*
		* When the ACPI device is artificially split to the banks of GPIOs,
		* where each of them is represented by a separate GPIO device,
		* the firmware node of the physical device may not be shared among
		* the banks as they may require different values for the same property,
		* e.g., number of GPIOs in a certain bank. In such case the ACPI handle
		* of a GPIO device is NULL and can not be used. Hence we have to check
		* the parent device to be sure that there is no match before bailing
		* out.
		*/
		if (gc->parent)
		return device_match_acpi_handle(gc->parent, data);
		return false;
		}

		/**