From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1B053101DD for ; Wed, 7 Jan 2026 12:18:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767788302; cv=none; b=s5KKGFiz7XBW7wLmLbXHP3h1R6YObIIFCgPywn9lQDpOx8Qtm6D0nKJpPsAhlt3GIOoya0wHHcnrp6VGBik+/UcLQs5bEH0gRpmH+4AjUCFuqJBs5v75Y4iwigPf2b9kDP33lCmEDT3HxaRH0PU88CI2fRf9NB2FFZqTu0ymrs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767788302; c=relaxed/simple; bh=3ydAp9jc7dmpW2SknC20PAvReUMoRGp82U5G48UebqU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=S/NholMR1C3WDxo/CQYCxPR9ly7GYIsxpb6rdOm6PVtlZgqz+A4uYXUCydyQAdHzjK5cVG2Mb5tMc6IwKFKHGtN6rkqYZoAE0XAdipEWZ6RHI4kD3YRhquxzGpC5ZZUcLDiD2ob4Bk9qMDSJ0WI9fxkh5x4s3CVmiacVjYz1Nqs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=XXQItyR+; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="XXQItyR+" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=4h8Jx2ZI8h/J6LJOiYzY01rdWQD1J3ZD0e23g8rEcw4=; b=XXQItyR+AdD0pBYgPF6Xvj4Ow7 qVZOgNkle+9jo8i8Vrmxs2aPlmBET7SSe7eF1OyAsbpZmXDYFdQOw7+UjPjy+MB1FNcK8+KGyBHAj lyX3GYOFpi8vsm0+nW2cbIU9XLyqg2hx0VCDgDEQYWAu9Dv+EBeR0V6WPutjl2ZH7UoZRzc4J4qRS bVwkenez8q1yPufdg/gj+AjqpfyClU8FBqwMzgyKNtOVEL5w33UgeeOFivWUjkgcAY6DmTfVXuq/x VDxNcY3GmGT0IYvNagOZ7j7OAViKwnspI7C59ef5+zG0p5e+w+lcjJ9Z4w+lVs7F5ynNIpWXDz7Z2 /hkApNAg==; Received: from i53875b57.versanet.de ([83.135.91.87] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vdSUC-001NDi-JT; Wed, 07 Jan 2026 13:18:01 +0100 From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , Andy Yan , Chaoyi Chen Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Chaoyi Chen Subject: Re: [PATCH] drm/mipi-dsi: Only remove child devices that match the dsi device type Date: Wed, 07 Jan 2026 13:18:00 +0100 Message-ID: <2718437.9Mp67QZiUf@diego> In-Reply-To: <20251203115028.133-1-kernel@airkyi.com> References: <20251203115028.133-1-kernel@airkyi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Mittwoch, 3. Dezember 2025, 12:50:28 Mitteleurop=C3=A4ische Normalzeit s= chrieb Chaoyi Chen: > From: Chaoyi Chen >=20 > This patch checks whether the device is a valid mipi_dsi_device before > accessing it in mipi_dsi_remove_device_fn(). >=20 > The mipi_dsi_host_unregister() assumes that all child devices of the > host device are mipi_dsi_devices and uses mipi_dsi_remove_device_fn() > to perform subsequent operations specific to mipi_dsi_device. >=20 > In rockchip platform, for dw-mipi-dsi-rockchip.c, it creates a dphy > device, and it use the dsi host device as its parent device. >=20 > And when we call dw_mipi_dsi_remove() in > dw_mipi_dsi_rockchip_remove(), mipi_dsi_host_unregister() will get > such a dphy child device and treat it as an mipi_dsi_device, which > will lead to a further panic. >=20 > Signed-off-by: Chaoyi Chen > --- > drivers/gpu/drm/drm_mipi_dsi.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_ds= i.c > index a712e177b350..5b9cc799eb87 100644 > --- a/drivers/gpu/drm/drm_mipi_dsi.c > +++ b/drivers/gpu/drm/drm_mipi_dsi.c > @@ -349,7 +349,12 @@ EXPORT_SYMBOL(mipi_dsi_host_register); > =20 > static int mipi_dsi_remove_device_fn(struct device *dev, void *priv) > { > - struct mipi_dsi_device *dsi =3D to_mipi_dsi_device(dev); > + struct mipi_dsi_device *dsi; > + > + if (!dev_is_mipi_dsi(dev)) > + return 0; > + > + dsi =3D to_mipi_dsi_device(dev); > =20 > if (dsi->attached) > mipi_dsi_detach(dsi); >=20 This makes a lot of sense. Reviewed-by: Heiko Stuebner =46or people reading along: The DSI controllers on the RK3399 uses a phy that is _inside_ the DW-DSI controller, instead of a separate IP block. But this internal PHY can also work as a receiver for camera data for the ISP block in the RK3399. Heiko