Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2639847pxb; Fri, 8 Oct 2021 11:50:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3lI09LZe5TUfbkGlEKdNqR3gr8rA7vrARMh8YISCKdeS+P0+d/2fkJ0PvCPcQ0jwklZ1u X-Received: by 2002:a17:906:ed1:: with SMTP id u17mr6302614eji.304.1633719019368; Fri, 08 Oct 2021 11:50:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633719019; cv=none; d=google.com; s=arc-20160816; b=Bs1GnnvQyaTVwCwJVrX5Ifpv3tTimgq1c93wDfccaKuJ2FUQVVoOYBmF5+MM40FBMq XZI13gwEHXOqs+y0dYp33IBLRRJHHoszd6FR3vQjWk8YCPjQHD5Zb+8GMrGKJlGc0hRC ZNuWiBKdsYLXmWuPPTgKXXPYN/gxO5tjAUbXPuwnwbezNvYUjMq1urnfYvNql3XWcDKm AV8asGal6ZiIni3fkM/nUUIhsB8uZrAOvQpY9zPpsNd851r9sjMK4LDZS9Sx9UXszFtc /w3DppES1mp28ZTKFVgt5Ikzclne0Yjv5um0cel5Qa7hPhiaM6ZBjreIc/RvNNFs4twK HXng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ijctcI5vpJQPwzhUQFvS7p/QdhBr3LnKeHeoMXTfhIA=; b=MEfEonaPofTG95K/Y6xNNXNgIz/WCRST8ktOVubncy9hYr6fJag2lXGgzh5VhTWq0y Dcs1f2qSDW40jztD8dKguEQUOFv5VMa9aQLiAWbii0/fsSBmSMj/f0Svq5+oVW1oGhxG NKagXTZwDxHmPlCVe/naz8+MT6i8IW6dH7Zmje9+IqU6rnUbrQmCEXqM+uwABZ5YNkKZ 6XN8AASlMAcqLBLGEDp0TkVenCWgTKh5x4P2okGadBkQjXdqgM/pk4EnOdekzIszr+fP sDJsussa8rVLf7nuixPfczlHW+dwNZ6bp8b/tVI95UZ/00uZvyRaTNMezDu3+U+r5Ett XCVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TAELWoPz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hq3si262237ejc.142.2021.10.08.11.49.55; Fri, 08 Oct 2021 11:50:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TAELWoPz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231308AbhJHSuV (ORCPT + 99 others); Fri, 8 Oct 2021 14:50:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:28921 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231316AbhJHSuT (ORCPT ); Fri, 8 Oct 2021 14:50:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633718903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ijctcI5vpJQPwzhUQFvS7p/QdhBr3LnKeHeoMXTfhIA=; b=TAELWoPzf9EaqN8Amfvyr0x+egpg/RFJ0i+bh0Ejvxf0o9rKsjrDPh0Fna/2MrywppbVY4 S8VWyjnpsr3SVEFWvgj1bK4cHYuSzAihMT/tKmAUo1dOczg8i3kCISXVQ4llrVWChBgb/Q 6vEr1k7SXoMG6i80afU5uEC9PCmX0Jk= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-406-juYU8v-LNzGuq5HmJbZVKQ-1; Fri, 08 Oct 2021 14:48:21 -0400 X-MC-Unique: juYU8v-LNzGuq5HmJbZVKQ-1 Received: by mail-ed1-f69.google.com with SMTP id z6-20020a50cd06000000b003d2c2e38f1fso10087128edi.1 for ; Fri, 08 Oct 2021 11:48:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ijctcI5vpJQPwzhUQFvS7p/QdhBr3LnKeHeoMXTfhIA=; b=UIA8SehDFc5kBpHykMNYhtgqCe8BOJ+1pI4dJM/aCC3YMpILr0W47nxq2cqlf4zIa/ yUBk9epX1+u9va3UIWMXS3ywQPl6h8pqBkCkG/M6dk5XbVfjY7SNxq7r+BGRZmGi1IA5 7gzb8uSktylp5keHMDfVDzuTzg+OaFDTehhOn9wFfyse1zfwUk6JJyRdQO+CTjBVMRlJ hVj8Ivq6WInMdt6P+pCZdc6lidARpZNR1fHyvw5ODdItuFMtOzCUqfTCcZrJgf+Yrliy KxUdHP5NbYfmDpwoiSViBKAY6gXY+sY9Hk7G+TWSRCSTyF/Gdvi6jcHF0eaOzE8iIc/X uDpA== X-Gm-Message-State: AOAM530NqNRZUXyGm7SUI60qt/MjYJ2YWmWshAv0X7jqF3BaibOAUKQe wVFgc50RRMHHzj2LptRtvG34RzBrW2RT6RsUBtvtzAptq05prt6aOjMjn9qT4izLKIR26T9zLna Hv0m48PV5OUeiNOygC2bzw/oc X-Received: by 2002:a05:6402:438d:: with SMTP id o13mr15370843edc.0.1633718900404; Fri, 08 Oct 2021 11:48:20 -0700 (PDT) X-Received: by 2002:a05:6402:438d:: with SMTP id o13mr15370805edc.0.1633718900231; Fri, 08 Oct 2021 11:48:20 -0700 (PDT) Received: from x1.localdomain ([2a0e:5700:4:11:334c:7e36:8d57:40cb]) by smtp.gmail.com with ESMTPSA id o12sm56200edw.84.2021.10.08.11.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 11:48:19 -0700 (PDT) Subject: Re: [PATCH 02/12] media: i2c: ov8865: Add an has_unmet_acpi_deps() check To: Laurent Pinchart Cc: "Rafael J . Wysocki" , Mark Gross , Andy Shevchenko , Daniel Scally , Mauro Carvalho Chehab , Liam Girdwood , Mark Brown , Michael Turquette , Stephen Boyd , Len Brown , linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Sakari Ailus , Kate Hsuan , linux-media@vger.kernel.org, linux-clk@vger.kernel.org References: <20211008162121.6628-1-hdegoede@redhat.com> <20211008162121.6628-3-hdegoede@redhat.com> From: Hans de Goede Message-ID: <39a85265-017e-f86d-619b-c1aa6a771a26@redhat.com> Date: Fri, 8 Oct 2021 20:48:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, On 10/8/21 8:41 PM, Laurent Pinchart wrote: > Hi Hans, > > Thank you for the patch. > > On Fri, Oct 08, 2021 at 06:21:11PM +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 of the ov8865 driver vs the >> drivers for 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 regs. >> >> On ACPI/x86 where this is a problem, the ov8865 ACPI fw-nodes have a _DEP >> dependency on the INT3472 ACPI fw-node which describes the hardware which >> provides the clks/regulators. >> >> The drivers/platform/x86/intel/int3472/ code dealing with these ACPI >> fw-nodes will call acpi_dev_clear_dependencies() to indicate that this >> _DEP has been "met" when all the clks/regulators have been setup. >> >> Call the has_unmet_acpi_deps() helper to check for unmet _DEPs >> and return -EPROBE_DEFER if this returns true, so that we wait for >> the clk/regulator setup to be done before continuing with probing. >> >> Signed-off-by: Hans de Goede >> --- >> drivers/media/i2c/ov8865.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c >> index ce4e0ae2c4d3..fd18d1256f78 100644 >> --- a/drivers/media/i2c/ov8865.c >> +++ b/drivers/media/i2c/ov8865.c >> @@ -2978,6 +2978,9 @@ static int ov8865_probe(struct i2c_client *client) >> unsigned int i; >> int ret; >> >> + if (has_unmet_acpi_deps(dev)) >> + return -EPROBE_DEFER; >> + > > We've worked hard to avoid adding ACPI-specific code such as this in > sensor drivers, as it would then spread like crazy, and also open the > door to more ACPI-specific support. I don't want to open this pandora's > box, I'd like to see this handled in another layer (the I2C core could > be a condidate for instance, but bonus points if it can be handled in > the ACPI subsystem itself). The problem is that we do NOT want this check for all i2c devices, so doing it in any place other then the drivers means having some list of APCI-ids to which to apply this someplace else. And then for every sensor driver which needs this we need to update this list. This is wht I've chosen to just put this check directly in the sensor drivers. It is only 2 lines, it is a no-op on kernels where ACPI is not enabled (without need a #ifdef) and it is a no-op if the sensor i2c-client is not instantiated through APCI even when ACPI support is enabled in the kernel. I understand that you don't want a lot of ACPI specific code inside the drivers, which is why I've come up with this fix which consists of only 2 lines. My previous attempts (which I never posted) where much worse then this. Regards, Hans > >> sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); >> if (!sensor) >> return -ENOMEM; >