The i2c subsystem currently blocks during adapter deregistration
whenever there are consumers holding a reference.

Switch to using of_get_i2c_adapter_by_node() which also takes a
reference to the adapter module so that an attempt to unload the module
while in use fails gracefully instead of blocking uninterruptibly.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/gpu/drm/panel/panel-edp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index aa27d6cd932e..1606b50513d1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -873,7 +873,7 @@ static int panel_edp_probe(struct device *dev, const struct panel_desc *desc,
 
 	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
 	if (ddc) {
-		panel->ddc = of_find_i2c_adapter_by_node(ddc);
+		panel->ddc = of_get_i2c_adapter_by_node(ddc);
 		of_node_put(ddc);
 
 		if (!panel->ddc)
@@ -938,7 +938,7 @@ static int panel_edp_probe(struct device *dev, const struct panel_desc *desc,
 	pm_runtime_disable(dev);
 err_finished_ddc_init:
 	if (panel->ddc && (!panel->aux || panel->ddc != &panel->aux->ddc))
-		put_device(&panel->ddc->dev);
+		i2c_put_adapter(panel->ddc);
 
 	return err;
 }
@@ -983,7 +983,7 @@ static void panel_edp_remove(struct device *dev)
 	pm_runtime_dont_use_autosuspend(dev);
 	pm_runtime_disable(dev);
 	if (panel->ddc && (!panel->aux || panel->ddc != &panel->aux->ddc))
-		put_device(&panel->ddc->dev);
+		i2c_put_adapter(panel->ddc);
 
 	drm_edid_free(panel->drm_edid);
 	panel->drm_edid = NULL;
-- 
2.54.0

Hi,

On Thu, Jul 16, 2026 at 6:22 AM Johan Hovold <johan@kernel.org> wrote:
>
> The i2c subsystem currently blocks during adapter deregistration
> whenever there are consumers holding a reference.
>
> Switch to using of_get_i2c_adapter_by_node() which also takes a
> reference to the adapter module so that an attempt to unload the module
> while in use fails gracefully instead of blocking uninterruptibly.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/gpu/drm/panel/panel-edp.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Worth adding any "Fixes:" tag? I guess this has been using
of_find_i2c_adapter_by_node() for a long time...

Sashiko-bot review [1] seems right, even though it's pointing out
something that isn't really a new problem and is very much a corner
case where someone is crafting an intentionally ridiculous device
tree. If you agree, I wouldn't mind a followup patch fixing that, too.
;-)

[1] https://lore.kernel.org/r/20260716133420.187131F000E9@smtp.kernel.org/

Hi Doug,

On Thu, Jul 16, 2026 at 10:27:02AM -0700, Doug Anderson wrote:

> On Thu, Jul 16, 2026 at 6:22 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > The i2c subsystem currently blocks during adapter deregistration
> > whenever there are consumers holding a reference.
> >
> > Switch to using of_get_i2c_adapter_by_node() which also takes a
> > reference to the adapter module so that an attempt to unload the module
> > while in use fails gracefully instead of blocking uninterruptibly.
> >
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> >  drivers/gpu/drm/panel/panel-edp.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> Worth adding any "Fixes:" tag? I guess this has been using
> of_find_i2c_adapter_by_node() for a long time...

Yeah, this comes from panel-simple which has had this issue since it was
merged in 2013. And that's a couple of years before the helper taking a
module reference even existed. 

I decided not to treat these as individual driver bugs, but perhaps the
instances added after the helper was merged could have had a Fixes tag.

> Sashiko-bot review [1] seems right, even though it's pointing out
> something that isn't really a new problem and is very much a corner
> case where someone is crafting an intentionally ridiculous device
> tree. If you agree, I wouldn't mind a followup patch fixing that, too.
> ;-)
> 
> [1] https://lore.kernel.org/r/20260716133420.187131F000E9@smtp.kernel.org/

Right, I saw that one too but wrote it off as a preexisting issue.

I'll send a v2 of this one rebased on a fix for that instead.

Johan