Message ID | 20231002235407.769399-1-swboyd@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1759449vqb; Mon, 2 Oct 2023 16:54:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEtlwk2+iXvnZCPU856uUwe3V2lTQoNoZ0LHM8i9GUC3Y6ZM8N9dVphs3VxNb6W4B6wkZl0 X-Received: by 2002:a05:6870:468c:b0:1d6:3b5f:3211 with SMTP id a12-20020a056870468c00b001d63b5f3211mr14529410oap.31.1696290871390; Mon, 02 Oct 2023 16:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696290871; cv=none; d=google.com; s=arc-20160816; b=EA1NVaFq/g2AerziigMjwNcBvqmHSpT2+YR3sFmFovEVFBT0kqfL6SmwevD5vHSluO 6XwBMTs5c1tKjvgkidtBrEqwWgv97nYF8+zqJoOLoG/nQ1htx/0JIzWuR0ga2+NeitUS Wb+9hWdRfUpx09PJG3ykhlpV0CEB4m03h6AmCjXMt2zR0LrS3U+JIct31chT/6YvAlzK pBsIxJIRK+CLJweeclELTiYyaRG2Myoo42591+e8BDbdpVKoUcNAl4SnCwNs4rkkj0dc BDDiODjyTT4hpIRn50JV+TNLYGJ1skj0DBpexbdf94Zk/9zLOpoeWZDvvWJ9+P8rNxgM WJvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ri2H++HoCXFAmUL0q2wpktG5mORN8GB1kk/7QHCMaos=; fh=KDxXz/dzlwa9KpsZCDwszaHgmOpRLUXqYbCiQF11kf0=; b=0yYrwImSoGUFgtOlqy1qm0BxP4ovbT1Jt2headIygPmWZ7iZALcJQEXNYJjbTWhvLm QI29y++gB0GF40+fr2uYYK17Y2LwiCySJTQqyeWI+5FiNvG/37jpNW9yJDQdDbg0/v+V koDF1NigldOfG9sxzVT4qdJotkOaSvLVRrVYwTZjySNUlNu4oz6h9QeG7t/5BrN4qgoD Hf6Rnh5betfUSIVFYjZFdEQBtq60Gkv8lI0Zfy9Y9hM2hwZk4Ad+wW69wvqFT1jxnz6m wzFZ+V4UvHgN5D6CxalHzBtWBMcoIbbg9Q1OAcSSuPsZ+pys4x2jJkLrt8isJOO6Nmu7 2gkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YZkgpR1z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id az1-20020a056a02004100b00578b4082453si80414pgb.712.2023.10.02.16.54.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 16:54:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YZkgpR1z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 902FC801D0CA; Mon, 2 Oct 2023 16:54:28 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230046AbjJBXyP (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Mon, 2 Oct 2023 19:54:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbjJBXyO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 2 Oct 2023 19:54:14 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12CE590 for <linux-kernel@vger.kernel.org>; Mon, 2 Oct 2023 16:54:11 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c434c33ec0so2583655ad.3 for <linux-kernel@vger.kernel.org>; Mon, 02 Oct 2023 16:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1696290850; x=1696895650; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ri2H++HoCXFAmUL0q2wpktG5mORN8GB1kk/7QHCMaos=; b=YZkgpR1zirPII/O6NeTEUh28T46qP5l6LA4dnLoXoae9eojCuNrf+NSqHdmX/LFf/V C2+mfFaO4t0x6ziL7zXT6L9BAKeUxQYKxigRvNCfwcLrK6jgLhjwpDzqMfNDGbpbGoid sbSR3LOTZrFtOazurohvpmzeUNE/FOSPmz/GI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696290850; x=1696895650; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ri2H++HoCXFAmUL0q2wpktG5mORN8GB1kk/7QHCMaos=; b=YG3TwTdVu/9pVNHTNNanHvoPdvAY+elDv5Bhzi4TcUa0PbOUe1KWhLlc7FVjyzjDPr J2msC3WNBg+d6fgeem7Fw4Vhq5CLhHFLIT+EnS81Awx2xMBNo9kxAqFXf4XdHkyTYssS oaDxwRQ4TrK5vi1tVyyiVlJftEnO3z6gQUy7dYGi0oAPcKs+bOecTeKK9hp8t7pAwwIJ oby50iVZfU8pSxxTvl3IZ25j9VAkQT9NPYX9qzqOp02gVRJOUWe+Vl5BEFYgq5mejHce b2ULOkv6NQ44kNks/WSEp2hN5UNbASCHwEJEwvNiiVUAAlSI+c7TsMgHdxeINjFZhbtA aMww== X-Gm-Message-State: AOJu0YxtNz9DTkLIttjBU0F2OAGsGkDNTcBx1ptA2dJa3xId6CQrzKZk prqMbevY2mCHHqjXqNj9gXlsLw== X-Received: by 2002:a17:903:48c:b0:1c5:dfe9:b1f3 with SMTP id jj12-20020a170903048c00b001c5dfe9b1f3mr10596391plb.16.1696290850436; Mon, 02 Oct 2023 16:54:10 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:f676:8db:8677:aefe]) by smtp.gmail.com with ESMTPSA id 12-20020a170902ee4c00b001c3ea6073e0sm32167plo.37.2023.10.02.16.54.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 16:54:09 -0700 (PDT) From: Stephen Boyd <swboyd@chromium.org> To: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org> Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, dri-devel@lists.freedesktop.org, Douglas Anderson <dianders@chromium.org>, Maxime Ripard <maxime@cerno.tech> Subject: [PATCH] drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device Date: Mon, 2 Oct 2023 16:54:06 -0700 Message-ID: <20231002235407.769399-1-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.582.g8ccd20d70d-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Mon, 02 Oct 2023 16:54:28 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778689896850132985 X-GMAIL-MSGID: 1778689896850132985 |
Series |
drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device
|
|
Commit Message
Stephen Boyd
Oct. 2, 2023, 11:54 p.m. UTC
The kernel produces a warning splat and the DSI device fails to register
in this driver if the i2c driver probes, populates child auxiliary
devices, and then somewhere in ti_sn_bridge_probe() a function call
returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi
device created by devm_mipi_dsi_device_register_full() is left
registered because the devm managed device used to manage the lifetime
of the DSI device is the parent i2c device, not the auxiliary device
that is being probed.
Associate the DSI device created and managed by this driver to the
lifetime of the auxiliary device, not the i2c device, so that the DSI
device is removed when the auxiliary driver unbinds. Similarly change
the device pointer used for dev_err_probe() so the deferred probe errors
are associated with the auxiliary device instead of the parent i2c
device so we can narrow down future problems faster.
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Maxime Ripard <maxime@cerno.tech>
Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
Comments
Hi, On Mon, Oct 2, 2023 at 4:54 PM Stephen Boyd <swboyd@chromium.org> wrote: > > The kernel produces a warning splat and the DSI device fails to register > in this driver if the i2c driver probes, populates child auxiliary > devices, and then somewhere in ti_sn_bridge_probe() a function call > returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi > device created by devm_mipi_dsi_device_register_full() is left > registered because the devm managed device used to manage the lifetime > of the DSI device is the parent i2c device, not the auxiliary device > that is being probed. > > Associate the DSI device created and managed by this driver to the > lifetime of the auxiliary device, not the i2c device, so that the DSI > device is removed when the auxiliary driver unbinds. Similarly change > the device pointer used for dev_err_probe() so the deferred probe errors > are associated with the auxiliary device instead of the parent i2c > device so we can narrow down future problems faster. > > Cc: Douglas Anderson <dianders@chromium.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") Even before that commit I think it was using the main "dev" instead of the auxiliary device's "dev" for some "devm" stuff. I guess the difference is that it wouldn't mess with probe deferral? Searching back, I think the first instance of a case that was using "devm_" with the wrong device was commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge")? Would it make sense to use that as a Fixes, you think? In any case, this looks reasonable to me: Reviewed-by: Douglas Anderson <dianders@chromium.org> I'll give it a week and then apply to "-fixes" if everything is quiet.
On 03/10/2023 01:54, Stephen Boyd wrote: > The kernel produces a warning splat and the DSI device fails to register > in this driver if the i2c driver probes, populates child auxiliary > devices, and then somewhere in ti_sn_bridge_probe() a function call > returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi > device created by devm_mipi_dsi_device_register_full() is left > registered because the devm managed device used to manage the lifetime > of the DSI device is the parent i2c device, not the auxiliary device > that is being probed. > > Associate the DSI device created and managed by this driver to the > lifetime of the auxiliary device, not the i2c device, so that the DSI > device is removed when the auxiliary driver unbinds. Similarly change > the device pointer used for dev_err_probe() so the deferred probe errors > are associated with the auxiliary device instead of the parent i2c > device so we can narrow down future problems faster. > > Cc: Douglas Anderson <dianders@chromium.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index f448b903e190..84148a79414b 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -692,7 +692,7 @@ static struct ti_sn65dsi86 *bridge_to_ti_sn65dsi86(struct drm_bridge *bridge) > return container_of(bridge, struct ti_sn65dsi86, bridge); > } > > -static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) > +static int ti_sn_attach_host(struct auxiliary_device *adev, struct ti_sn65dsi86 *pdata) > { > int val; > struct mipi_dsi_host *host; > @@ -707,7 +707,7 @@ static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) > if (!host) > return -EPROBE_DEFER; > > - dsi = devm_mipi_dsi_device_register_full(dev, host, &info); > + dsi = devm_mipi_dsi_device_register_full(&adev->dev, host, &info); > if (IS_ERR(dsi)) > return PTR_ERR(dsi); > > @@ -725,7 +725,7 @@ static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) > > pdata->dsi = dsi; > > - return devm_mipi_dsi_attach(dev, dsi); > + return devm_mipi_dsi_attach(&adev->dev, dsi); > } > > static int ti_sn_bridge_attach(struct drm_bridge *bridge, > @@ -1298,9 +1298,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, > struct device_node *np = pdata->dev->of_node; > int ret; > > - pdata->next_bridge = devm_drm_of_get_bridge(pdata->dev, np, 1, 0); > + pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0); > if (IS_ERR(pdata->next_bridge)) > - return dev_err_probe(pdata->dev, PTR_ERR(pdata->next_bridge), > + return dev_err_probe(&adev->dev, PTR_ERR(pdata->next_bridge), > "failed to create panel bridge\n"); > > ti_sn_bridge_parse_lanes(pdata, np); > @@ -1319,9 +1319,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, > > drm_bridge_add(&pdata->bridge); > > - ret = ti_sn_attach_host(pdata); > + ret = ti_sn_attach_host(adev, pdata); > if (ret) { > - dev_err_probe(pdata->dev, ret, "failed to attach dsi host\n"); > + dev_err_probe(&adev->dev, ret, "failed to attach dsi host\n"); > goto err_remove_bridge; > } > > > base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d This looks reasonable Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Quoting Doug Anderson (2023-10-02 17:31:41) > Hi, > > On Mon, Oct 2, 2023 at 4:54 PM Stephen Boyd <swboyd@chromium.org> wrote: > > > > The kernel produces a warning splat and the DSI device fails to register > > in this driver if the i2c driver probes, populates child auxiliary > > devices, and then somewhere in ti_sn_bridge_probe() a function call > > returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi > > device created by devm_mipi_dsi_device_register_full() is left > > registered because the devm managed device used to manage the lifetime > > of the DSI device is the parent i2c device, not the auxiliary device > > that is being probed. > > > > Associate the DSI device created and managed by this driver to the > > lifetime of the auxiliary device, not the i2c device, so that the DSI > > device is removed when the auxiliary driver unbinds. Similarly change > > the device pointer used for dev_err_probe() so the deferred probe errors > > are associated with the auxiliary device instead of the parent i2c > > device so we can narrow down future problems faster. > > > > Cc: Douglas Anderson <dianders@chromium.org> > > Cc: Maxime Ripard <maxime@cerno.tech> > > Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") > > Even before that commit I think it was using the main "dev" instead of > the auxiliary device's "dev" for some "devm" stuff. I guess the > difference is that it wouldn't mess with probe deferral? Searching > back, I think the first instance of a case that was using "devm_" with > the wrong device was commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: > Wrap panel with panel-bridge")? Would it make sense to use that as a > Fixes, you think? The problem for me is that the dsi device is registered twice. That happens because probe for the auxiliary device happens twice. I was cautious about the fixes tag here because it didn't look like probe deferral was happening before commit c3b75d4734cb. > > In any case, this looks reasonable to me: > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > I'll give it a week and then apply to "-fixes" if everything is quiet. Thanks!
Hi, On Thu, Oct 5, 2023 at 10:18 AM Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Doug Anderson (2023-10-02 17:31:41) > > Hi, > > > > On Mon, Oct 2, 2023 at 4:54 PM Stephen Boyd <swboyd@chromium.org> wrote: > > > > > > The kernel produces a warning splat and the DSI device fails to register > > > in this driver if the i2c driver probes, populates child auxiliary > > > devices, and then somewhere in ti_sn_bridge_probe() a function call > > > returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi > > > device created by devm_mipi_dsi_device_register_full() is left > > > registered because the devm managed device used to manage the lifetime > > > of the DSI device is the parent i2c device, not the auxiliary device > > > that is being probed. > > > > > > Associate the DSI device created and managed by this driver to the > > > lifetime of the auxiliary device, not the i2c device, so that the DSI > > > device is removed when the auxiliary driver unbinds. Similarly change > > > the device pointer used for dev_err_probe() so the deferred probe errors > > > are associated with the auxiliary device instead of the parent i2c > > > device so we can narrow down future problems faster. > > > > > > Cc: Douglas Anderson <dianders@chromium.org> > > > Cc: Maxime Ripard <maxime@cerno.tech> > > > Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") > > > > Even before that commit I think it was using the main "dev" instead of > > the auxiliary device's "dev" for some "devm" stuff. I guess the > > difference is that it wouldn't mess with probe deferral? Searching > > back, I think the first instance of a case that was using "devm_" with > > the wrong device was commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: > > Wrap panel with panel-bridge")? Would it make sense to use that as a > > Fixes, you think? > > The problem for me is that the dsi device is registered twice. That > happens because probe for the auxiliary device happens twice. I was > cautious about the fixes tag here because it didn't look like probe > deferral was happening before commit c3b75d4734cb. > > > > > In any case, this looks reasonable to me: > > > > Reviewed-by: Douglas Anderson <dianders@chromium.org> > > > > I'll give it a week and then apply to "-fixes" if everything is quiet. > > Thanks! Pushed to drm-misc-fixes leaving your existing "Fixes" line: 7b821db95140 drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device -Doug
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index f448b903e190..84148a79414b 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -692,7 +692,7 @@ static struct ti_sn65dsi86 *bridge_to_ti_sn65dsi86(struct drm_bridge *bridge) return container_of(bridge, struct ti_sn65dsi86, bridge); } -static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) +static int ti_sn_attach_host(struct auxiliary_device *adev, struct ti_sn65dsi86 *pdata) { int val; struct mipi_dsi_host *host; @@ -707,7 +707,7 @@ static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) if (!host) return -EPROBE_DEFER; - dsi = devm_mipi_dsi_device_register_full(dev, host, &info); + dsi = devm_mipi_dsi_device_register_full(&adev->dev, host, &info); if (IS_ERR(dsi)) return PTR_ERR(dsi); @@ -725,7 +725,7 @@ static int ti_sn_attach_host(struct ti_sn65dsi86 *pdata) pdata->dsi = dsi; - return devm_mipi_dsi_attach(dev, dsi); + return devm_mipi_dsi_attach(&adev->dev, dsi); } static int ti_sn_bridge_attach(struct drm_bridge *bridge, @@ -1298,9 +1298,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, struct device_node *np = pdata->dev->of_node; int ret; - pdata->next_bridge = devm_drm_of_get_bridge(pdata->dev, np, 1, 0); + pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0); if (IS_ERR(pdata->next_bridge)) - return dev_err_probe(pdata->dev, PTR_ERR(pdata->next_bridge), + return dev_err_probe(&adev->dev, PTR_ERR(pdata->next_bridge), "failed to create panel bridge\n"); ti_sn_bridge_parse_lanes(pdata, np); @@ -1319,9 +1319,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, drm_bridge_add(&pdata->bridge); - ret = ti_sn_attach_host(pdata); + ret = ti_sn_attach_host(adev, pdata); if (ret) { - dev_err_probe(pdata->dev, ret, "failed to attach dsi host\n"); + dev_err_probe(&adev->dev, ret, "failed to attach dsi host\n"); goto err_remove_bridge; }