[PATCH v4 07/15] media: meson-ir-tx: Ensure clock is disabled on unbind
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Mon Jul 27 07:51:56 PDT 2026
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] Memory leak of the rc_dev struct on driver unbind due to mixing unmanaged allocation with managed registration.
- [High] Integer underflow and division by zero when configuring high carrier frequencies.
- [High] Lockless check of completion_done in the IRQ handler exposes a race that can overflow the hardware FIFO.
- [Medium] Error codes from core kernel APIs are hardcoded to -ENODEV, breaking probe deferral.
--
--- Patch [7]: [PATCH v4 07/15] media: meson-ir-tx: Ensure clock is disabled on unbind ---
commit b425f7e336876fa07197476c4560b56dec0eb33d
Author: Sean Young <sean at mess.org>
media: meson-ir-tx: Ensure clock is disabled on unbind
clk_prepare_enable() needs a call to clk_disable_unprepare() on
driver unbind. Make it devm managed.
> diff --git a/drivers/media/rc/meson-ir-tx.c b/drivers/media/rc/meson-ir-tx.c
> index fded2c256f2a6..e7bb107e6a843 100644
> --- a/drivers/media/rc/meson-ir-tx.c
> +++ b/drivers/media/rc/meson-ir-tx.c
> @@ -288,8 +288,8 @@ static int meson_irtx_mod_clock_probe(struct meson_irtx *ir,
> if (!np)
> return -ENODEV;
>
> - clock = devm_clk_get(ir->dev, "xtal");
> - if (IS_ERR(clock) || clk_prepare_enable(clock))
> + clock = devm_clk_get_enabled(ir->dev, "xtal");
> + if (IS_ERR(clock))
> return -ENODEV;
>
> *clk_nr = IRB_MOD_XTAL3_CLK;
[Severity: Medium]
This isn't a bug introduced by this patch, but returning -ENODEV here prevents
proper probe deferral. If the clock is not yet ready and devm_clk_get_enabled()
returns -EPROBE_DEFER, the initialization will permanently fail instead of
trying again later.
Also in meson_irtx_probe(), the same pattern exists for the IRQ:
drivers/media/rc/meson-ir-tx.c:meson_irtx_probe() {
...
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return -ENODEV;
...
}
Should these functions return the exact error pointer (e.g. PTR_ERR(clock))
or error code rather than hardcoding -ENODEV?
[Severity: High]
This is a pre-existing issue, but does this code cause an integer underflow
and division by zero when configuring high carrier frequencies?
drivers/media/rc/meson-ir-tx.c:meson_irtx_set_mod() {
...
unsigned int cnt = DIV_ROUND_CLOSEST(ir->clk_rate, ir->carrier);
unsigned int pulse_cnt = DIV_ROUND_CLOSEST(cnt * ir->duty_cycle, 100);
unsigned int space_cnt = cnt - pulse_cnt;
dev_dbg(ir->dev, "F_mod = %uHz, T_mod = %luns, duty_cycle = %u%%\n",
ir->carrier, NSEC_PER_SEC / ir->clk_rate * cnt,
100 * pulse_cnt / cnt);
...
}
If a user space process provides a carrier frequency greater than twice the
modulator clock rate (ir->clk_rate), cnt will be 0. This results in pulse_cnt
being 0, which triggers a division by zero in the dev_dbg() statement.
Could this also cause an underflow when writing to the hardware register via
IRB_MOD_COUNT(pulse_cnt, space_cnt)?
[Severity: High]
This is a pre-existing issue, but does the lockless check of completion_done()
in the IRQ handler expose a race condition?
drivers/media/rc/meson-ir-tx.c:meson_irtx_irqhandler() {
...
if (completion_done(&ir->completion))
return IRQ_HANDLED;
spin_lock_irqsave(&ir->lock, flags);
if (ir->buf_head < ir->buf_len)
meson_irtx_send_buffer(ir);
else
complete(&ir->completion);
spin_unlock_irqrestore(&ir->lock, flags);
...
}
If an edge interrupt for the FIFO threshold is delayed, and a new transmission
begins by acquiring the lock and reinitializing the completion, could the
delayed IRQ handler evaluate completion_done() outside the lock, see it as
false, and then blindly write up to 96 more words, overflowing the hardware
FIFO?
[Severity: High]
This is a pre-existing issue, but does this code leak the rc_dev structure on
driver unbind?
drivers/media/rc/meson-ir-tx.c:meson_irtx_probe() {
...
rc = rc_allocate_device(RC_DRIVER_IR_RAW_TX);
if (!rc)
return -ENOMEM;
...
ret = devm_rc_register_device(dev, rc);
if (ret < 0) {
rc_free_device(rc);
return dev_err_probe(dev, ret, "rc_dev registration failed\n");
}
...
}
Because rc is allocated with rc_allocate_device() instead of a managed
variant like devm_rc_allocate_device(), when the driver is unbound,
devm_rc_register_device() will automatically unregister the device, but the
memory for the rc_dev structure is never freed since there is no remove
callback.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785158244.git.sean@mess.org?part=7
More information about the linux-amlogic
mailing list