| Message ID | 20211010185707.195883-3-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data | expand |
On Sun, Oct 10, 2021 at 08:56:58PM +0200, Hans de Goede wrote: > 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@redhat.com> If the ACPI and I2C-ACPI maintainers are happy, I am fine with this, too: Acked-by: Wolfram Sang <wsa@kernel.org>
On Sun, Oct 10, 2021 at 8:57 PM Hans de Goede <hdegoede@redhat.com> wrote: > > 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@redhat.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; I kind of prefer combining checks that cause the same error code to be returned, but this is fine with me too.
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;
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@redhat.com> --- drivers/i2c/i2c-core-acpi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)