Re: [PATCH v3 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device

[Mika Westerberg]

On Mon, Oct 11, 2021 at 09:11:05AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/11/21 8:19 AM, Mika Westerberg wrote:
> > Hi,
> > 
> > On Sun, Oct 10, 2021 at 08:56:57PM +0200, Hans de Goede wrote:
> >> +/* List of HIDs for which we honor deps of matching ACPI devs, when checking _DEP lists. */
> >> +static const char * const acpi_honor_dep_ids[] = {
> >> +	"INT3472", /* Camera sensor PMIC / clk and regulator info */
> > 
> > Is there some reason why we can't do this for all devices with _DEP?
> > That way we don't need to maintain lists like this.
> 
> Up until now the ACPI core deliberate mostly ignores _DEP-s because the
> _DEP method may point to pretty much any random ACPI object and Linux does
> not necessarily have a driver for all ACPI objects the driver points too,
> which would lead to the devices never getting instantiated.
> 
> In hindsight this might not have been the best solution (1), but if we
> now start honoring _DEP-s for all devices all of a sudden then this
> will almost certainly lead to a whole bunch of regressions.
> 
> Note that in this case the HID which triggers this is for the device
> being depended upon and for all camera sensors used with the IPU3 and
> IPU4 Intel camera blocks this is the INT3472 device. By triggering on
> this HID (rather then on the sensor HIDs) I expect that we will not
> need to update this list all that often.

I see and agree. Thanks for the explanation!

No objections from my side then :)