This is a note to let you know that I've just added the patch titled
media: s5h1420: Don't use dynamic static allocation
to the 3.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
media-s5h1420-don-t-use-dynamic-static-allocation.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 9736a89dafe07359d9c86bf9c3b815a250b354bc Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Date: Sat, 2 Nov 2013 04:29:42 -0300
Subject: media: s5h1420: Don't use dynamic static allocation
From: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
commit 9736a89dafe07359d9c86bf9c3b815a250b354bc upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this frontend, only ttpci uses it. The maximum
number of messages there is two, on I2C read operations. As the logic
can add an extra operation, change the size to 3.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Reviewed-by: Hans Verkuil <hans.verkuil@xxxxxxxxx>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/media/dvb-frontends/s5h1420.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb-frontends/s5h1420.c
+++ b/drivers/media/dvb-frontends/s5h1420.c
@@ -836,9 +836,16 @@ static u32 s5h1420_tuner_i2c_func(struct
static int s5h1420_tuner_i2c_tuner_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msg[], int num)
{
struct s5h1420_state *state = i2c_get_adapdata(i2c_adap);
- struct i2c_msg m[1 + num];
+ struct i2c_msg m[3];
u8 tx_open[2] = { CON_1, state->CON_1_val | 1 }; /* repeater stops once there was a stop condition */
+ if (1 + num > ARRAY_SIZE(m)) {
+ printk(KERN_WARNING
+ "%s: i2c xfer: num=%d is too big!\n",
+ KBUILD_MODNAME, num);
+ return -EOPNOTSUPP;
+ }
+
memset(m, 0, sizeof(struct i2c_msg) * (1 + num));
m[0].addr = state->config->demod_address;
@@ -847,7 +854,7 @@ static int s5h1420_tuner_i2c_tuner_xfer(
memcpy(&m[1], msg, sizeof(struct i2c_msg) * num);
- return i2c_transfer(state->i2c, m, 1+num) == 1 + num ? num : -EIO;
+ return i2c_transfer(state->i2c, m, 1 + num) == 1 + num ? num : -EIO;
}
static struct i2c_algorithm s5h1420_tuner_i2c_algo = {
Patches currently in stable-queue which might be from m.chehab@xxxxxxxxxxx are
queue-3.10/media-af9015-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-dw2102-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-af9035-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-stb0899_drv-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-dibusb-common-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-cx18-struct-i2c_client-is-too-big-for-stack.patch
queue-3.10/media-tuner-xc2028-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-cimax2-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-tuners-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-dvb-frontends-again-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-dvb-frontends-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-stv090x-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-s5h1420-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-av7110_hw-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-stv0367-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-lirc_zilog-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-cxusb-don-t-use-dynamic-static-allocation.patch
queue-3.10/media-mxl111sf-don-t-use-dynamic-static-allocation.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html