Received-SPF: pass (google.com: domain of linux-kernel+bounces-212072-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240528084413.2624435-1-sakari.ailus@linux.intel.com>
 <a05df025-a0be-49cd-84a9-7d7fb2eeb33e@redhat.com> <e9062095-b312-44df-a9e3-0b09f3ec9eff@redhat.com>
 <4b387b4d-f778-4891-9f07-df5fc0a093cd@redhat.com> <ZmmQLt7wB-yGQBTw@kekkonen.localdomain>
 <CAJZ5v0ii3WFQRPdfHeeW4M9kXSWDVxxxy02zThcf25mjNwqDAw@mail.gmail.com>
 <ZmmT56Cyvb2FCyav@kekkonen.localdomain> <CAJZ5v0hOBggQR_=uA3VuhruQnZihVxHHovpTz4=qfcbiSunsYw@mail.gmail.com>
 <ZmmY3he9vfWVWU3I@kekkonen.localdomain> <CAJZ5v0j7HTfg1wY+B+7vhE6tBKPVHMuu_MsFHjaLK70VS_cNEw@mail.gmail.com>
 <ZmnnFueL-Cgw5Eqp@kekkonen.localdomain>
In-Reply-To: <ZmnnFueL-Cgw5Eqp@kekkonen.localdomain>
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: Wed, 12 Jun 2024 20:29:21 +0200
Message-ID: <CAJZ5v0gtK9yusimCOVV2dGkQWDwQ6=r=vfbgC-eE60Cg-5wk_Q@mail.gmail.com>
Subject: Re: [PATCH 1/1] ACPI: scan: Ignore Dell XPS 9320 camera graph port nodes
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Hans de Goede <hdegoede@redhat.com>, 
	Genes Lists <lists@sapience.com>, linux-kernel@vger.kernel.org, mchehab@kernel.org, 
	hverkuil-cisco@xs4all.nl, laurent.pinchart@ideasonboard.com, 
	wentong.wu@intel.com, linux-media@vger.kernel.org, linux-acpi@vger.kernel.org, 
	"regressions@lists.linux.dev" <regressions@lists.linux.dev>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Sakari,

On Wed, Jun 12, 2024 at 8:21=E2=80=AFPM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Rafael,
>
> On Wed, Jun 12, 2024 at 03:06:53PM +0200, Rafael J. Wysocki wrote:
> > Hi Sakari,
> >
> > On Wed, Jun 12, 2024 at 2:47=E2=80=AFPM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Rafael,
> > >
> > > On Wed, Jun 12, 2024 at 02:32:26PM +0200, Rafael J. Wysocki wrote:
> > > > > > > > I just hit the same problem on another Dell laptop. It seem=
s that
> > > > > > > > all Dell laptops with IPU6 camera from the Tiger Lake, Alde=
r Lake
> > > > > > > > and Raptor Lake generations suffer from this problem.
> > > > > > > >
> > > > > > > > So instead of playing whack a mole with DMI matches we shou=
ld
> > > > > > > > simply disable ACPI MIPI DISCO support on all Dell laptops
> > > > > > > > with those CPUs. I'm preparing a fix for this to replace
> > > > > > > > the DMI matching now.
> > > > > > >
> > > > > > > DisCo for Imaging support shouldn't be dropped on these syste=
ms, and this
> > > > > > > isn't what your patch does either. Instead the ACPI graph por=
t nodes (as
> > > > > > > per Linux specific definitions) are simply dropped, i.e. this=
 isn't related
> > > > > > > to DisCo for Imaging at all.
> > > > > >
> > > > > > So it looks like the changelog of that patch could be improved,=
 right?
> > > > >
> > > > > Well, yes. The reason the function is in the file is that nearly =
all camera
> > > > > related parsing is located there, not that it would be related to=
 DisCo for
> > > > > Imaging as such.
> > > >
> > > > So IIUC the camera graph port nodes are created by default with the
> > > > help of the firmware-supplied information, but if that is defective=
 a
> > > > quirk can be added to skip the creation of those ports in which cas=
e
> > > > they will be created elsewhere.
> > > >
> > > > Is this correct?
> > >
> > > Yes.
> >
> > So it would be good to add a comment to this effect to
> > acpi_nondev_subnode_extract() where acpi_graph_ignore_port() is
> > called.
> >
> > And there is a somewhat tangential question that occurred to me: If
> > the nodes are created elsewhere when acpi_graph_ignore_port() is true,
> > why is it necessary to consult the platform firmware for the
> > information on them at all?  Wouldn't it be better to simply always
> > create them elsewhere?
>
> Simple answer: for the same reason why in general system specific
> information comes from ACPI and not from platform data compiled into the
> kernel.
>
> Of course this is technically possible but it does not scale.

While I agree in general, in this particular case the platform data
compiled into the kernel needs to be present anyway, at least
apparently, in case the data coming from the platform firmware is
invalid.

So we need to do 3 things: compile in the platform data into the
kernel and expect the platform firmware to provide the necessary
information, and add quirks for the systems where it is known invalid.

Isn't this a bit too much?

> On laptops shipped with Windows some additional information is also avail=
able
> from ACPI via custom objects but a lot of information is just hard coded =
into
> the IPU bridge as well as the INT3472 driver.

Well, that's how it goes.