From: Myeonghun Pak <mhun512@gmail.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Hans Verkuil <hverkuil@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, Ijae Kim <ae878000@gmail.com>
Subject: Re: [PATCH] media: s5p_cec: release IRQ before deleting the adapter
Date: Mon, 19 Oct 2026 19:03:03 -0400 [thread overview]
Message-ID: <CAGEsz8G1k9O2CpA23vKmUFghfN-HTFhVUtx693A0whq-mSbxYA@mail.gmail.com> (raw)
In-Reply-To: <6c07141b-e2d7-49b2-8493-394d727c3a15@samsung.com>
Hi Marek,
Agreed. I'll switch to request_threaded_irq() and free_irq() in v2.
Thanks for the review.
Best regards,
Myeonghun
2026년 10월 19일 (월) 오전 2:54, Marek Szyprowski <m.szyprowski@samsung.com>님이 작성:
>
> On 18.10.2026 05:51, Myeonghun Pak wrote:
> > The threaded IRQ handler reports transmit and receive events through
> > cec->adap. Adapter unregistration masks the hardware interrupts but does
> > not wait for this handler. With no open device-node references, it can
> > free the adapter while an already queued IRQ thread still uses it.
> > Devres also unmaps the registers before releasing the IRQ, since the
> > mapping was acquired after the IRQ.
> >
> > Free the managed IRQ before unregistering the adapter and disabling
> > runtime PM. Request it only after the register mapping and adapter have
> > been initialized, and free it on adapter registration failure before
> > deleting the adapter. This also makes IRQ release precede MMIO release
> > on probe unwind.
> >
> > This issue was identified as part of our ongoing research while
> > reviewing kernel code.
> >
> > Fixes: 1bcbf6f4b6b0 ("[media] cec: s5p-cec: Add s5p-cec driver")
> > Co-developed-by: Ijae Kim <ae878000@gmail.com>
> > Signed-off-by: Ijae Kim <ae878000@gmail.com>
> > Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> >
> > ---
> > Compile-tested with Clang, W=1. No hardware runtime testing.
> >
> > Based on mainline 0fcb05b72344f40806cbe810de8872f1698bf053.
> >
> > diff --git a/drivers/media/cec/platform/s5p/s5p_cec.c b/drivers/media/cec/platform/s5p/s5p_cec.c
> > index 4a92d32..e83705f 100644
> > --- a/drivers/media/cec/platform/s5p/s5p_cec.c
> > +++ b/drivers/media/cec/platform/s5p/s5p_cec.c
> > @@ -199,11 +199,6 @@ static int s5p_cec_probe(struct platform_device *pdev)
> > if (cec->irq < 0)
> > return cec->irq;
> >
> > - ret = devm_request_threaded_irq(dev, cec->irq, s5p_cec_irq_handler,
> > - s5p_cec_irq_handler_thread, 0, pdev->name, cec);
> > - if (ret)
> > - return ret;
> > -
> > cec->clk = devm_clk_get(dev, "hdmicec");
> > if (IS_ERR(cec->clk))
> > return PTR_ERR(cec->clk);
> > @@ -231,16 +226,24 @@ static int s5p_cec_probe(struct platform_device *pdev)
> > goto err_delete_adapter;
> > }
> >
> > - ret = cec_register_adapter(cec->adap, &pdev->dev);
> > + ret = devm_request_threaded_irq(dev, cec->irq, s5p_cec_irq_handler,
> > + s5p_cec_irq_handler_thread, 0, pdev->name, cec);
> > if (ret)
> > goto err_notifier;
> >
> > + ret = cec_register_adapter(cec->adap, &pdev->dev);
> > + if (ret)
> > + goto err_free_irq;
> > +
> > platform_set_drvdata(pdev, cec);
> > pm_runtime_enable(dev);
> >
> > dev_dbg(dev, "successfully probed\n");
> > return 0;
> >
> > +err_free_irq:
> > + devm_free_irq(dev, cec->irq, cec);
> There is no point in using devm_* API if one needs to manually free the
> resource for whatever reason.
>
>
> > +
> > err_notifier:
> > cec_notifier_cec_adap_unregister(cec->notifier, cec->adap);
> >
> > @@ -253,6 +256,7 @@ static void s5p_cec_remove(struct platform_device *pdev)
> > {
> > struct s5p_cec_dev *cec = platform_get_drvdata(pdev);
> >
> > + devm_free_irq(&pdev->dev, cec->irq, cec);
> > cec_notifier_cec_adap_unregister(cec->notifier, cec->adap);
> > cec_unregister_adapter(cec->adap);
> > pm_runtime_disable(&pdev->dev);
> >
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
prev parent reply other threads:[~2026-10-19 23:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261018035132eucas1p2ccd8f0233fd196fd8801506c1c213b39@eucas1p2.samsung.com>
2026-10-18 3:51 ` Myeonghun Pak
2026-10-19 6:54 ` Marek Szyprowski
2026-10-19 23:03 ` Myeonghun Pak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGEsz8G1k9O2CpA23vKmUFghfN-HTFhVUtx693A0whq-mSbxYA@mail.gmail.com \
--to=mhun512@gmail.com \
--cc=ae878000@gmail.com \
--cc=hverkuil@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®