lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 10 Oct 2021 20:56:58 +0200 From: Hans de Goede <hdegoede@...hat.com> To: "Rafael J . Wysocki" <rjw@...ysocki.net>, Mark Gross <markgross@...nel.org>, Andy Shevchenko <andy@...radead.org>, Wolfram Sang <wsa@...-dreams.de>, Mika Westerberg <mika.westerberg@...ux.intel.com>, Daniel Scally <djrscally@...il.com>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org> Cc: Hans de Goede <hdegoede@...hat.com>, Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org, Sakari Ailus <sakari.ailus@...ux.intel.com>, Kate Hsuan <hpa@...hat.com>, linux-media@...r.kernel.org, linux-clk@...r.kernel.org Subject: [PATCH v3 02/11] i2c: acpi: Use acpi_dev_ready_for_enumeration() helper The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. To ensure the correct probe-ordering the ACPI core has code to defer the enumeration of consumers affected by this until the providers are ready. Call the new acpi_dev_ready_for_enumeration() helper to avoid enumerating / instantiating i2c-clients too early. Signed-off-by: Hans de Goede <hdegoede@...hat.com> --- drivers/i2c/i2c-core-acpi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c index aaeeacc12121..688cc71d650d 100644 --- a/drivers/i2c/i2c-core-acpi.c +++ b/drivers/i2c/i2c-core-acpi.c @@ -144,9 +144,12 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev, struct list_head resource_list; int ret; - if (acpi_bus_get_status(adev) || !adev->status.present) + if (acpi_bus_get_status(adev)) return -EINVAL; + if (!acpi_dev_ready_for_enumeration(adev)) + return -ENODEV; + if (acpi_match_device_ids(adev, i2c_acpi_ignored_device_ids) == 0) return -ENODEV; -- 2.31.1
Powered by blists - more mailing lists