From: Sean Young <sean@mess.org>
To: Cosmin Tanislav <demonsingur@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] media: rc: ir-spi: constrain carrier frequency
Date: Thu, 12 Jun 2025 21:10:42 +0100 [thread overview]
Message-ID: <aEs0Qr3O5myydP_L@gofer.mess.org> (raw)
In-Reply-To: <aEsycgtDxrypTU0v@gofer.mess.org>
On Thu, Jun 12, 2025 at 09:02:59PM +0100, Sean Young wrote:
> On Wed, Jun 11, 2025 at 11:35:21PM +0300, Cosmin Tanislav wrote:
> > On 6/11/25 11:09 PM, Sean Young wrote:
> > > On Wed, Jun 11, 2025 at 02:23:44PM +0300, Cosmin Tanislav wrote:
> > > > Carrier frequency is currently unconstrained, allowing the SPI transfer
> > > > to be allocated and filled only for it to be later rejected by the SPI
> > > > controller since the frequency is too large.
> > > >
> > > > Add a check to constrain the carrier frequency inside
> > > > ir_spi_set_tx_carrier().
> > > >
> > > > Also, move the number of bits per pulse to a macro since it is not used
> > > > in multiple places.
> > > >
> > > > Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
> > > > ---
> > > > drivers/media/rc/ir-spi.c | 6 +++++-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
> > > > index 50e30e2fae22..bf731204c81e 100644
> > > > --- a/drivers/media/rc/ir-spi.c
> > > > +++ b/drivers/media/rc/ir-spi.c
> > > > @@ -21,6 +21,7 @@
> > > > #define IR_SPI_DRIVER_NAME "ir-spi"
> > > > #define IR_SPI_DEFAULT_FREQUENCY 38000
> > > > +#define IR_SPI_BITS_PER_PULSE 16
> > > > struct ir_spi_data {
> > > > u32 freq;
> > > > @@ -70,7 +71,7 @@ static int ir_spi_tx(struct rc_dev *dev, unsigned int *buffer, unsigned int coun
> > > > memset(&xfer, 0, sizeof(xfer));
> > > > - xfer.speed_hz = idata->freq * 16;
> > > > + xfer.speed_hz = idata->freq * IR_SPI_BITS_PER_PULSE;
> > > > xfer.len = len * sizeof(*tx_buf);
> > > > xfer.tx_buf = tx_buf;
> > > > @@ -98,6 +99,9 @@ static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
> > > > if (!carrier)
> > > > return -EINVAL;
> > > > + if (carrier * IR_SPI_BITS_PER_PULSE > idata->spi->max_speed_hz)
> > > > + return -EINVAL;
> > >
> > > Just a nitpick.
> > >
> > > I think carrier * IR_SPI_BITS_PER_PULSE could overflow, and then the check
> > > wouldn't work. It might be better to do:
> > >
> > > if (carrier > idata->spi->max_speed_hz / IR_SPI_BITS_PER_PULSE)
> > >
> > > However since IR_SPI_BITS_PER_PULSE is 16, which is just a shift left by 4,
> > > I don't think this can be abused in any useful way.
> > >
> >
> > I have another concern regarding overflow, inside ir_spi_tx().
> >
> > DIV_ROUND_CLOSEST() is called with buffer[i] * idata->freq and 1000000.
> > buffer[i] comes from userspace, it's the number of microseconds for this
> > pulse. It's unsigned int. lirc core already checks that each element
> > is not bigger than 500000 microseconds. Issue is, at 500000, it would
> > take a carrier frequency as low as 8590 to overflow the unsigned int.
>
> Interesting, you are right.
>
> > Maybe it would make sense to switch this one to mult_frac()? But we
> > would lose rounding.
> >
> > mult_frac(buffer[i], idata->freq, 1000000)
> >
> > Optionally, we could cast buffer[i] to u64/unsigned long long, and use
> > DIV_ROUND_CLOSEST_ULL.
> >
> > DIV_ROUND_CLOSEST_ULL((u64)buffer[i] * idata->freq, 1000000)
> >
> > Let me know what you think.
>
> I've given it some thought and I'm not sure there is a better solution. It's
> an edge case of course, but we should deal with it correctly.
Actually could we use check_mul_overflow() for this?
Just an idea.
Sean
next prev parent reply other threads:[~2025-06-12 20:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 11:23 [PATCH v4 0/2] media: rc: ir-spi: allocate buffer dynamically Cosmin Tanislav
2025-06-11 11:23 ` [PATCH v4 1/2] " Cosmin Tanislav
2025-06-11 11:23 ` [PATCH v4 2/2] media: rc: ir-spi: constrain carrier frequency Cosmin Tanislav
2025-06-11 20:09 ` Sean Young
2025-06-11 20:35 ` Cosmin Tanislav
2025-06-12 20:02 ` Sean Young
2025-06-12 20:10 ` Sean Young [this message]
2025-06-12 20:20 ` Cosmin Tanislav
2025-06-13 9:30 ` Sean Young
2025-06-13 9:52 ` Cosmin Tanislav
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=aEs0Qr3O5myydP_L@gofer.mess.org \
--to=sean@mess.org \
--cc=demonsingur@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.