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 <[email protected]> know about it.
>From 9736a89dafe07359d9c86bf9c3b815a250b354bc Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <[email protected]>
Date: Sat, 2 Nov 2013 04:29:42 -0300
Subject: media: s5h1420: Don't use dynamic static allocation
From: Mauro Carvalho Chehab <[email protected]>
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 <[email protected]>
Reviewed-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
