* [PATCHv2 01/29] tda9887: remove an warning when compiling for alpha
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 02/29] radio-shark: remove a warning when CONFIG_PM is not defined Mauro Carvalho Chehab
` (27 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
There's no need to zero the buffer, as if the routine gets an error,
rc will be different than one.
That fixes the following warning:
drivers/media/tuners/tda9887.c: In function 'tda9887_status':
drivers/media/tuners/tda9887.c:539:2: warning: value computed is not used [-Wunused-value]
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/tuners/tda9887.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tda9887.c b/drivers/media/tuners/tda9887.c
index 300005c535ba..9823248d743f 100644
--- a/drivers/media/tuners/tda9887.c
+++ b/drivers/media/tuners/tda9887.c
@@ -536,8 +536,8 @@ static int tda9887_status(struct dvb_frontend *fe)
unsigned char buf[1];
int rc;
- memset(buf,0,sizeof(buf));
- if (1 != (rc = tuner_i2c_xfer_recv(&priv->i2c_props,buf,1)))
+ rc = tuner_i2c_xfer_recv(&priv->i2c_props, buf, 1);
+ if (rc != 1)
tuner_info("i2c i/o error: rc == %d (should be 1)\n", rc);
dump_read_message(fe, buf);
return 0;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 02/29] radio-shark: remove a warning when CONFIG_PM is not defined
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 01/29] tda9887: remove an warning when compiling for alpha Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 03/29] zoran: don't build it on alpha Mauro Carvalho Chehab
` (26 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
On alpha, allyesconfig doesn't have CONFIG_PM, and produces the following warnings:
drivers/media/radio/radio-shark.c:274:13: warning: 'shark_resume_leds' defined but not used [-Wunused-function]
drivers/media/radio/radio-shark2.c:240:13: warning: 'shark_resume_leds' defined but not used [-Wunused-function]
That's because those functions are used only at device resume.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/radio/radio-shark.c | 2 ++
drivers/media/radio/radio-shark2.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/radio/radio-shark.c b/drivers/media/radio/radio-shark.c
index b91477212413..3db8a8cfe1a8 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -271,6 +271,7 @@ static void shark_unregister_leds(struct shark_device *shark)
cancel_work_sync(&shark->led_work);
}
+#ifdef CONFIG_PM
static void shark_resume_leds(struct shark_device *shark)
{
if (test_bit(BLUE_IS_PULSE, &shark->brightness_new))
@@ -280,6 +281,7 @@ static void shark_resume_leds(struct shark_device *shark)
set_bit(RED_LED, &shark->brightness_new);
schedule_work(&shark->led_work);
}
+#endif
#else
static int shark_register_leds(struct shark_device *shark, struct device *dev)
{
diff --git a/drivers/media/radio/radio-shark2.c b/drivers/media/radio/radio-shark2.c
index 9fb669721e66..d86d90dab8bf 100644
--- a/drivers/media/radio/radio-shark2.c
+++ b/drivers/media/radio/radio-shark2.c
@@ -237,6 +237,7 @@ static void shark_unregister_leds(struct shark_device *shark)
cancel_work_sync(&shark->led_work);
}
+#ifdef CONFIG_PM
static void shark_resume_leds(struct shark_device *shark)
{
int i;
@@ -246,6 +247,7 @@ static void shark_resume_leds(struct shark_device *shark)
schedule_work(&shark->led_work);
}
+#endif
#else
static int shark_register_leds(struct shark_device *shark, struct device *dev)
{
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 03/29] zoran: don't build it on alpha
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 01/29] tda9887: remove an warning when compiling for alpha Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 02/29] radio-shark: remove a warning when CONFIG_PM is not defined Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 04/29] cx18: struct i2c_client is too big for stack Mauro Carvalho Chehab
` (25 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
This driver uses virt_to_bus() with is deprecated on Alpha:
drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_vfe':
drivers/media/pci/zoran/zoran_device.c:451:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_device.c:453:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_jpg':
drivers/media/pci/zoran/zoran_device.c:796:2: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_driver.c: In function 'v4l_fbuffer_alloc':
drivers/media/pci/zoran/zoran_driver.c:241:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_driver.c:245:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_driver.c: In function 'jpg_fbuffer_alloc':
drivers/media/pci/zoran/zoran_driver.c:334:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_driver.c:347:5: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
drivers/media/pci/zoran/zoran_driver.c:366:6: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations]
As we're not even sure if it works on Alpha, better to just disable its compilation there.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/pci/zoran/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
index 26ca8702e33f..39ec35bd21a5 100644
--- a/drivers/media/pci/zoran/Kconfig
+++ b/drivers/media/pci/zoran/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_ZORAN
tristate "Zoran ZR36057/36067 Video For Linux"
depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS
+ depends on !ALPHA
help
Say Y for support for MJPEG capture cards based on the Zoran
36057/36067 PCI controller chipset. This includes the Iomega
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 04/29] cx18: struct i2c_client is too big for stack
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (2 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 03/29] zoran: don't build it on alpha Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 05/29] tef6862: fix warning on avr32 arch Mauro Carvalho Chehab
` (24 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom':
drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
That happens because the routine allocates 256 bytes for an eeprom buffer, plus
the size of struct i2c_client, with is big.
Change the logic to dynamically allocate/deallocate space for struct i2c_client,
instead of using the stack.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/pci/cx18/cx18-driver.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/cx18/cx18-driver.c b/drivers/media/pci/cx18/cx18-driver.c
index ff7232023f56..87f5bcf29e90 100644
--- a/drivers/media/pci/cx18/cx18-driver.c
+++ b/drivers/media/pci/cx18/cx18-driver.c
@@ -324,23 +324,24 @@ static void cx18_eeprom_dump(struct cx18 *cx, unsigned char *eedata, int len)
/* Hauppauge card? get values from tveeprom */
void cx18_read_eeprom(struct cx18 *cx, struct tveeprom *tv)
{
- struct i2c_client c;
+ struct i2c_client *c;
u8 eedata[256];
- memset(&c, 0, sizeof(c));
- strlcpy(c.name, "cx18 tveeprom tmp", sizeof(c.name));
- c.adapter = &cx->i2c_adap[0];
- c.addr = 0xA0 >> 1;
+ c = kzalloc(sizeof(*c), GFP_ATOMIC);
+
+ strlcpy(c->name, "cx18 tveeprom tmp", sizeof(c->name));
+ c->adapter = &cx->i2c_adap[0];
+ c->addr = 0xa0 >> 1;
memset(tv, 0, sizeof(*tv));
- if (tveeprom_read(&c, eedata, sizeof(eedata)))
- return;
+ if (tveeprom_read(c, eedata, sizeof(eedata)))
+ goto ret;
switch (cx->card->type) {
case CX18_CARD_HVR_1600_ESMT:
case CX18_CARD_HVR_1600_SAMSUNG:
case CX18_CARD_HVR_1600_S5H1411:
- tveeprom_hauppauge_analog(&c, tv, eedata);
+ tveeprom_hauppauge_analog(c, tv, eedata);
break;
case CX18_CARD_YUAN_MPC718:
case CX18_CARD_GOTVIEW_PCI_DVD3:
@@ -354,6 +355,9 @@ void cx18_read_eeprom(struct cx18 *cx, struct tveeprom *tv)
cx18_eeprom_dump(cx, eedata, sizeof(eedata));
break;
}
+
+ret:
+ kfree(c);
}
static void cx18_process_eeprom(struct cx18 *cx)
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 05/29] tef6862: fix warning on avr32 arch
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (3 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 04/29] cx18: struct i2c_client is too big for stack Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 06/29] iguanair: shut up a gcc " Mauro Carvalho Chehab
` (23 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
On avr32 arch, we get those warnings:
drivers/media/radio/tef6862.c:59:1: warning: "MODE_SHIFT" redefined
In file included from /devel/v4l/ktest-build/arch/avr32/include/asm/ptrace.h:11,
arch/avr32/include/uapi/asm/ptrace.h:41:1: warning: this is the location of the previous definition
Prefix MSA_ to the MSA register bitmap macros, to avoid reusing the same symbol.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/radio/tef6862.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/radio/tef6862.c b/drivers/media/radio/tef6862.c
index 06ac69245ca1..69e3245a58a0 100644
--- a/drivers/media/radio/tef6862.c
+++ b/drivers/media/radio/tef6862.c
@@ -48,15 +48,15 @@
#define WM_SUB_TEST 0xF
/* Different modes of the MSA register */
-#define MODE_BUFFER 0x0
-#define MODE_PRESET 0x1
-#define MODE_SEARCH 0x2
-#define MODE_AF_UPDATE 0x3
-#define MODE_JUMP 0x4
-#define MODE_CHECK 0x5
-#define MODE_LOAD 0x6
-#define MODE_END 0x7
-#define MODE_SHIFT 5
+#define MSA_MODE_BUFFER 0x0
+#define MSA_MODE_PRESET 0x1
+#define MSA_MODE_SEARCH 0x2
+#define MSA_MODE_AF_UPDATE 0x3
+#define MSA_MODE_JUMP 0x4
+#define MSA_MODE_CHECK 0x5
+#define MSA_MODE_LOAD 0x6
+#define MSA_MODE_END 0x7
+#define MSA_MODE_SHIFT 5
struct tef6862_state {
struct v4l2_subdev sd;
@@ -114,7 +114,7 @@ static int tef6862_s_frequency(struct v4l2_subdev *sd, const struct v4l2_frequen
clamp(freq, TEF6862_LO_FREQ, TEF6862_HI_FREQ);
pll = 1964 + ((freq - TEF6862_LO_FREQ) * 20) / FREQ_MUL;
- i2cmsg[0] = (MODE_PRESET << MODE_SHIFT) | WM_SUB_PLLM;
+ i2cmsg[0] = (MSA_MODE_PRESET << MSA_MODE_SHIFT) | WM_SUB_PLLM;
i2cmsg[1] = (pll >> 8) & 0xff;
i2cmsg[2] = pll & 0xff;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 06/29] iguanair: shut up a gcc warning on avr32 arch
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (4 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 05/29] tef6862: fix warning on avr32 arch Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-03 22:10 ` Sean Young
2013-11-02 13:31 ` [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs Mauro Carvalho Chehab
` (22 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
drivers/media/rc/iguanair.c: In function 'iguanair_set_tx_carrier':
drivers/media/rc/iguanair.c:304: warning: 'sevens' may be used uninitialized in this function
This is clearly a gcc bug, but it doesn't hurt to add a default line
at the switch to shut it up.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/rc/iguanair.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 19632b1c2190..67e5667db2eb 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -320,6 +320,7 @@ static int iguanair_set_tx_carrier(struct rc_dev *dev, uint32_t carrier)
sevens = 2;
break;
case 3:
+ default:
sevens = 1;
break;
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 06/29] iguanair: shut up a gcc warning on avr32 arch
2013-11-02 13:31 ` [PATCHv2 06/29] iguanair: shut up a gcc " Mauro Carvalho Chehab
@ 2013-11-03 22:10 ` Sean Young
2013-11-03 22:13 ` [PATCH] [media] iguanair: simplify calculation of carrier delay cycles Sean Young
0 siblings, 1 reply; 59+ messages in thread
From: Sean Young @ 2013-11-03 22:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
On Sat, Nov 02, 2013 at 11:31:14AM -0200, Mauro Carvalho Chehab wrote:
> drivers/media/rc/iguanair.c: In function 'iguanair_set_tx_carrier':
> drivers/media/rc/iguanair.c:304: warning: 'sevens' may be used uninitialized in this function
>
> This is clearly a gcc bug, but it doesn't hurt to add a default line
> at the switch to shut it up.
Mauro, I have a different way of solving this which also cleans up the code
a little. I'll send a patch shortly.
Sean
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH] [media] iguanair: simplify calculation of carrier delay cycles
2013-11-03 22:10 ` Sean Young
@ 2013-11-03 22:13 ` Sean Young
0 siblings, 0 replies; 59+ messages in thread
From: Sean Young @ 2013-11-03 22:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Signed-off-by: Sean Young <sean@mess.org>
---
drivers/media/rc/iguanair.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 19632b1..7f05e19 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -308,22 +308,12 @@ static int iguanair_set_tx_carrier(struct rc_dev *dev, uint32_t carrier)
cycles = DIV_ROUND_CLOSEST(24000000, carrier * 2) -
ir->cycle_overhead;
- /* make up the the remainer of 4-cycle blocks */
- switch (cycles & 3) {
- case 0:
- sevens = 0;
- break;
- case 1:
- sevens = 3;
- break;
- case 2:
- sevens = 2;
- break;
- case 3:
- sevens = 1;
- break;
- }
-
+ /*
+ * Calculate minimum number of 7 cycles needed so
+ * we are left with a multiple of 4; so we want to have
+ * (sevens * 7) & 3 == cycles & 3
+ */
+ sevens = (4 - cycles) & 3;
fours = (cycles - sevens * 7) / 4;
/* magic happens here */
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (5 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 06/29] iguanair: shut up a gcc " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-04 4:03 ` Ben Hutchings
2013-11-02 13:31 ` [PATCHv2 08/29] cx18: disable compilation on frv arch Mauro Carvalho Chehab
` (21 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, stable
On cris and frv archs, the functions below aren't defined:
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
While this is not fixed, remove those 3 drivers from building on
those archs.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: stable@vger.kernel.org
---
drivers/media/platform/Kconfig | 2 ++
drivers/media/platform/soc_camera/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 3d9beef60325..ab4b22c8ee85 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -205,6 +205,7 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+ depends on !CRIS && !FRV
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
@@ -214,6 +215,7 @@ config VIDEO_SH_VEU
config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on !CRIS && !FRV
select VIDEOBUF2_DMA_CONTIG
---help---
This is a V4L2 driver for the Renesas VSP1 video processing engine.
diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
index af39c4665554..df11f69aeba5 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -47,6 +47,7 @@ config VIDEO_PXA27x
config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) support"
depends on VIDEO_DEV && SOC_CAMERA
+ depends on !CRIS && !FRV
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
---help---
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs
2013-11-02 13:31 ` [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs Mauro Carvalho Chehab
@ 2013-11-04 4:03 ` Ben Hutchings
2013-11-04 11:28 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Ben Hutchings @ 2013-11-04 4:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, stable
[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]
On Sat, 2013-11-02 at 11:31 -0200, Mauro Carvalho Chehab wrote:
> On cris and frv archs, the functions below aren't defined:
> drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
> drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
> drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
> drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
> drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
> drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
> drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
> drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
> drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>
> While this is not fixed, remove those 3 drivers from building on
> those archs.
[...]
Well where does this stop? There will be many other drivers that are
broken if those functions are missing, and there's going to be a lot of
churn if we disable them all and then reenable when the architecture
headers are fixed.
cris selects the generic implementations (CONFIG_GENERIC_IOMAP) but I
think arch/cris/include/asm/io.h is missing
#include <asm-generic/iomap.h>.
frv defines these functions inline in arch/frv/include/asm/io.h so I
don't know what the problem is there.
Ben.
--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs
2013-11-04 4:03 ` Ben Hutchings
@ 2013-11-04 11:28 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-04 11:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab, stable
[-- Attachment #1: Type: text/plain, Size: 5917 bytes --]
Hi Ben,
Em Mon, 04 Nov 2013 04:03:10 +0000
Ben Hutchings <ben@decadent.org.uk> escreveu:
> On Sat, 2013-11-02 at 11:31 -0200, Mauro Carvalho Chehab wrote:
> > On cris and frv archs, the functions below aren't defined:
> > drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
> > drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
> > drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
> > drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
> > drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
> > drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
> > drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
> > drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
> > drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> >
> > While this is not fixed, remove those 3 drivers from building on
> > those archs.
> [...]
>
> Well where does this stop? There will be many other drivers that are
> broken if those functions are missing, and there's going to be a lot of
> churn if we disable them all and then reenable when the architecture
> headers are fixed.
>
> cris selects the generic implementations (CONFIG_GENERIC_IOMAP) but I
> think arch/cris/include/asm/io.h is missing
> #include <asm-generic/iomap.h>.
Thanks for your review!
Yes, adding it is enough to get rid of the errors on cris.
> frv defines these functions inline in arch/frv/include/asm/io.h so I
> don't know what the problem is there.
One of the drivers weren't including <linux/io.h>. Probably, this were
indirectly included on other archs. That's why it failed only on frv.
The enclosed patch should fix for both:
platform drivers: Fix build on cris and frv archs
On cris and frv archs, compilation fails due to the lack of ioread32/iowrite32:
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read':
drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write':
drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read':
drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write':
drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup':
drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop':
drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
On cris, the reason is because asm-generic/iomap.h is not included
on asm/io.h.
On frv, the reason is because linux/io.h is not included on rcar_vin.c.
Fix both issues.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
PS.: I'll split this patch on two separate ones, sending the cris patch
to the arch maintainer, and committing the media patch via my tree.
diff --git a/arch/cris/include/asm/io.h b/arch/cris/include/asm/io.h
index 5d3047e5563b..4353cf239a13 100644
--- a/arch/cris/include/asm/io.h
+++ b/arch/cris/include/asm/io.h
@@ -3,6 +3,7 @@
#include <asm/page.h> /* for __va, __pa */
#include <arch/io.h>
+#include <asm-generic/iomap.h>
#include <linux/kernel.h>
struct cris_io_operations
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c
index b21f777f55e7..ddf648fab63f 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -14,6 +14,7 @@
* option) any later version.
*/
+#include <linux/io.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCHv2 08/29] cx18: disable compilation on frv arch
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (6 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 09/29] radio-si470x-i2c: fix a warning on ia64 Mauro Carvalho Chehab
` (20 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
This driver produces a lot of errors on this arch:
In file included from drivers/media/pci/cx18/cx18-driver.c:26:0:
/drivers/media/pci/cx18/cx18-io.h: In function 'cx18_raw_readl':
drivers/media/pci/cx18/cx18-io.h:40:2: warning: passing argument 1 of '__builtin_read32' discards 'const' qualifier from pointer target type [enabled by default]
arch/frv/include/asm/mb-regs.h:24:15: note: expected 'volatile void *' but argument is of type 'const void *'
...
While this is not fixed, just disable it.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/pci/cx18/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/pci/cx18/Kconfig b/drivers/media/pci/cx18/Kconfig
index c675b83c43a9..10e6bc72c460 100644
--- a/drivers/media/pci/cx18/Kconfig
+++ b/drivers/media/pci/cx18/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_CX18
tristate "Conexant cx23418 MPEG encoder support"
depends on VIDEO_V4L2 && DVB_CORE && PCI && I2C
+ depends on !FRV
select I2C_ALGOBIT
select VIDEOBUF_VMALLOC
depends on RC_CORE
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 09/29] radio-si470x-i2c: fix a warning on ia64
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (7 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 08/29] cx18: disable compilation on frv arch Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 10/29] rc: Fir warnings on m68k arch Mauro Carvalho Chehab
` (19 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
on ia64, those warnings appear:
drivers/media/radio/si470x/radio-si470x-i2c.c:470:12: warning: 'si470x_i2c_suspend' defined but not used [-Wunused-function]
drivers/media/radio/si470x/radio-si470x-i2c.c:487:12: warning: 'si470x_i2c_resume' defined but not used [-Wunused-function]
They're caused because the PM logic uses this define:
#define SET_SYSTEM_SLEEP_PM_OPS()
With is only defined for CONFIG_PM_SLEEP.
So, change the logic there to test for CONFIG_PM_SLEEP, instead of
CONFIG_PM.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c b/drivers/media/radio/si470x/radio-si470x-i2c.c
index e5fc9acd0c4f..2a497c80c77f 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -463,7 +463,7 @@ static int si470x_i2c_remove(struct i2c_client *client)
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
/*
* si470x_i2c_suspend - suspend the device
*/
@@ -509,7 +509,7 @@ static struct i2c_driver si470x_i2c_driver = {
.driver = {
.name = "si470x",
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
.pm = &si470x_i2c_pm,
#endif
},
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 10/29] rc: Fir warnings on m68k arch
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (8 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 09/29] radio-si470x-i2c: fix a warning on ia64 Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch Mauro Carvalho Chehab
` (18 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Fix the following warnings:
drivers/media/rc/fintek-cir.c: In function 'fintek_cr_write':
drivers/media/rc/fintek-cir.c:45:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:46:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_cr_read':
drivers/media/rc/fintek-cir.c:54:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:55:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_enable':
drivers/media/rc/fintek-cir.c:80:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:81:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_disable':
drivers/media/rc/fintek-cir.c:87:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_write':
drivers/media/rc/nuvoton-cir.c:45:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:46:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_read':
drivers/media/rc/nuvoton-cir.c:52:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:53:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_enable':
drivers/media/rc/nuvoton-cir.c:74:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:75:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_disable':
drivers/media/rc/nuvoton-cir.c:81:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_select_logical_dev':
drivers/media/rc/nuvoton-cir.c:91:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:92:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Those are caused because the I/O port is u32, instead of u8.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/rc/fintek-cir.h | 4 ++--
drivers/media/rc/nuvoton-cir.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/fintek-cir.h b/drivers/media/rc/fintek-cir.h
index 82516a1d39b0..b698f3d2ced9 100644
--- a/drivers/media/rc/fintek-cir.h
+++ b/drivers/media/rc/fintek-cir.h
@@ -76,8 +76,8 @@ struct fintek_dev {
} tx;
/* Config register index/data port pair */
- u8 cr_ip;
- u8 cr_dp;
+ u32 cr_ip;
+ u32 cr_dp;
/* hardware I/O settings */
unsigned long cir_addr;
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 7c3674ff5ea2..07e83108df0f 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -84,8 +84,8 @@ struct nvt_dev {
} tx;
/* EFER Config register index/data pair */
- u8 cr_efir;
- u8 cr_efdr;
+ u32 cr_efir;
+ u32 cr_efdr;
/* hardware I/O settings */
unsigned long cir_addr;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (9 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 10/29] rc: Fir warnings on m68k arch Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-04 14:22 ` Laurent Pinchart
2013-11-02 13:31 ` [PATCHv2 12/29] s5h1420: Don't use dynamic static allocation Mauro Carvalho Chehab
` (17 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Laurent Pinchart
On this arch, usec is not unsigned long. So, we need to typecast,
in order to remove those warnings:
drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update':
drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 9 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c: In function 'irq_handler':
drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat]
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/media/usb/uvc/uvc_video.c | 3 ++-
drivers/staging/media/lirc/lirc_serial.c | 9 ++++++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 3394c3432011..899cb6d1c4a4 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -680,7 +680,8 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
stream->dev->name,
sof >> 16, div_u64(((u64)sof & 0xffff) * 1000000LLU, 65536),
y, ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC,
- v4l2_buf->timestamp.tv_sec, v4l2_buf->timestamp.tv_usec,
+ v4l2_buf->timestamp.tv_sec,
+ (unsigned long)v4l2_buf->timestamp.tv_usec,
x1, first->host_sof, first->dev_sof,
x2, last->host_sof, last->dev_sof, y1, y2);
diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c
index af08e677b60f..7b3be2346b4b 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -707,7 +707,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn("ignoring spike: %d %d %lx %lx %lx %lx\n",
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
continue;
}
@@ -719,7 +720,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn("%d %d %lx %lx %lx %lx\n",
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
data = PULSE_MASK;
} else if (deltv > 15) {
data = PULSE_MASK; /* really long time */
@@ -728,7 +730,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn("AIEEEE: %d %d %lx %lx %lx %lx\n",
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
/*
* detecting pulse while this
* MUST be a space!
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch
2013-11-02 13:31 ` [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch Mauro Carvalho Chehab
@ 2013-11-04 14:22 ` Laurent Pinchart
2013-11-04 14:43 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Laurent Pinchart @ 2013-11-04 14:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
Hi Mauro,
Thank you for the patch.
On Saturday 02 November 2013 11:31:19 Mauro Carvalho Chehab wrote:
> On this arch, usec is not unsigned long. So, we need to typecast,
> in order to remove those warnings:
>
> drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update':
> drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects
> argument of type 'long unsigned int', but argument 9 has type
> '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:
> In function 'irq_handler': drivers/staging/media/lirc/lirc_serial.c:707:5:
> warning: format '%lx' expects argument of type 'long unsigned int', but
> argument 6 has type '__kernel_suseconds_t' [-Wformat]
> drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx'
> expects argument of type 'long unsigned int', but argument 7 has type
> '__kernel_suseconds_t' [-Wformat]
> drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
> expects argument of type 'long unsigned int', but argument 6 has type
> '__kernel_suseconds_t' [-Wformat]
> drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
> expects argument of type 'long unsigned int', but argument 7 has type
> '__kernel_suseconds_t' [-Wformat]
> drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
> expects argument of type 'long unsigned int', but argument 6 has type
> '__kernel_suseconds_t' [-Wformat]
> drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
> expects argument of type 'long unsigned int', but argument 7 has type
> '__kernel_suseconds_t' [-Wformat]
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
I don't like this much, but I guess we won't get parisc to switch
__kernel_suseconds from int to unsigned long any time soon. So,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
By the way, what about defining a macro similar to the PRI* macros (from
inttypes.h) for kernel types ? We could then get rid of the cast.
I expect you to apply the patch directly to your tree, please let me know if I
should take it in mine instead.
> ---
> drivers/media/usb/uvc/uvc_video.c | 3 ++-
> drivers/staging/media/lirc/lirc_serial.c | 9 ++++++---
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index 3394c3432011..899cb6d1c4a4 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -680,7 +680,8 @@ void uvc_video_clock_update(struct uvc_streaming
> *stream, stream->dev->name,
> sof >> 16, div_u64(((u64)sof & 0xffff) * 1000000LLU, 65536),
> y, ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC,
> - v4l2_buf->timestamp.tv_sec, v4l2_buf->timestamp.tv_usec,
> + v4l2_buf->timestamp.tv_sec,
> + (unsigned long)v4l2_buf->timestamp.tv_usec,
> x1, first->host_sof, first->dev_sof,
> x2, last->host_sof, last->dev_sof, y1, y2);
>
> diff --git a/drivers/staging/media/lirc/lirc_serial.c
> b/drivers/staging/media/lirc/lirc_serial.c index af08e677b60f..7b3be2346b4b
> 100644
> --- a/drivers/staging/media/lirc/lirc_serial.c
> +++ b/drivers/staging/media/lirc/lirc_serial.c
> @@ -707,7 +707,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> pr_warn("ignoring spike: %d %d %lx %lx %lx %lx\n",
> dcd, sense,
> tv.tv_sec, lasttv.tv_sec,
> - tv.tv_usec, lasttv.tv_usec);
> + (unsigned long)tv.tv_usec,
> + (unsigned long)lasttv.tv_usec);
> continue;
> }
>
> @@ -719,7 +720,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> pr_warn("%d %d %lx %lx %lx %lx\n",
> dcd, sense,
> tv.tv_sec, lasttv.tv_sec,
> - tv.tv_usec, lasttv.tv_usec);
> + (unsigned long)tv.tv_usec,
> + (unsigned long)lasttv.tv_usec);
> data = PULSE_MASK;
> } else if (deltv > 15) {
> data = PULSE_MASK; /* really long time */
> @@ -728,7 +730,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> pr_warn("AIEEEE: %d %d %lx %lx %lx %lx\n",
> dcd, sense,
> tv.tv_sec, lasttv.tv_sec,
> - tv.tv_usec, lasttv.tv_usec);
> + (unsigned long)tv.tv_usec,
> + (unsigned long)lasttv.tv_usec);
> /*
> * detecting pulse while this
> * MUST be a space!
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch
2013-11-04 14:22 ` Laurent Pinchart
@ 2013-11-04 14:43 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-04 14:43 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
Em Mon, 04 Nov 2013 15:22:26 +0100
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Saturday 02 November 2013 11:31:19 Mauro Carvalho Chehab wrote:
> > On this arch, usec is not unsigned long. So, we need to typecast,
> > in order to remove those warnings:
> >
> > drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update':
> > drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects
> > argument of type 'long unsigned int', but argument 9 has type
> > '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:
> > In function 'irq_handler': drivers/staging/media/lirc/lirc_serial.c:707:5:
> > warning: format '%lx' expects argument of type 'long unsigned int', but
> > argument 6 has type '__kernel_suseconds_t' [-Wformat]
> > drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx'
> > expects argument of type 'long unsigned int', but argument 7 has type
> > '__kernel_suseconds_t' [-Wformat]
> > drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
> > expects argument of type 'long unsigned int', but argument 6 has type
> > '__kernel_suseconds_t' [-Wformat]
> > drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
> > expects argument of type 'long unsigned int', but argument 7 has type
> > '__kernel_suseconds_t' [-Wformat]
> > drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
> > expects argument of type 'long unsigned int', but argument 6 has type
> > '__kernel_suseconds_t' [-Wformat]
> > drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
> > expects argument of type 'long unsigned int', but argument 7 has type
> > '__kernel_suseconds_t' [-Wformat]
> >
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I don't like this much, but I guess we won't get parisc to switch
> __kernel_suseconds from int to unsigned long any time soon.
No, I don't think so.
> So,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks!
> By the way, what about defining a macro similar to the PRI* macros (from
> inttypes.h) for kernel types ? We could then get rid of the cast.
Well, the Kernel's way is to define a type-specific printk stuff, like %zd
for size_t.
Personally, I think that the PRI* macros are a dirty hack. Adding
type-specific handlers at print* functions seems more elegant, IMHO,
but such discussions should actually happen at LKML.
In any case, before writing this patch, I double checked if there was
anything like that for __kernel_suseconds_t but it doesn't. The thing
is that there aren't many places inside the kernel where a timestamp
is printed.
So, IMO, a typecast for timestamps cost less than reserving a new
type-specific handler at printk.
> I expect you to apply the patch directly to your tree, please let me know if I
> should take it in mine instead.
Yeah, I'll apply it on my tree. My plan is to have them for 3.13 (they are
already on a separate branch, at -next - although I'll rebase it due to
some comments/acks). So, it will likely be sent on a separate pull request,
after the one containing the other patches.
>
> > ---
> > drivers/media/usb/uvc/uvc_video.c | 3 ++-
> > drivers/staging/media/lirc/lirc_serial.c | 9 ++++++---
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > b/drivers/media/usb/uvc/uvc_video.c index 3394c3432011..899cb6d1c4a4 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -680,7 +680,8 @@ void uvc_video_clock_update(struct uvc_streaming
> > *stream, stream->dev->name,
> > sof >> 16, div_u64(((u64)sof & 0xffff) * 1000000LLU, 65536),
> > y, ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC,
> > - v4l2_buf->timestamp.tv_sec, v4l2_buf->timestamp.tv_usec,
> > + v4l2_buf->timestamp.tv_sec,
> > + (unsigned long)v4l2_buf->timestamp.tv_usec,
> > x1, first->host_sof, first->dev_sof,
> > x2, last->host_sof, last->dev_sof, y1, y2);
> >
> > diff --git a/drivers/staging/media/lirc/lirc_serial.c
> > b/drivers/staging/media/lirc/lirc_serial.c index af08e677b60f..7b3be2346b4b
> > 100644
> > --- a/drivers/staging/media/lirc/lirc_serial.c
> > +++ b/drivers/staging/media/lirc/lirc_serial.c
> > @@ -707,7 +707,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> > pr_warn("ignoring spike: %d %d %lx %lx %lx %lx\n",
> > dcd, sense,
> > tv.tv_sec, lasttv.tv_sec,
> > - tv.tv_usec, lasttv.tv_usec);
> > + (unsigned long)tv.tv_usec,
> > + (unsigned long)lasttv.tv_usec);
> > continue;
> > }
> >
> > @@ -719,7 +720,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> > pr_warn("%d %d %lx %lx %lx %lx\n",
> > dcd, sense,
> > tv.tv_sec, lasttv.tv_sec,
> > - tv.tv_usec, lasttv.tv_usec);
> > + (unsigned long)tv.tv_usec,
> > + (unsigned long)lasttv.tv_usec);
> > data = PULSE_MASK;
> > } else if (deltv > 15) {
> > data = PULSE_MASK; /* really long time */
> > @@ -728,7 +730,8 @@ static irqreturn_t irq_handler(int i, void *blah)
> > pr_warn("AIEEEE: %d %d %lx %lx %lx %lx\n",
> > dcd, sense,
> > tv.tv_sec, lasttv.tv_sec,
> > - tv.tv_usec, lasttv.tv_usec);
> > + (unsigned long)tv.tv_usec,
> > + (unsigned long)lasttv.tv_usec);
> > /*
> > * detecting pulse while this
> > * MUST be a space!
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 12/29] s5h1420: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (10 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 13/29] dvb-frontends: " Mauro Carvalho Chehab
` (16 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Patrick Boettcher
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@samsung.com>
Cc: Patrick Boettcher <pb@linuxtv.org>
---
drivers/media/dvb-frontends/s5h1420.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/s5h1420.c b/drivers/media/dvb-frontends/s5h1420.c
index e2fec9ebf947..e0b0366ccfa5 100644
--- 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 i2c_adapter *adapter)
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 -EREMOTEIO;
+ }
+
memset(m, 0, sizeof(struct i2c_msg) * (1 + num));
m[0].addr = state->config->demod_address;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 13/29] dvb-frontends: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (11 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 12/29] s5h1420: Don't use dynamic static allocation Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 14/29] " Mauro Carvalho Chehab
` (15 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/dvb-frontends/bcm3510.c | 12 +++++++++++-
drivers/media/dvb-frontends/itd1000.c | 10 +++++++++-
drivers/media/dvb-frontends/mt312.c | 8 +++++++-
drivers/media/dvb-frontends/nxt200x.c | 8 +++++++-
drivers/media/dvb-frontends/stb6100.c | 9 ++++++++-
drivers/media/dvb-frontends/stv6110.c | 9 ++++++++-
drivers/media/dvb-frontends/stv6110x.c | 9 ++++++++-
drivers/media/dvb-frontends/tda18271c2dd.c | 11 +++++++++--
drivers/media/dvb-frontends/zl10039.c | 9 ++++++++-
9 files changed, 75 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-frontends/bcm3510.c b/drivers/media/dvb-frontends/bcm3510.c
index 1b77909c0c71..efd8ce671caf 100644
--- a/drivers/media/dvb-frontends/bcm3510.c
+++ b/drivers/media/dvb-frontends/bcm3510.c
@@ -201,9 +201,19 @@ static int bcm3510_hab_send_request(struct bcm3510_state *st, u8 *buf, int len)
static int bcm3510_do_hab_cmd(struct bcm3510_state *st, u8 cmd, u8 msgid, u8 *obuf, u8 olen, u8 *ibuf, u8 ilen)
{
- u8 ob[olen+2],ib[ilen+2];
+ u8 ob[128], ib[128];
int ret = 0;
+ if (ilen + 2 > sizeof(ib)) {
+ deb_hab("do_hab_cmd: ilen=%d is too big!\n", ilen);
+ return -EREMOTEIO;
+ }
+
+ if (olen + 2 > sizeof(ob)) {
+ deb_hab("do_hab_cmd: olen=%d is too big!\n", olen);
+ return -EREMOTEIO;
+ }
+
ob[0] = cmd;
ob[1] = msgid;
memcpy(&ob[2],obuf,olen);
diff --git a/drivers/media/dvb-frontends/itd1000.c b/drivers/media/dvb-frontends/itd1000.c
index c1c3400b2173..1a8e9f83a002 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -52,10 +52,18 @@ MODULE_PARM_DESC(debug, "Turn on/off debugging (default:off).");
/* don't write more than one byte with flexcop behind */
static int itd1000_write_regs(struct itd1000_state *state, u8 reg, u8 v[], u8 len)
{
- u8 buf[1+len];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = state->cfg->i2c_address, .flags = 0, .buf = buf, .len = len+1
};
+
+ if (1 + len > sizeof(buf)) {
+ printk(KERN_WARNING
+ "itd1000: i2c wr reg=%04x: len=%d is too big!\n",
+ reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], v, len);
diff --git a/drivers/media/dvb-frontends/mt312.c b/drivers/media/dvb-frontends/mt312.c
index ec388c1d6913..fee0e7938f48 100644
--- a/drivers/media/dvb-frontends/mt312.c
+++ b/drivers/media/dvb-frontends/mt312.c
@@ -96,9 +96,15 @@ static int mt312_write(struct mt312_state *state, const enum mt312_reg_addr reg,
const u8 *src, const size_t count)
{
int ret;
- u8 buf[count + 1];
+ u8 buf[80];
struct i2c_msg msg;
+ if (1 + count > sizeof(buf)) {
+ printk(KERN_WARNING
+ "mt312: write: len=%zd is too big!\n", count);
+ return -EREMOTEIO;
+ }
+
if (debug) {
int i;
dprintk("W(%d):", reg & 0x7f);
diff --git a/drivers/media/dvb-frontends/nxt200x.c b/drivers/media/dvb-frontends/nxt200x.c
index 8e288940a61f..335b35ce60c8 100644
--- a/drivers/media/dvb-frontends/nxt200x.c
+++ b/drivers/media/dvb-frontends/nxt200x.c
@@ -95,10 +95,16 @@ static int i2c_readbytes(struct nxt200x_state *state, u8 addr, u8 *buf, u8 len)
static int nxt200x_writebytes (struct nxt200x_state* state, u8 reg,
const u8 *buf, u8 len)
{
- u8 buf2 [len+1];
+ u8 buf2[80];
int err;
struct i2c_msg msg = { .addr = state->config->demod_address, .flags = 0, .buf = buf2, .len = len + 1 };
+ if (1 + len > sizeof(buf2)) {
+ pr_warn("%s: i2c wr reg=%04x: len=%d is too big!\n",
+ __func__, reg, len);
+ return -EREMOTEIO;
+ }
+
buf2[0] = reg;
memcpy(&buf2[1], buf, len);
diff --git a/drivers/media/dvb-frontends/stb6100.c b/drivers/media/dvb-frontends/stb6100.c
index 45f9523f968f..5623af5fcdd4 100644
--- a/drivers/media/dvb-frontends/stb6100.c
+++ b/drivers/media/dvb-frontends/stb6100.c
@@ -183,7 +183,7 @@ static int stb6100_read_reg(struct stb6100_state *state, u8 reg)
static int stb6100_write_reg_range(struct stb6100_state *state, u8 buf[], int start, int len)
{
int rc;
- u8 cmdbuf[len + 1];
+ u8 cmdbuf[80];
struct i2c_msg msg = {
.addr = state->config->tuner_address,
.flags = 0,
@@ -191,6 +191,13 @@ static int stb6100_write_reg_range(struct stb6100_state *state, u8 buf[], int st
.len = len + 1
};
+ if (1 + len > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr: len=%d is too big!\n",
+ KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
if (unlikely(start < 1 || start + len > STB6100_NUMREGS)) {
dprintk(verbose, FE_ERROR, 1, "Invalid register range %d:%d",
start, len);
diff --git a/drivers/media/dvb-frontends/stv6110.c b/drivers/media/dvb-frontends/stv6110.c
index 20b5fa92c53e..4bb3f9a1cf2a 100644
--- a/drivers/media/dvb-frontends/stv6110.c
+++ b/drivers/media/dvb-frontends/stv6110.c
@@ -68,7 +68,7 @@ static int stv6110_write_regs(struct dvb_frontend *fe, u8 buf[],
{
struct stv6110_priv *priv = fe->tuner_priv;
int rc;
- u8 cmdbuf[len + 1];
+ u8 cmdbuf[80];
struct i2c_msg msg = {
.addr = priv->i2c_address,
.flags = 0,
@@ -78,6 +78,13 @@ static int stv6110_write_regs(struct dvb_frontend *fe, u8 buf[],
dprintk("%s\n", __func__);
+ if (1 + len > sizeof(cmdbuf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr: len=%d is too big!\n",
+ KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
if (start + len > 8)
return -EINVAL;
diff --git a/drivers/media/dvb-frontends/stv6110x.c b/drivers/media/dvb-frontends/stv6110x.c
index f36cab12bdc7..41f1d34f64ac 100644
--- a/drivers/media/dvb-frontends/stv6110x.c
+++ b/drivers/media/dvb-frontends/stv6110x.c
@@ -61,7 +61,7 @@ static int stv6110x_write_regs(struct stv6110x_state *stv6110x, int start, u8 da
{
int ret;
const struct stv6110x_config *config = stv6110x->config;
- u8 buf[len + 1];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = config->addr,
.flags = 0,
@@ -69,6 +69,13 @@ static int stv6110x_write_regs(struct stv6110x_state *stv6110x, int start, u8 da
.len = len + 1
};
+ if (1 + len > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr: len=%d is too big!\n",
+ KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
if (start + len > 8)
return -EINVAL;
diff --git a/drivers/media/dvb-frontends/tda18271c2dd.c b/drivers/media/dvb-frontends/tda18271c2dd.c
index d281f77d5c28..d3aa82cd4eb7 100644
--- a/drivers/media/dvb-frontends/tda18271c2dd.c
+++ b/drivers/media/dvb-frontends/tda18271c2dd.c
@@ -139,11 +139,18 @@ static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
static int WriteRegs(struct tda_state *state,
u8 SubAddr, u8 *Regs, u16 nRegs)
{
- u8 data[nRegs+1];
+ u8 data[80];
+
+ if (1 + nRegs > sizeof(data)) {
+ printk(KERN_WARNING
+ "%s: i2c wr: len=%d is too big!\n",
+ KBUILD_MODNAME, nRegs);
+ return -EREMOTEIO;
+ }
data[0] = SubAddr;
memcpy(data + 1, Regs, nRegs);
- return i2c_write(state->i2c, state->adr, data, nRegs+1);
+ return i2c_write(state->i2c, state->adr, data, nRegs + 1);
}
static int WriteReg(struct tda_state *state, u8 SubAddr, u8 Reg)
diff --git a/drivers/media/dvb-frontends/zl10039.c b/drivers/media/dvb-frontends/zl10039.c
index eff9c5fde50a..1e2d99b47bc3 100644
--- a/drivers/media/dvb-frontends/zl10039.c
+++ b/drivers/media/dvb-frontends/zl10039.c
@@ -98,7 +98,7 @@ static int zl10039_write(struct zl10039_state *state,
const enum zl10039_reg_addr reg, const u8 *src,
const size_t count)
{
- u8 buf[count + 1];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = state->i2c_addr,
.flags = 0,
@@ -106,6 +106,13 @@ static int zl10039_write(struct zl10039_state *state,
.len = count + 1,
};
+ if (1 + count > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr reg=%04x: len=%zd is too big!\n",
+ KBUILD_MODNAME, reg, count);
+ return -EREMOTEIO;
+ }
+
dprintk("%s\n", __func__);
/* Write register address and data in one go */
buf[0] = reg;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 14/29] dvb-frontends: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (12 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 13/29] dvb-frontends: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 17:10 ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 15/29] stb0899_drv: " Mauro Carvalho Chehab
` (14 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Antti Palosaari
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Antti Palosaari <crope@iki.fi>
---
drivers/media/dvb-frontends/af9013.c | 9 ++++++++-
drivers/media/dvb-frontends/af9033.c | 18 ++++++++++++++++--
drivers/media/dvb-frontends/cxd2820r_core.c | 18 ++++++++++++++++--
drivers/media/dvb-frontends/rtl2830.c | 9 ++++++++-
drivers/media/dvb-frontends/rtl2832.c | 9 ++++++++-
drivers/media/dvb-frontends/tda10071.c | 18 ++++++++++++++++--
6 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9013.c b/drivers/media/dvb-frontends/af9013.c
index a204f2828820..f968dc0e5de9 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -50,7 +50,7 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8 mbox, u16 reg,
const u8 *val, int len)
{
int ret;
- u8 buf[3+len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->config.i2c_addr,
@@ -60,6 +60,13 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8 mbox, u16 reg,
}
};
+ if (3 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg >> 8) & 0xff;
buf[1] = (reg >> 0) & 0xff;
buf[2] = mbox;
diff --git a/drivers/media/dvb-frontends/af9033.c b/drivers/media/dvb-frontends/af9033.c
index a777b4b944eb..efa2efafa97f 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -40,7 +40,7 @@ static int af9033_wr_regs(struct af9033_state *state, u32 reg, const u8 *val,
int len)
{
int ret;
- u8 buf[3 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = state->cfg.i2c_addr,
@@ -50,6 +50,13 @@ static int af9033_wr_regs(struct af9033_state *state, u32 reg, const u8 *val,
}
};
+ if (3 + len > sizeof(buf)) {
+ dev_warn(&state->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg >> 16) & 0xff;
buf[1] = (reg >> 8) & 0xff;
buf[2] = (reg >> 0) & 0xff;
@@ -161,7 +168,14 @@ static int af9033_wr_reg_val_tab(struct af9033_state *state,
const struct reg_val *tab, int tab_len)
{
int ret, i, j;
- u8 buf[tab_len];
+ u8 buf[80];
+
+ if (tab_len > sizeof(buf)) {
+ dev_warn(&state->i2c->dev,
+ "%s: i2c wr len=%d is too big!\n",
+ KBUILD_MODNAME, tab_len);
+ return -EREMOTEIO;
+ }
dev_dbg(&state->i2c->dev, "%s: tab_len=%d\n", __func__, tab_len);
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c b/drivers/media/dvb-frontends/cxd2820r_core.c
index d9eeeb1dfa96..8ef96a96b141 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -26,7 +26,7 @@ static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
u8 *val, int len)
{
int ret;
- u8 buf[len+1];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = i2c,
@@ -36,6 +36,13 @@ static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
@@ -55,7 +62,7 @@ static int cxd2820r_rd_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = i2c,
@@ -70,6 +77,13 @@ static int cxd2820r_rd_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
}
};
+ if (len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/dvb-frontends/rtl2830.c b/drivers/media/dvb-frontends/rtl2830.c
index 362d26d11e82..bd54fd8b3e2d 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -31,7 +31,7 @@
static int rtl2830_wr(struct rtl2830_priv *priv, u8 reg, const u8 *val, int len)
{
int ret;
- u8 buf[1+len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg.i2c_addr,
@@ -41,6 +41,13 @@ static int rtl2830_wr(struct rtl2830_priv *priv, u8 reg, const u8 *val, int len)
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c
index a95dfe0a5ce3..067547fd6ac5 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -162,7 +162,7 @@ static const struct rtl2832_reg_entry registers[] = {
static int rtl2832_wr(struct rtl2832_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1+len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg.i2c_addr,
@@ -172,6 +172,13 @@ static int rtl2832_wr(struct rtl2832_priv *priv, u8 reg, u8 *val, int len)
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
diff --git a/drivers/media/dvb-frontends/tda10071.c b/drivers/media/dvb-frontends/tda10071.c
index e79749cfec81..6f007f55d35d 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -27,7 +27,7 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
int len)
{
int ret;
- u8 buf[len+1];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg.demod_i2c_addr,
@@ -37,6 +37,13 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
@@ -56,7 +63,7 @@ static int tda10071_rd_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv->cfg.demod_i2c_addr,
@@ -71,6 +78,13 @@ static int tda10071_rd_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
}
};
+ if (len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 14/29] dvb-frontends: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 14/29] " Mauro Carvalho Chehab
@ 2013-11-02 17:10 ` Antti Palosaari
0 siblings, 0 replies; 59+ messages in thread
From: Antti Palosaari @ 2013-11-02 17:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer. Considering that I2C
> transfers are generally limited, and that devices used on USB has a
> max data length of 80, it seem safe to use 80 as the hard limit for all
> those devices. On most cases, the limit is a way lower than that, but
> 80 is small enough to not affect the Kernel stack, and it is a no brain
> limit, as using smaller ones would require to either carefully each
> driver or to take a look on each datasheet.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Antti Palosaari <crope@iki.fi>
> ---
> drivers/media/dvb-frontends/af9013.c | 9 ++++++++-
> drivers/media/dvb-frontends/af9033.c | 18 ++++++++++++++++--
> drivers/media/dvb-frontends/cxd2820r_core.c | 18 ++++++++++++++++--
> drivers/media/dvb-frontends/rtl2830.c | 9 ++++++++-
> drivers/media/dvb-frontends/rtl2832.c | 9 ++++++++-
> drivers/media/dvb-frontends/tda10071.c | 18 ++++++++++++++++--
> 6 files changed, 72 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/af9013.c b/drivers/media/dvb-frontends/af9013.c
> index a204f2828820..f968dc0e5de9 100644
> --- a/drivers/media/dvb-frontends/af9013.c
> +++ b/drivers/media/dvb-frontends/af9013.c
> @@ -50,7 +50,7 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8 mbox, u16 reg,
> const u8 *val, int len)
> {
> int ret;
> - u8 buf[3+len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->config.i2c_addr,
> @@ -60,6 +60,13 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8 mbox, u16 reg,
> }
> };
>
> + if (3 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = (reg >> 8) & 0xff;
> buf[1] = (reg >> 0) & 0xff;
> buf[2] = mbox;
> diff --git a/drivers/media/dvb-frontends/af9033.c b/drivers/media/dvb-frontends/af9033.c
> index a777b4b944eb..efa2efafa97f 100644
> --- a/drivers/media/dvb-frontends/af9033.c
> +++ b/drivers/media/dvb-frontends/af9033.c
> @@ -40,7 +40,7 @@ static int af9033_wr_regs(struct af9033_state *state, u32 reg, const u8 *val,
> int len)
> {
> int ret;
> - u8 buf[3 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = state->cfg.i2c_addr,
> @@ -50,6 +50,13 @@ static int af9033_wr_regs(struct af9033_state *state, u32 reg, const u8 *val,
> }
> };
>
> + if (3 + len > sizeof(buf)) {
> + dev_warn(&state->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = (reg >> 16) & 0xff;
> buf[1] = (reg >> 8) & 0xff;
> buf[2] = (reg >> 0) & 0xff;
> @@ -161,7 +168,14 @@ static int af9033_wr_reg_val_tab(struct af9033_state *state,
> const struct reg_val *tab, int tab_len)
> {
> int ret, i, j;
> - u8 buf[tab_len];
> + u8 buf[80];
> +
> + if (tab_len > sizeof(buf)) {
> + dev_warn(&state->i2c->dev,
> + "%s: i2c wr len=%d is too big!\n",
> + KBUILD_MODNAME, tab_len);
> + return -EREMOTEIO;
> + }
>
> dev_dbg(&state->i2c->dev, "%s: tab_len=%d\n", __func__, tab_len);
>
> diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c b/drivers/media/dvb-frontends/cxd2820r_core.c
> index d9eeeb1dfa96..8ef96a96b141 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_core.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
> @@ -26,7 +26,7 @@ static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
> u8 *val, int len)
> {
> int ret;
> - u8 buf[len+1];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = i2c,
> @@ -36,6 +36,13 @@ static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -55,7 +62,7 @@ static int cxd2820r_rd_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
> u8 *val, int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = i2c,
> @@ -70,6 +77,13 @@ static int cxd2820r_rd_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/dvb-frontends/rtl2830.c b/drivers/media/dvb-frontends/rtl2830.c
> index 362d26d11e82..bd54fd8b3e2d 100644
> --- a/drivers/media/dvb-frontends/rtl2830.c
> +++ b/drivers/media/dvb-frontends/rtl2830.c
> @@ -31,7 +31,7 @@
> static int rtl2830_wr(struct rtl2830_priv *priv, u8 reg, const u8 *val, int len)
> {
> int ret;
> - u8 buf[1+len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg.i2c_addr,
> @@ -41,6 +41,13 @@ static int rtl2830_wr(struct rtl2830_priv *priv, u8 reg, const u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c
> index a95dfe0a5ce3..067547fd6ac5 100644
> --- a/drivers/media/dvb-frontends/rtl2832.c
> +++ b/drivers/media/dvb-frontends/rtl2832.c
> @@ -162,7 +162,7 @@ static const struct rtl2832_reg_entry registers[] = {
> static int rtl2832_wr(struct rtl2832_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[1+len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg.i2c_addr,
> @@ -172,6 +172,13 @@ static int rtl2832_wr(struct rtl2832_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> diff --git a/drivers/media/dvb-frontends/tda10071.c b/drivers/media/dvb-frontends/tda10071.c
> index e79749cfec81..6f007f55d35d 100644
> --- a/drivers/media/dvb-frontends/tda10071.c
> +++ b/drivers/media/dvb-frontends/tda10071.c
> @@ -27,7 +27,7 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len+1];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg.demod_i2c_addr,
> @@ -37,6 +37,13 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -56,7 +63,7 @@ static int tda10071_rd_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg.demod_i2c_addr,
> @@ -71,6 +78,13 @@ static int tda10071_rd_regs(struct tda10071_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 15/29] stb0899_drv: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (13 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 14/29] " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 16/29] stv0367: " Mauro Carvalho Chehab
` (13 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Michael Krufky, Zoran Turalija,
Reinhard Nißl
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Michael Krufky <mkrufky@linuxtv.org>
Cc: Zoran Turalija <zoran.turalija@gmail.com>
Cc: "Reinhard Nißl" <rnissl@gmx.de>
---
drivers/media/dvb-frontends/stb0899_drv.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stb0899_drv.c b/drivers/media/dvb-frontends/stb0899_drv.c
index 3dd5714eadba..9df77899b219 100644
--- a/drivers/media/dvb-frontends/stb0899_drv.c
+++ b/drivers/media/dvb-frontends/stb0899_drv.c
@@ -499,7 +499,7 @@ err:
int stb0899_write_regs(struct stb0899_state *state, unsigned int reg, u8 *data, u32 count)
{
int ret;
- u8 buf[2 + count];
+ u8 buf[80];
struct i2c_msg i2c_msg = {
.addr = state->config->demod_address,
.flags = 0,
@@ -507,6 +507,13 @@ int stb0899_write_regs(struct stb0899_state *state, unsigned int reg, u8 *data,
.len = 2 + count
};
+ if (2 + count > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, count);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg >> 8;
buf[1] = reg & 0xff;
memcpy(&buf[2], data, count);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 16/29] stv0367: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (14 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 15/29] stb0899_drv: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 17/29] stv090x: " Mauro Carvalho Chehab
` (12 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Jiri Kosina, Geert Uytterhoeven
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/media/dvb-frontends/stv0367.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 7b6dba3ce55e..28294b3be319 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -767,7 +767,7 @@ static struct st_register def0367cab[STV0367CAB_NBREGS] = {
static
int stv0367_writeregs(struct stv0367_state *state, u16 reg, u8 *data, int len)
{
- u8 buf[len + 2];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = state->config->demod_address,
.flags = 0,
@@ -776,6 +776,14 @@ int stv0367_writeregs(struct stv0367_state *state, u16 reg, u8 *data, int len)
};
int ret;
+ if (2 + len > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
+
buf[0] = MSB(reg);
buf[1] = LSB(reg);
memcpy(buf + 2, data, len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 17/29] stv090x: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (15 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 16/29] stv0367: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 18/29] av7110_hw: " Mauro Carvalho Chehab
` (11 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Manu Abraham, Alexey Khoroshilov,
Andreas Regel
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Manu Abraham <manu@linuxtv.org>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Andreas Regel <andreas.regel@gmx.de>
---
drivers/media/dvb-frontends/stv090x.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stv090x.c b/drivers/media/dvb-frontends/stv090x.c
index 56d470ad5a82..7484b01a9f13 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -722,9 +722,16 @@ static int stv090x_write_regs(struct stv090x_state *state, unsigned int reg, u8
{
const struct stv090x_config *config = state->config;
int ret;
- u8 buf[2 + count];
+ u8 buf[80];
struct i2c_msg i2c_msg = { .addr = config->address, .flags = 0, .buf = buf, .len = 2 + count };
+ if (2 + count > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, count);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg >> 8;
buf[1] = reg & 0xff;
memcpy(&buf[2], data, count);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 18/29] av7110_hw: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (16 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 17/29] stv090x: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 19/29] tuners: " Mauro Carvalho Chehab
` (10 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/ttpci/av7110_hw.c:510:1: warning: 'av7110_fw_cmd' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum fw command size
is 6 + 2, as checked using:
$ git grep -A1 av7110_fw_cmd drivers/media/pci/ttpci/
So, use 8 for the buffer size.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/pci/ttpci/av7110_hw.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/ttpci/av7110_hw.c b/drivers/media/pci/ttpci/av7110_hw.c
index f1cbfe526989..ca6672a29fbc 100644
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -22,7 +22,7 @@
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
* Or, point your browser to http://www.gnu.org/copyleft/gpl.html
*
- * the project's page is at http://www.linuxtv.org/
+ * the project's page is at http://www.linuxtv.org/
*/
/* for debugging ARM communication: */
@@ -488,11 +488,18 @@ static int av7110_send_fw_cmd(struct av7110 *av7110, u16* buf, int length)
int av7110_fw_cmd(struct av7110 *av7110, int type, int com, int num, ...)
{
va_list args;
- u16 buf[num + 2];
+ u16 buf[8];
int i, ret;
// dprintk(4, "%p\n", av7110);
+ if (2 + num > sizeof(buf)) {
+ printk(KERN_WARNING
+ "%s: %s len=%d is too big!\n",
+ KBUILD_MODNAME, __func__, num);
+ return -EREMOTEIO;
+ }
+
buf[0] = ((type << 8) | com);
buf[1] = num;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (17 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 18/29] av7110_hw: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 17:12 ` Antti Palosaari
2013-11-02 17:25 ` Hans Verkuil
2013-11-02 13:31 ` [PATCHv2 20/29] tuner-xc2028: " Mauro Carvalho Chehab
` (9 subsequent siblings)
28 siblings, 2 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Antti Palosaari
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Antti Palosaari <crope@iki.fi>
---
drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg->i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
@@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv->cfg->i2c_addr,
@@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
}
};
+ if (len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c rd reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index 81f38aae9c66..e27bf5be311d 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -41,7 +41,7 @@
static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg->i2c_addr,
@@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
@@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv->cfg->i2c_addr,
@@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
}
};
+ if (len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c rd reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index e4a84ee231cf..765b9f9d4bc6 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -32,7 +32,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
int len)
{
int ret;
- u8 buf[len+1];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg->i2c_address,
@@ -42,6 +42,13 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(&buf[1], val, len);
@@ -61,7 +68,7 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv->cfg->i2c_address,
@@ -76,6 +83,13 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
}
};
+ if (len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c rd reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
index 2d31aeb6b088..e4e662c2e6ef 100644
--- a/drivers/media/tuners/tda18218.c
+++ b/drivers/media/tuners/tda18218.c
@@ -24,7 +24,7 @@
static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
{
int ret = 0, len2, remaining;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv->cfg->i2c_address,
@@ -33,6 +33,13 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
}
};
+ if (1 + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
for (remaining = len; remaining > 0;
remaining -= (priv->cfg->i2c_wr_max - 1)) {
len2 = remaining;
@@ -63,7 +70,7 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
{
int ret;
- u8 buf[reg+len]; /* we must start read always from reg 0x00 */
+ u8 buf[80]; /* we must start read always from reg 0x00 */
struct i2c_msg msg[2] = {
{
.addr = priv->cfg->i2c_address,
@@ -78,6 +85,13 @@ static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
}
};
+ if (reg + len > sizeof(buf)) {
+ dev_warn(&priv->i2c->dev,
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv->i2c, msg, 2);
if (ret == 2) {
memcpy(val, &buf[reg], len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 19/29] tuners: " Mauro Carvalho Chehab
@ 2013-11-02 17:12 ` Antti Palosaari
2013-11-02 17:25 ` Hans Verkuil
1 sibling, 0 replies; 59+ messages in thread
From: Antti Palosaari @ 2013-11-02 17:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer. Considering that I2C
> transfers are generally limited, and that devices used on USB has a
> max data length of 80, it seem safe to use 80 as the hard limit for all
> those devices. On most cases, the limit is a way lower than that, but
> 80 is small enough to not affect the Kernel stack, and it is a no brain
> limit, as using smaller ones would require to either carefully each
> driver or to take a look on each datasheet.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Antti Palosaari <crope@iki.fi>
> ---
> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> 4 files changed, 64 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> index ad9309da4a91..235e90251609 100644
> --- a/drivers/media/tuners/e4000.c
> +++ b/drivers/media/tuners/e4000.c
> @@ -24,7 +24,7 @@
> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> index 81f38aae9c66..e27bf5be311d 100644
> --- a/drivers/media/tuners/fc2580.c
> +++ b/drivers/media/tuners/fc2580.c
> @@ -41,7 +41,7 @@
> static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
> index e4a84ee231cf..765b9f9d4bc6 100644
> --- a/drivers/media/tuners/tda18212.c
> +++ b/drivers/media/tuners/tda18212.c
> @@ -32,7 +32,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len+1];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -42,6 +42,13 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -61,7 +68,7 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -76,6 +83,13 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
> index 2d31aeb6b088..e4e662c2e6ef 100644
> --- a/drivers/media/tuners/tda18218.c
> +++ b/drivers/media/tuners/tda18218.c
> @@ -24,7 +24,7 @@
> static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> {
> int ret = 0, len2, remaining;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -33,6 +33,13 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> for (remaining = len; remaining > 0;
> remaining -= (priv->cfg->i2c_wr_max - 1)) {
> len2 = remaining;
> @@ -63,7 +70,7 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> {
> int ret;
> - u8 buf[reg+len]; /* we must start read always from reg 0x00 */
> + u8 buf[80]; /* we must start read always from reg 0x00 */
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -78,6 +85,13 @@ static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> }
> };
>
> + if (reg + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, &buf[reg], len);
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 19/29] tuners: " Mauro Carvalho Chehab
2013-11-02 17:12 ` Antti Palosaari
@ 2013-11-02 17:25 ` Hans Verkuil
2013-11-02 21:15 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-02 17:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Antti Palosaari
Hi Mauro,
I'll review this series more carefully on Monday, but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer. Considering that I2C
> transfers are generally limited, and that devices used on USB has a
> max data length of 80, it seem safe to use 80 as the hard limit for all
> those devices. On most cases, the limit is a way lower than that, but
> 80 is small enough to not affect the Kernel stack, and it is a no brain
> limit, as using smaller ones would require to either carefully each
> driver or to take a look on each datasheet.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Antti Palosaari <crope@iki.fi>
> ---
> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> 4 files changed, 64 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> index ad9309da4a91..235e90251609 100644
> --- a/drivers/media/tuners/e4000.c
> +++ b/drivers/media/tuners/e4000.c
> @@ -24,7 +24,7 @@
> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
I think this can be greatly simplified to:
if (WARN_ON(len + 1 > sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does. WARN_ON
does the job IMHO. I also don't like the EREMOTEIO error: it has nothing to do with
an I/O problem. Wouldn't EMSGSIZE be much better here?
Ditto for all the similar situations in the patch series.
Regards,
Hans
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> index 81f38aae9c66..e27bf5be311d 100644
> --- a/drivers/media/tuners/fc2580.c
> +++ b/drivers/media/tuners/fc2580.c
> @@ -41,7 +41,7 @@
> static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_addr,
> @@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
> index e4a84ee231cf..765b9f9d4bc6 100644
> --- a/drivers/media/tuners/tda18212.c
> +++ b/drivers/media/tuners/tda18212.c
> @@ -32,7 +32,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len+1];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -42,6 +42,13 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> buf[0] = reg;
> memcpy(&buf[1], val, len);
>
> @@ -61,7 +68,7 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> int len)
> {
> int ret;
> - u8 buf[len];
> + u8 buf[80];
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -76,6 +83,13 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> }
> };
>
> + if (len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, buf, len);
> diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
> index 2d31aeb6b088..e4e662c2e6ef 100644
> --- a/drivers/media/tuners/tda18218.c
> +++ b/drivers/media/tuners/tda18218.c
> @@ -24,7 +24,7 @@
> static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> {
> int ret = 0, len2, remaining;
> - u8 buf[1 + len];
> + u8 buf[80];
> struct i2c_msg msg[1] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -33,6 +33,13 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> }
> };
>
> + if (1 + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> for (remaining = len; remaining > 0;
> remaining -= (priv->cfg->i2c_wr_max - 1)) {
> len2 = remaining;
> @@ -63,7 +70,7 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> {
> int ret;
> - u8 buf[reg+len]; /* we must start read always from reg 0x00 */
> + u8 buf[80]; /* we must start read always from reg 0x00 */
> struct i2c_msg msg[2] = {
> {
> .addr = priv->cfg->i2c_address,
> @@ -78,6 +85,13 @@ static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> }
> };
>
> + if (reg + len > sizeof(buf)) {
> + dev_warn(&priv->i2c->dev,
> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> + KBUILD_MODNAME, reg, len);
> + return -EREMOTEIO;
> + }
> +
> ret = i2c_transfer(priv->i2c, msg, 2);
> if (ret == 2) {
> memcpy(val, &buf[reg], len);
>
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 17:25 ` Hans Verkuil
@ 2013-11-02 21:15 ` Mauro Carvalho Chehab
2013-11-02 21:53 ` Hans Verkuil
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 21:15 UTC (permalink / raw)
To: Hans Verkuil
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Antti Palosaari
Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> Hi Mauro,
>
> I'll review this series more carefully on Monday,
Thanks!
> but for now I want to make
> a suggestion for the array checks:
>
> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> > Dynamic static allocation is evil, as Kernel stack is too low, and
> > compilation complains about it on some archs:
> >
> > drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> > drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >
> > Instead, let's enforce a limit for the buffer. Considering that I2C
> > transfers are generally limited, and that devices used on USB has a
> > max data length of 80, it seem safe to use 80 as the hard limit for all
> > those devices. On most cases, the limit is a way lower than that, but
> > 80 is small enough to not affect the Kernel stack, and it is a no brain
> > limit, as using smaller ones would require to either carefully each
> > driver or to take a look on each datasheet.
> >
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Antti Palosaari <crope@iki.fi>
> > ---
> > drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> > drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> > drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> > drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> > 4 files changed, 64 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> > index ad9309da4a91..235e90251609 100644
> > --- a/drivers/media/tuners/e4000.c
> > +++ b/drivers/media/tuners/e4000.c
> > @@ -24,7 +24,7 @@
> > static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > {
> > int ret;
> > - u8 buf[1 + len];
> > + u8 buf[80];
> > struct i2c_msg msg[1] = {
> > {
> > .addr = priv->cfg->i2c_addr,
> > @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > }
> > };
> >
> > + if (1 + len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
>
> I think this can be greatly simplified to:
>
> if (WARN_ON(len + 1 > sizeof(buf))
> return -EREMOTEIO;
>
> This should really never happen, and it is a clear driver bug if it does. WARN_ON
> does the job IMHO.
Works for me. I'll wait for more comments, and go for it on v3.
> I also don't like the EREMOTEIO error: it has nothing to do with
> an I/O problem. Wouldn't EMSGSIZE be much better here?
EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.
I remember that there's an error code for that on I2C (EOPNOTSUPP?).
In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.
> Ditto for all the similar situations in the patch series.
>
> Regards,
>
> Hans
>
> > buf[0] = reg;
> > memcpy(&buf[1], val, len);
> >
> > @@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > {
> > int ret;
> > - u8 buf[len];
> > + u8 buf[80];
> > struct i2c_msg msg[2] = {
> > {
> > .addr = priv->cfg->i2c_addr,
> > @@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > }
> > };
> >
> > + if (len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > ret = i2c_transfer(priv->i2c, msg, 2);
> > if (ret == 2) {
> > memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> > index 81f38aae9c66..e27bf5be311d 100644
> > --- a/drivers/media/tuners/fc2580.c
> > +++ b/drivers/media/tuners/fc2580.c
> > @@ -41,7 +41,7 @@
> > static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> > {
> > int ret;
> > - u8 buf[1 + len];
> > + u8 buf[80];
> > struct i2c_msg msg[1] = {
> > {
> > .addr = priv->cfg->i2c_addr,
> > @@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> > }
> > };
> >
> > + if (1 + len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > buf[0] = reg;
> > memcpy(&buf[1], val, len);
> >
> > @@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> > static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> > {
> > int ret;
> > - u8 buf[len];
> > + u8 buf[80];
> > struct i2c_msg msg[2] = {
> > {
> > .addr = priv->cfg->i2c_addr,
> > @@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> > }
> > };
> >
> > + if (len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > ret = i2c_transfer(priv->i2c, msg, 2);
> > if (ret == 2) {
> > memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
> > index e4a84ee231cf..765b9f9d4bc6 100644
> > --- a/drivers/media/tuners/tda18212.c
> > +++ b/drivers/media/tuners/tda18212.c
> > @@ -32,7 +32,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> > int len)
> > {
> > int ret;
> > - u8 buf[len+1];
> > + u8 buf[80];
> > struct i2c_msg msg[1] = {
> > {
> > .addr = priv->cfg->i2c_address,
> > @@ -42,6 +42,13 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> > }
> > };
> >
> > + if (1 + len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > buf[0] = reg;
> > memcpy(&buf[1], val, len);
> >
> > @@ -61,7 +68,7 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> > int len)
> > {
> > int ret;
> > - u8 buf[len];
> > + u8 buf[80];
> > struct i2c_msg msg[2] = {
> > {
> > .addr = priv->cfg->i2c_address,
> > @@ -76,6 +83,13 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> > }
> > };
> >
> > + if (len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > ret = i2c_transfer(priv->i2c, msg, 2);
> > if (ret == 2) {
> > memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
> > index 2d31aeb6b088..e4e662c2e6ef 100644
> > --- a/drivers/media/tuners/tda18218.c
> > +++ b/drivers/media/tuners/tda18218.c
> > @@ -24,7 +24,7 @@
> > static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> > {
> > int ret = 0, len2, remaining;
> > - u8 buf[1 + len];
> > + u8 buf[80];
> > struct i2c_msg msg[1] = {
> > {
> > .addr = priv->cfg->i2c_address,
> > @@ -33,6 +33,13 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> > }
> > };
> >
> > + if (1 + len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > for (remaining = len; remaining > 0;
> > remaining -= (priv->cfg->i2c_wr_max - 1)) {
> > len2 = remaining;
> > @@ -63,7 +70,7 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> > static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> > {
> > int ret;
> > - u8 buf[reg+len]; /* we must start read always from reg 0x00 */
> > + u8 buf[80]; /* we must start read always from reg 0x00 */
> > struct i2c_msg msg[2] = {
> > {
> > .addr = priv->cfg->i2c_address,
> > @@ -78,6 +85,13 @@ static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> > }
> > };
> >
> > + if (reg + len > sizeof(buf)) {
> > + dev_warn(&priv->i2c->dev,
> > + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > + KBUILD_MODNAME, reg, len);
> > + return -EREMOTEIO;
> > + }
> > +
> > ret = i2c_transfer(priv->i2c, msg, 2);
> > if (ret == 2) {
> > memcpy(val, &buf[reg], len);
> >
>
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 21:15 ` Mauro Carvalho Chehab
@ 2013-11-02 21:53 ` Hans Verkuil
2013-11-02 21:59 ` Hans Verkuil
0 siblings, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-02 21:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Antti Palosaari
On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 02 Nov 2013 18:25:19 +0100
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> Hi Mauro,
>>
>> I'll review this series more carefully on Monday,
>
> Thanks!
>
>> but for now I want to make
>> a suggestion for the array checks:
>>
>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
>>> Dynamic static allocation is evil, as Kernel stack is too low, and
>>> compilation complains about it on some archs:
>>>
>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>
>>> Instead, let's enforce a limit for the buffer. Considering that I2C
>>> transfers are generally limited, and that devices used on USB has a
>>> max data length of 80, it seem safe to use 80 as the hard limit for all
>>> those devices. On most cases, the limit is a way lower than that, but
>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
>>> limit, as using smaller ones would require to either carefully each
>>> driver or to take a look on each datasheet.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>>> Cc: Antti Palosaari <crope@iki.fi>
>>> ---
>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
>>> 4 files changed, 64 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
>>> index ad9309da4a91..235e90251609 100644
>>> --- a/drivers/media/tuners/e4000.c
>>> +++ b/drivers/media/tuners/e4000.c
>>> @@ -24,7 +24,7 @@
>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>> {
>>> int ret;
>>> - u8 buf[1 + len];
>>> + u8 buf[80];
>>> struct i2c_msg msg[1] = {
>>> {
>>> .addr = priv->cfg->i2c_addr,
>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>> }
>>> };
>>>
>>> + if (1 + len > sizeof(buf)) {
>>> + dev_warn(&priv->i2c->dev,
>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
>>> + KBUILD_MODNAME, reg, len);
>>> + return -EREMOTEIO;
>>> + }
>>> +
>>
>> I think this can be greatly simplified to:
>>
>> if (WARN_ON(len + 1 > sizeof(buf))
>> return -EREMOTEIO;
>>
>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
>> does the job IMHO.
>
> Works for me. I'll wait for more comments, and go for it on v3.
>
>> I also don't like the EREMOTEIO error: it has nothing to do with
>> an I/O problem. Wouldn't EMSGSIZE be much better here?
>
>
> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
> right error code.
>
> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
>
> In any case, I don't think we should use an unusual error code here.
> In theory, this error should never happen, but we don't want to break
> userspace because of it. That's why I opted to use EREMOTEIO: this is
> the error code that most of those drivers return when something gets
> wrong during I2C transfers.
The problem I have is that EREMOTEIO is used when the i2c transfer fails,
i.e. there is some sort of a hardware or communication problem.
That's not the case here, it's an argument error. So EINVAL would actually
be better, but that's perhaps overused which is why I suggested EMSGSIZE.
I personally don't think EIO or EREMOTEIO should be used for something that
is not hardware related. I'm sure there are some gray areas, but this
particular situation is clearly not hardware-related.
So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
ENOMEM is also an option (you are after all 'out of buffer memory').
A bit more exotic, but still sort of in the area, is EPROTO.
Regards,
Hans
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 21:53 ` Hans Verkuil
@ 2013-11-02 21:59 ` Hans Verkuil
2013-11-03 0:21 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-02 21:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Antti Palosaari
On 11/02/2013 10:53 PM, Hans Verkuil wrote:
> On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
>> Em Sat, 02 Nov 2013 18:25:19 +0100
>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>
>>> Hi Mauro,
>>>
>>> I'll review this series more carefully on Monday,
>>
>> Thanks!
>>
>>> but for now I want to make
>>> a suggestion for the array checks:
>>>
>>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
>>>> Dynamic static allocation is evil, as Kernel stack is too low, and
>>>> compilation complains about it on some archs:
>>>>
>>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
>>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>
>>>> Instead, let's enforce a limit for the buffer. Considering that I2C
>>>> transfers are generally limited, and that devices used on USB has a
>>>> max data length of 80, it seem safe to use 80 as the hard limit for all
>>>> those devices. On most cases, the limit is a way lower than that, but
>>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
>>>> limit, as using smaller ones would require to either carefully each
>>>> driver or to take a look on each datasheet.
>>>>
>>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>>>> Cc: Antti Palosaari <crope@iki.fi>
>>>> ---
>>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
>>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
>>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
>>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
>>>> 4 files changed, 64 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
>>>> index ad9309da4a91..235e90251609 100644
>>>> --- a/drivers/media/tuners/e4000.c
>>>> +++ b/drivers/media/tuners/e4000.c
>>>> @@ -24,7 +24,7 @@
>>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>> {
>>>> int ret;
>>>> - u8 buf[1 + len];
>>>> + u8 buf[80];
>>>> struct i2c_msg msg[1] = {
>>>> {
>>>> .addr = priv->cfg->i2c_addr,
>>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>> }
>>>> };
>>>>
>>>> + if (1 + len > sizeof(buf)) {
>>>> + dev_warn(&priv->i2c->dev,
>>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
>>>> + KBUILD_MODNAME, reg, len);
>>>> + return -EREMOTEIO;
>>>> + }
>>>> +
>>>
>>> I think this can be greatly simplified to:
>>>
>>> if (WARN_ON(len + 1 > sizeof(buf))
>>> return -EREMOTEIO;
>>>
>>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
>>> does the job IMHO.
>>
>> Works for me. I'll wait for more comments, and go for it on v3.
>>
>>> I also don't like the EREMOTEIO error: it has nothing to do with
>>> an I/O problem. Wouldn't EMSGSIZE be much better here?
>>
>>
>> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
>> right error code.
>>
>> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
>>
>> In any case, I don't think we should use an unusual error code here.
>> In theory, this error should never happen, but we don't want to break
>> userspace because of it. That's why I opted to use EREMOTEIO: this is
>> the error code that most of those drivers return when something gets
>> wrong during I2C transfers.
>
> The problem I have is that EREMOTEIO is used when the i2c transfer fails,
> i.e. there is some sort of a hardware or communication problem.
>
> That's not the case here, it's an argument error. So EINVAL would actually
> be better, but that's perhaps overused which is why I suggested EMSGSIZE.
> I personally don't think EIO or EREMOTEIO should be used for something that
> is not hardware related. I'm sure there are some gray areas, but this
> particular situation is clearly not hardware-related.
>
> So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
> ENOMEM is also an option (you are after all 'out of buffer memory').
> A bit more exotic, but still sort of in the area, is EPROTO.
After thinking about it a little bit more I would just return -EINVAL. It's
a wrong argument, it's something that shouldn't happen at all, and you get a
big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
Regards,
Hans
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-02 21:59 ` Hans Verkuil
@ 2013-11-03 0:21 ` Mauro Carvalho Chehab
2013-11-03 9:12 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-03 0:21 UTC (permalink / raw)
To: Hans Verkuil
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Antti Palosaari
Em Sat, 02 Nov 2013 22:59:04 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 11/02/2013 10:53 PM, Hans Verkuil wrote:
> > On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
> >> Em Sat, 02 Nov 2013 18:25:19 +0100
> >> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >>
> >>> Hi Mauro,
> >>>
> >>> I'll review this series more carefully on Monday,
> >>
> >> Thanks!
> >>
> >>> but for now I want to make
> >>> a suggestion for the array checks:
> >>>
> >>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> >>>> Dynamic static allocation is evil, as Kernel stack is too low, and
> >>>> compilation complains about it on some archs:
> >>>>
> >>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>>
> >>>> Instead, let's enforce a limit for the buffer. Considering that I2C
> >>>> transfers are generally limited, and that devices used on USB has a
> >>>> max data length of 80, it seem safe to use 80 as the hard limit for all
> >>>> those devices. On most cases, the limit is a way lower than that, but
> >>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
> >>>> limit, as using smaller ones would require to either carefully each
> >>>> driver or to take a look on each datasheet.
> >>>>
> >>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> >>>> Cc: Antti Palosaari <crope@iki.fi>
> >>>> ---
> >>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> >>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> >>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> >>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> >>>> 4 files changed, 64 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> >>>> index ad9309da4a91..235e90251609 100644
> >>>> --- a/drivers/media/tuners/e4000.c
> >>>> +++ b/drivers/media/tuners/e4000.c
> >>>> @@ -24,7 +24,7 @@
> >>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >>>> {
> >>>> int ret;
> >>>> - u8 buf[1 + len];
> >>>> + u8 buf[80];
> >>>> struct i2c_msg msg[1] = {
> >>>> {
> >>>> .addr = priv->cfg->i2c_addr,
> >>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >>>> }
> >>>> };
> >>>>
> >>>> + if (1 + len > sizeof(buf)) {
> >>>> + dev_warn(&priv->i2c->dev,
> >>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> >>>> + KBUILD_MODNAME, reg, len);
> >>>> + return -EREMOTEIO;
> >>>> + }
> >>>> +
> >>>
> >>> I think this can be greatly simplified to:
> >>>
> >>> if (WARN_ON(len + 1 > sizeof(buf))
> >>> return -EREMOTEIO;
> >>>
> >>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
> >>> does the job IMHO.
> >>
> >> Works for me. I'll wait for more comments, and go for it on v3.
> >>
> >>> I also don't like the EREMOTEIO error: it has nothing to do with
> >>> an I/O problem. Wouldn't EMSGSIZE be much better here?
> >>
> >>
> >> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
> >> right error code.
> >>
> >> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
> >>
> >> In any case, I don't think we should use an unusual error code here.
> >> In theory, this error should never happen, but we don't want to break
> >> userspace because of it. That's why I opted to use EREMOTEIO: this is
> >> the error code that most of those drivers return when something gets
> >> wrong during I2C transfers.
> >
> > The problem I have is that EREMOTEIO is used when the i2c transfer fails,
> > i.e. there is some sort of a hardware or communication problem.
> >
> > That's not the case here, it's an argument error. So EINVAL would actually
> > be better, but that's perhaps overused which is why I suggested EMSGSIZE.
> > I personally don't think EIO or EREMOTEIO should be used for something that
> > is not hardware related. I'm sure there are some gray areas, but this
> > particular situation is clearly not hardware-related.
> >
> > So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
> > ENOMEM is also an option (you are after all 'out of buffer memory').
> > A bit more exotic, but still sort of in the area, is EPROTO.
>
> After thinking about it a little bit more I would just return -EINVAL. It's
> a wrong argument, it's something that shouldn't happen at all, and you get a
> big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
Works for me.
Regards,
Mauro
>
> Regards,
>
> Hans
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-03 0:21 ` Mauro Carvalho Chehab
@ 2013-11-03 9:12 ` Mauro Carvalho Chehab
2013-11-03 11:54 ` Antti Palosaari
2013-11-04 13:26 ` Hans Verkuil
0 siblings, 2 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-03 9:12 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Antti Palosaari
Em Sat, 2 Nov 2013 22:21:32 -0200
Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
> Em Sat, 02 Nov 2013 22:59:04 +0100
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
> > On 11/02/2013 10:53 PM, Hans Verkuil wrote:
> > > On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
> > >> Em Sat, 02 Nov 2013 18:25:19 +0100
> > >> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> > >>
> > >>> Hi Mauro,
> > >>>
> > >>> I'll review this series more carefully on Monday,
> > >>
> > >> Thanks!
> > >>
> > >>> but for now I want to make
> > >>> a suggestion for the array checks:
> > >>>
> > >>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> > >>>> Dynamic static allocation is evil, as Kernel stack is too low, and
> > >>>> compilation complains about it on some archs:
> > >>>>
> > >>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> > >>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > >>>>
> > >>>> Instead, let's enforce a limit for the buffer. Considering that I2C
> > >>>> transfers are generally limited, and that devices used on USB has a
> > >>>> max data length of 80, it seem safe to use 80 as the hard limit for all
> > >>>> those devices. On most cases, the limit is a way lower than that, but
> > >>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
> > >>>> limit, as using smaller ones would require to either carefully each
> > >>>> driver or to take a look on each datasheet.
> > >>>>
> > >>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > >>>> Cc: Antti Palosaari <crope@iki.fi>
> > >>>> ---
> > >>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> > >>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> > >>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> > >>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> > >>>> 4 files changed, 64 insertions(+), 8 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> > >>>> index ad9309da4a91..235e90251609 100644
> > >>>> --- a/drivers/media/tuners/e4000.c
> > >>>> +++ b/drivers/media/tuners/e4000.c
> > >>>> @@ -24,7 +24,7 @@
> > >>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > >>>> {
> > >>>> int ret;
> > >>>> - u8 buf[1 + len];
> > >>>> + u8 buf[80];
> > >>>> struct i2c_msg msg[1] = {
> > >>>> {
> > >>>> .addr = priv->cfg->i2c_addr,
> > >>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> > >>>> }
> > >>>> };
> > >>>>
> > >>>> + if (1 + len > sizeof(buf)) {
> > >>>> + dev_warn(&priv->i2c->dev,
> > >>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > >>>> + KBUILD_MODNAME, reg, len);
> > >>>> + return -EREMOTEIO;
> > >>>> + }
> > >>>> +
> > >>>
> > >>> I think this can be greatly simplified to:
> > >>>
> > >>> if (WARN_ON(len + 1 > sizeof(buf))
> > >>> return -EREMOTEIO;
> > >>>
> > >>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
> > >>> does the job IMHO.
> > >>
> > >> Works for me. I'll wait for more comments, and go for it on v3.
> > >>
> > >>> I also don't like the EREMOTEIO error: it has nothing to do with
> > >>> an I/O problem. Wouldn't EMSGSIZE be much better here?
> > >>
> > >>
> > >> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
> > >> right error code.
> > >>
> > >> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
> > >>
> > >> In any case, I don't think we should use an unusual error code here.
> > >> In theory, this error should never happen, but we don't want to break
> > >> userspace because of it. That's why I opted to use EREMOTEIO: this is
> > >> the error code that most of those drivers return when something gets
> > >> wrong during I2C transfers.
> > >
> > > The problem I have is that EREMOTEIO is used when the i2c transfer fails,
> > > i.e. there is some sort of a hardware or communication problem.
> > >
> > > That's not the case here, it's an argument error. So EINVAL would actually
> > > be better, but that's perhaps overused which is why I suggested EMSGSIZE.
> > > I personally don't think EIO or EREMOTEIO should be used for something that
> > > is not hardware related. I'm sure there are some gray areas, but this
> > > particular situation is clearly not hardware-related.
> > >
> > > So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
> > > ENOMEM is also an option (you are after all 'out of buffer memory').
> > > A bit more exotic, but still sort of in the area, is EPROTO.
> >
> > After thinking about it a little bit more I would just return -EINVAL. It's
> > a wrong argument, it's something that shouldn't happen at all, and you get a
> > big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
>
> Works for me.
After thinking a little bit about that, I think that using WARN_ON is not
a good idea.
The thing is that userspace may access directly the I2C devices, via
i2c-dev, and try to read/write using more data than supported. On such cases,
the expected behavior is for the driver to return EOPNOTSUPP without generating
a WARN_ON dump.
So, IMHO, the better is to keep the patches as-is, and just replace the
return code to EOPNOTSUPP, if the size is bigger than supported.
Regards,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-03 9:12 ` Mauro Carvalho Chehab
@ 2013-11-03 11:54 ` Antti Palosaari
2013-11-04 13:26 ` Hans Verkuil
1 sibling, 0 replies; 59+ messages in thread
From: Antti Palosaari @ 2013-11-03 11:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil; +Cc: Linux Media Mailing List
On 03.11.2013 11:12, Mauro Carvalho Chehab wrote:
> Em Sat, 2 Nov 2013 22:21:32 -0200
> Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
>
>> Em Sat, 02 Nov 2013 22:59:04 +0100
>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>
>>> On 11/02/2013 10:53 PM, Hans Verkuil wrote:
>>>> On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
>>>>> Em Sat, 02 Nov 2013 18:25:19 +0100
>>>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>>>
>>>>>> Hi Mauro,
>>>>>>
>>>>>> I'll review this series more carefully on Monday,
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> but for now I want to make
>>>>>> a suggestion for the array checks:
>>>>>>
>>>>>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
>>>>>>> Dynamic static allocation is evil, as Kernel stack is too low, and
>>>>>>> compilation complains about it on some archs:
>>>>>>>
>>>>>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>>
>>>>>>> Instead, let's enforce a limit for the buffer. Considering that I2C
>>>>>>> transfers are generally limited, and that devices used on USB has a
>>>>>>> max data length of 80, it seem safe to use 80 as the hard limit for all
>>>>>>> those devices. On most cases, the limit is a way lower than that, but
>>>>>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
>>>>>>> limit, as using smaller ones would require to either carefully each
>>>>>>> driver or to take a look on each datasheet.
>>>>>>>
>>>>>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>>>>>>> Cc: Antti Palosaari <crope@iki.fi>
>>>>>>> ---
>>>>>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
>>>>>>> 4 files changed, 64 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
>>>>>>> index ad9309da4a91..235e90251609 100644
>>>>>>> --- a/drivers/media/tuners/e4000.c
>>>>>>> +++ b/drivers/media/tuners/e4000.c
>>>>>>> @@ -24,7 +24,7 @@
>>>>>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>>>>> {
>>>>>>> int ret;
>>>>>>> - u8 buf[1 + len];
>>>>>>> + u8 buf[80];
>>>>>>> struct i2c_msg msg[1] = {
>>>>>>> {
>>>>>>> .addr = priv->cfg->i2c_addr,
>>>>>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>>>>> }
>>>>>>> };
>>>>>>>
>>>>>>> + if (1 + len > sizeof(buf)) {
>>>>>>> + dev_warn(&priv->i2c->dev,
>>>>>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
>>>>>>> + KBUILD_MODNAME, reg, len);
>>>>>>> + return -EREMOTEIO;
>>>>>>> + }
>>>>>>> +
>>>>>>
>>>>>> I think this can be greatly simplified to:
>>>>>>
>>>>>> if (WARN_ON(len + 1 > sizeof(buf))
>>>>>> return -EREMOTEIO;
>>>>>>
>>>>>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
>>>>>> does the job IMHO.
>>>>>
>>>>> Works for me. I'll wait for more comments, and go for it on v3.
>>>>>
>>>>>> I also don't like the EREMOTEIO error: it has nothing to do with
>>>>>> an I/O problem. Wouldn't EMSGSIZE be much better here?
>>>>>
>>>>>
>>>>> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
>>>>> right error code.
>>>>>
>>>>> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
>>>>>
>>>>> In any case, I don't think we should use an unusual error code here.
>>>>> In theory, this error should never happen, but we don't want to break
>>>>> userspace because of it. That's why I opted to use EREMOTEIO: this is
>>>>> the error code that most of those drivers return when something gets
>>>>> wrong during I2C transfers.
>>>>
>>>> The problem I have is that EREMOTEIO is used when the i2c transfer fails,
>>>> i.e. there is some sort of a hardware or communication problem.
>>>>
>>>> That's not the case here, it's an argument error. So EINVAL would actually
>>>> be better, but that's perhaps overused which is why I suggested EMSGSIZE.
>>>> I personally don't think EIO or EREMOTEIO should be used for something that
>>>> is not hardware related. I'm sure there are some gray areas, but this
>>>> particular situation is clearly not hardware-related.
>>>>
>>>> So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
>>>> ENOMEM is also an option (you are after all 'out of buffer memory').
>>>> A bit more exotic, but still sort of in the area, is EPROTO.
>>>
>>> After thinking about it a little bit more I would just return -EINVAL. It's
>>> a wrong argument, it's something that shouldn't happen at all, and you get a
>>> big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
>>
>> Works for me.
>
> After thinking a little bit about that, I think that using WARN_ON is not
> a good idea.
>
> The thing is that userspace may access directly the I2C devices, via
> i2c-dev, and try to read/write using more data than supported. On such cases,
> the expected behavior is for the driver to return EOPNOTSUPP without generating
> a WARN_ON dump.
>
> So, IMHO, the better is to keep the patches as-is, and just replace the
> return code to EOPNOTSUPP, if the size is bigger than supported.
There should be checks in every I2C adapter, which returns -EOPNOTSUPP,
when unsupported message is coming. It is another issue. For adapters
EOPNOTSUPP is suitable error code but for client in that case it is not.
If that happens in client it is simply driver bug and I think EINVAL in
suitable.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-03 9:12 ` Mauro Carvalho Chehab
2013-11-03 11:54 ` Antti Palosaari
@ 2013-11-04 13:26 ` Hans Verkuil
2013-11-04 14:24 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-04 13:26 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Antti Palosaari
On 11/03/2013 10:12 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 2 Nov 2013 22:21:32 -0200
> Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
>
>> Em Sat, 02 Nov 2013 22:59:04 +0100
>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>
>>> On 11/02/2013 10:53 PM, Hans Verkuil wrote:
>>>> On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
>>>>> Em Sat, 02 Nov 2013 18:25:19 +0100
>>>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>>>
>>>>>> Hi Mauro,
>>>>>>
>>>>>> I'll review this series more carefully on Monday,
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> but for now I want to make
>>>>>> a suggestion for the array checks:
>>>>>>
>>>>>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
>>>>>>> Dynamic static allocation is evil, as Kernel stack is too low, and
>>>>>>> compilation complains about it on some archs:
>>>>>>>
>>>>>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
>>>>>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
>>>>>>>
>>>>>>> Instead, let's enforce a limit for the buffer. Considering that I2C
>>>>>>> transfers are generally limited, and that devices used on USB has a
>>>>>>> max data length of 80, it seem safe to use 80 as the hard limit for all
>>>>>>> those devices. On most cases, the limit is a way lower than that, but
>>>>>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
>>>>>>> limit, as using smaller ones would require to either carefully each
>>>>>>> driver or to take a look on each datasheet.
>>>>>>>
>>>>>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>>>>>>> Cc: Antti Palosaari <crope@iki.fi>
>>>>>>> ---
>>>>>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
>>>>>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
>>>>>>> 4 files changed, 64 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
>>>>>>> index ad9309da4a91..235e90251609 100644
>>>>>>> --- a/drivers/media/tuners/e4000.c
>>>>>>> +++ b/drivers/media/tuners/e4000.c
>>>>>>> @@ -24,7 +24,7 @@
>>>>>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>>>>> {
>>>>>>> int ret;
>>>>>>> - u8 buf[1 + len];
>>>>>>> + u8 buf[80];
>>>>>>> struct i2c_msg msg[1] = {
>>>>>>> {
>>>>>>> .addr = priv->cfg->i2c_addr,
>>>>>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
>>>>>>> }
>>>>>>> };
>>>>>>>
>>>>>>> + if (1 + len > sizeof(buf)) {
>>>>>>> + dev_warn(&priv->i2c->dev,
>>>>>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
>>>>>>> + KBUILD_MODNAME, reg, len);
>>>>>>> + return -EREMOTEIO;
>>>>>>> + }
>>>>>>> +
>>>>>>
>>>>>> I think this can be greatly simplified to:
>>>>>>
>>>>>> if (WARN_ON(len + 1 > sizeof(buf))
>>>>>> return -EREMOTEIO;
>>>>>>
>>>>>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
>>>>>> does the job IMHO.
>>>>>
>>>>> Works for me. I'll wait for more comments, and go for it on v3.
>>>>>
>>>>>> I also don't like the EREMOTEIO error: it has nothing to do with
>>>>>> an I/O problem. Wouldn't EMSGSIZE be much better here?
>>>>>
>>>>>
>>>>> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
>>>>> right error code.
>>>>>
>>>>> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
>>>>>
>>>>> In any case, I don't think we should use an unusual error code here.
>>>>> In theory, this error should never happen, but we don't want to break
>>>>> userspace because of it. That's why I opted to use EREMOTEIO: this is
>>>>> the error code that most of those drivers return when something gets
>>>>> wrong during I2C transfers.
>>>>
>>>> The problem I have is that EREMOTEIO is used when the i2c transfer fails,
>>>> i.e. there is some sort of a hardware or communication problem.
>>>>
>>>> That's not the case here, it's an argument error. So EINVAL would actually
>>>> be better, but that's perhaps overused which is why I suggested EMSGSIZE.
>>>> I personally don't think EIO or EREMOTEIO should be used for something that
>>>> is not hardware related. I'm sure there are some gray areas, but this
>>>> particular situation is clearly not hardware-related.
>>>>
>>>> So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
>>>> ENOMEM is also an option (you are after all 'out of buffer memory').
>>>> A bit more exotic, but still sort of in the area, is EPROTO.
>>>
>>> After thinking about it a little bit more I would just return -EINVAL. It's
>>> a wrong argument, it's something that shouldn't happen at all, and you get a
>>> big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
>>
>> Works for me.
>
> After thinking a little bit about that, I think that using WARN_ON is not
> a good idea.
>
> The thing is that userspace may access directly the I2C devices, via
> i2c-dev, and try to read/write using more data than supported. On such cases,
> the expected behavior is for the driver to return EOPNOTSUPP without generating
> a WARN_ON dump.
Fair enough. I hadn't thought of that.
> So, IMHO, the better is to keep the patches as-is, and just replace the
> return code to EOPNOTSUPP, if the size is bigger than supported.
I still think that EINVAL is the right error code here.
I also wonder whether you really should print anything if this happens. Looking at
the patch series it adds many such warnings in lots of drivers. I see this as an
exceedingly rare thing, and just returning an error should be sufficient.
In the case of i2c-dev I don't think you want to print anything anyway if the user
provides too much data: it's generally not a good idea to print warnings in the kernel
log in case of incorrect user input.
Regards,
Hans
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
2013-11-04 13:26 ` Hans Verkuil
@ 2013-11-04 14:24 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-04 14:24 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Antti Palosaari
Em Mon, 04 Nov 2013 14:26:33 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 11/03/2013 10:12 AM, Mauro Carvalho Chehab wrote:
> > Em Sat, 2 Nov 2013 22:21:32 -0200
> > Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
> >
> >> Em Sat, 02 Nov 2013 22:59:04 +0100
> >> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >>
> >>> On 11/02/2013 10:53 PM, Hans Verkuil wrote:
> >>>> On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
> >>>>> Em Sat, 02 Nov 2013 18:25:19 +0100
> >>>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >>>>>
> >>>>>> Hi Mauro,
> >>>>>>
> >>>>>> I'll review this series more carefully on Monday,
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>>> but for now I want to make
> >>>>>> a suggestion for the array checks:
> >>>>>>
> >>>>>> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> >>>>>>> Dynamic static allocation is evil, as Kernel stack is too low, and
> >>>>>>> compilation complains about it on some archs:
> >>>>>>>
> >>>>>>> drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> >>>>>>> drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> >>>>>>>
> >>>>>>> Instead, let's enforce a limit for the buffer. Considering that I2C
> >>>>>>> transfers are generally limited, and that devices used on USB has a
> >>>>>>> max data length of 80, it seem safe to use 80 as the hard limit for all
> >>>>>>> those devices. On most cases, the limit is a way lower than that, but
> >>>>>>> 80 is small enough to not affect the Kernel stack, and it is a no brain
> >>>>>>> limit, as using smaller ones would require to either carefully each
> >>>>>>> driver or to take a look on each datasheet.
> >>>>>>>
> >>>>>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> >>>>>>> Cc: Antti Palosaari <crope@iki.fi>
> >>>>>>> ---
> >>>>>>> drivers/media/tuners/e4000.c | 18 ++++++++++++++++--
> >>>>>>> drivers/media/tuners/fc2580.c | 18 ++++++++++++++++--
> >>>>>>> drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> >>>>>>> drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> >>>>>>> 4 files changed, 64 insertions(+), 8 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> >>>>>>> index ad9309da4a91..235e90251609 100644
> >>>>>>> --- a/drivers/media/tuners/e4000.c
> >>>>>>> +++ b/drivers/media/tuners/e4000.c
> >>>>>>> @@ -24,7 +24,7 @@
> >>>>>>> static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >>>>>>> {
> >>>>>>> int ret;
> >>>>>>> - u8 buf[1 + len];
> >>>>>>> + u8 buf[80];
> >>>>>>> struct i2c_msg msg[1] = {
> >>>>>>> {
> >>>>>>> .addr = priv->cfg->i2c_addr,
> >>>>>>> @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >>>>>>> }
> >>>>>>> };
> >>>>>>>
> >>>>>>> + if (1 + len > sizeof(buf)) {
> >>>>>>> + dev_warn(&priv->i2c->dev,
> >>>>>>> + "%s: i2c wr reg=%04x: len=%d is too big!\n",
> >>>>>>> + KBUILD_MODNAME, reg, len);
> >>>>>>> + return -EREMOTEIO;
> >>>>>>> + }
> >>>>>>> +
> >>>>>>
> >>>>>> I think this can be greatly simplified to:
> >>>>>>
> >>>>>> if (WARN_ON(len + 1 > sizeof(buf))
> >>>>>> return -EREMOTEIO;
> >>>>>>
> >>>>>> This should really never happen, and it is a clear driver bug if it does. WARN_ON
> >>>>>> does the job IMHO.
> >>>>>
> >>>>> Works for me. I'll wait for more comments, and go for it on v3.
> >>>>>
> >>>>>> I also don't like the EREMOTEIO error: it has nothing to do with
> >>>>>> an I/O problem. Wouldn't EMSGSIZE be much better here?
> >>>>>
> >>>>>
> >>>>> EMSGSIZE is not used yet at drivers/media. So, it is probably not the
> >>>>> right error code.
> >>>>>
> >>>>> I remember that there's an error code for that on I2C (EOPNOTSUPP?).
> >>>>>
> >>>>> In any case, I don't think we should use an unusual error code here.
> >>>>> In theory, this error should never happen, but we don't want to break
> >>>>> userspace because of it. That's why I opted to use EREMOTEIO: this is
> >>>>> the error code that most of those drivers return when something gets
> >>>>> wrong during I2C transfers.
> >>>>
> >>>> The problem I have is that EREMOTEIO is used when the i2c transfer fails,
> >>>> i.e. there is some sort of a hardware or communication problem.
> >>>>
> >>>> That's not the case here, it's an argument error. So EINVAL would actually
> >>>> be better, but that's perhaps overused which is why I suggested EMSGSIZE.
> >>>> I personally don't think EIO or EREMOTEIO should be used for something that
> >>>> is not hardware related. I'm sure there are some gray areas, but this
> >>>> particular situation is clearly not hardware-related.
> >>>>
> >>>> So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
> >>>> ENOMEM is also an option (you are after all 'out of buffer memory').
> >>>> A bit more exotic, but still sort of in the area, is EPROTO.
> >>>
> >>> After thinking about it a little bit more I would just return -EINVAL. It's
> >>> a wrong argument, it's something that shouldn't happen at all, and you get a
> >>> big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
> >>
> >> Works for me.
> >
> > After thinking a little bit about that, I think that using WARN_ON is not
> > a good idea.
> >
> > The thing is that userspace may access directly the I2C devices, via
> > i2c-dev, and try to read/write using more data than supported. On such cases,
> > the expected behavior is for the driver to return EOPNOTSUPP without generating
> > a WARN_ON dump.
>
> Fair enough. I hadn't thought of that.
>
> > So, IMHO, the better is to keep the patches as-is, and just replace the
> > return code to EOPNOTSUPP, if the size is bigger than supported.
>
> I still think that EINVAL is the right error code here.
Ok. So, I'll use EINVAL for i2c client drivers, and EOPNOTSUPP on bridge
ones.
> I also wonder whether you really should print anything if this happens. Looking at
> the patch series it adds many such warnings in lots of drivers. I see this as an
> exceedingly rare thing, and just returning an error should be sufficient.
Well, eventually, we might be putting a lower limit than needed. As this
printk is rare enough, and it will help a lot on debugging issues at the
driver if it ever happens, I think that the better is to add a printk
here.
> In the case of i2c-dev I don't think you want to print anything anyway if the user
> provides too much data: it's generally not a good idea to print warnings in the kernel
> log in case of incorrect user input.
Agreed, but we can't distinguish if it happened due to i2c-dev or due to a
bridge call. So, I think that having a single printk line (as opposite to
a WARN_ON dump) to be a good compromise.
Regards,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 20/29] tuner-xc2028: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (18 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 19/29] tuners: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 21/29] cimax2: " Mauro Carvalho Chehab
` (8 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum limit is 80, used only
on tm6000 driver. This limit is due to the size of the USB control URBs.
Ok, it would be theoretically possible to use a bigger size on PCI
devices, but the firmware load time is already good enough. Anyway,
if some usage requires more, it is just a matter of also increasing
the buffer size at load_firmware().
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/tuners/tuner-xc2028.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c
index e287a7417319..387934b22a2b 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -547,7 +547,10 @@ static int load_firmware(struct dvb_frontend *fe, unsigned int type,
{
struct xc2028_data *priv = fe->tuner_priv;
int pos, rc;
- unsigned char *p, *endp, buf[priv->ctrl.max_len];
+ unsigned char *p, *endp, buf[80];
+
+ if (priv->ctrl.max_len > sizeof(buf))
+ priv->ctrl.max_len = sizeof(buf);
tuner_dbg("%s called\n", __func__);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 21/29] cimax2: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (19 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 20/29] tuner-xc2028: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 22/29] v4l2-async: " Mauro Carvalho Chehab
` (7 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/cx23885/cimax2.c
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/pci/cx23885/cimax2.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cimax2.c b/drivers/media/pci/cx23885/cimax2.c
index 7344849183a7..e6515f48aa8d 100644
--- a/drivers/media/pci/cx23885/cimax2.c
+++ b/drivers/media/pci/cx23885/cimax2.c
@@ -125,7 +125,7 @@ static int netup_write_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
u8 *buf, int len)
{
int ret;
- u8 buffer[len + 1];
+ u8 buffer[80];
struct i2c_msg msg = {
.addr = addr,
@@ -134,6 +134,13 @@ static int netup_write_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
.len = len + 1
};
+ if (1 + len > sizeof(buffer)) {
+ printk(KERN_WARNING
+ "%s: i2c wr reg=%04x: len=%d is too big!\n",
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buffer[0] = reg;
memcpy(&buffer[1], buf, len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (20 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 21/29] cimax2: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-04 13:15 ` Hans Verkuil
2013-11-02 13:31 ` [PATCHv2 23/29] cxusb: " Mauro Carvalho Chehab
` (6 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
with is currently 128. That means that the buffer size can be up to
128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
Worse than that, someone could increase it and cause real troubles.
So, let's use dynamically allocated data, instead.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/media/v4l2-core/v4l2-async.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index c85d69da35bd..071596869036 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
struct v4l2_subdev *sd, *tmp;
unsigned int notif_n_subdev = notifier->num_subdevs;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
- struct device *dev[n_subdev];
+ struct device **dev;
int i = 0;
if (!notifier->v4l2_dev)
return;
+ dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
+
mutex_lock(&list_lock);
list_del(¬ifier->list);
@@ -228,6 +230,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
}
put_device(d);
}
+ kfree(dev);
notifier->v4l2_dev = NULL;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 22/29] v4l2-async: " Mauro Carvalho Chehab
@ 2013-11-04 13:15 ` Hans Verkuil
2013-11-05 11:36 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-04 13:15 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer.
>
> In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
> with is currently 128. That means that the buffer size can be up to
> 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
>
> Worse than that, someone could increase it and cause real troubles.
>
> So, let's use dynamically allocated data, instead.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> drivers/media/v4l2-core/v4l2-async.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> index c85d69da35bd..071596869036 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> struct v4l2_subdev *sd, *tmp;
> unsigned int notif_n_subdev = notifier->num_subdevs;
> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> - struct device *dev[n_subdev];
> + struct device **dev;
> int i = 0;
>
> if (!notifier->v4l2_dev)
> return;
>
> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> +
No check for dev == NULL?
Regards,
Hans
> mutex_lock(&list_lock);
>
> list_del(¬ifier->list);
> @@ -228,6 +230,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> }
> put_device(d);
> }
> + kfree(dev);
>
> notifier->v4l2_dev = NULL;
>
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-04 13:15 ` Hans Verkuil
@ 2013-11-05 11:36 ` Mauro Carvalho Chehab
2013-11-05 11:42 ` Sylwester Nawrocki
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-05 11:36 UTC (permalink / raw)
To: Hans Verkuil
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski
Em Mon, 04 Nov 2013 14:15:04 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> > Dynamic static allocation is evil, as Kernel stack is too low, and
> > compilation complains about it on some archs:
> >
> > drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
> >
> > Instead, let's enforce a limit for the buffer.
> >
> > In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
> > with is currently 128. That means that the buffer size can be up to
> > 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
> >
> > Worse than that, someone could increase it and cause real troubles.
> >
> > So, let's use dynamically allocated data, instead.
> >
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> > drivers/media/v4l2-core/v4l2-async.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > index c85d69da35bd..071596869036 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> > struct v4l2_subdev *sd, *tmp;
> > unsigned int notif_n_subdev = notifier->num_subdevs;
> > unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> > - struct device *dev[n_subdev];
> > + struct device **dev;
> > int i = 0;
> >
> > if (!notifier->v4l2_dev)
> > return;
> >
> > + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> > +
>
> No check for dev == NULL?
Well, what should be done in this case?
We could do the changes below:
void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
{
struct v4l2_subdev *sd, *tmp;
unsigned int notif_n_subdev = notifier->num_subdevs;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
- struct device *dev[n_subdev];
+ struct device **dev;
int i = 0;
if (!notifier->v4l2_dev)
return;
+ dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
+ if (!dev) {
+ WARN_ON(true);
+ return;
+ }
+
mutex_lock(&list_lock);
list_del(¬ifier->list);
list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
dev[i] = get_device(sd->dev);
v4l2_async_cleanup(sd);
/* If we handled USB devices, we'd have to lock the parent too */
device_release_driver(dev[i++]);
if (notifier->unbind)
notifier->unbind(notifier, sd, sd->asd);
}
mutex_unlock(&list_lock);
while (i--) {
struct device *d = dev[i];
if (d && device_attach(d) < 0) {
const char *name = "(none)";
int lock = device_trylock(d);
if (lock && d->driver)
name = d->driver->name;
dev_err(d, "Failed to re-probe to %s\n", name);
if (lock)
device_unlock(d);
}
put_device(d);
}
+ kfree(dev);
notifier->v4l2_dev = NULL;
/*
* Don't care about the waiting list, it is initialised and populated
* upon notifier registration.
*/
}
EXPORT_SYMBOL(v4l2_async_notifier_unregister);
But I suspect that this will cause an OOPS anyway, as the device will be
only half-removed. So, it would likely OOPS at device removal or if the
device got probed again, at probing time.
So, IMHO, we should have at least a WARN_ON() for this case.
Do you have a better idea?
Regards,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-05 11:36 ` Mauro Carvalho Chehab
@ 2013-11-05 11:42 ` Sylwester Nawrocki
2013-11-05 12:03 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Sylwester Nawrocki @ 2013-11-05 11:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski
On 05/11/13 12:36, Mauro Carvalho Chehab wrote:
>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
>>> > > index c85d69da35bd..071596869036 100644
>>> > > --- a/drivers/media/v4l2-core/v4l2-async.c
>>> > > +++ b/drivers/media/v4l2-core/v4l2-async.c
>>> > > @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>>> > > struct v4l2_subdev *sd, *tmp;
>>> > > unsigned int notif_n_subdev = notifier->num_subdevs;
>>> > > unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
>>> > > - struct device *dev[n_subdev];
>>> > > + struct device **dev;
>>> > > int i = 0;
>>> > >
>>> > > if (!notifier->v4l2_dev)
>>> > > return;
>>> > >
>>> > > + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
>>> > > +
>> >
>> > No check for dev == NULL?
> Well, what should be done in this case?
>
> We could do the changes below:
>
> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> {
> struct v4l2_subdev *sd, *tmp;
> unsigned int notif_n_subdev = notifier->num_subdevs;
> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> - struct device *dev[n_subdev];
> + struct device **dev;
> int i = 0;
>
> if (!notifier->v4l2_dev)
> return;
>
> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> + if (!dev) {
> + WARN_ON(true);
> + return;
> + }
> +
> mutex_lock(&list_lock);
>
> list_del(¬ifier->list);
>
> list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
> dev[i] = get_device(sd->dev);
>
> v4l2_async_cleanup(sd);
>
> /* If we handled USB devices, we'd have to lock the parent too */
> device_release_driver(dev[i++]);
>
> if (notifier->unbind)
> notifier->unbind(notifier, sd, sd->asd);
> }
>
> mutex_unlock(&list_lock);
>
> while (i--) {
> struct device *d = dev[i];
>
> if (d && device_attach(d) < 0) {
> const char *name = "(none)";
> int lock = device_trylock(d);
>
> if (lock && d->driver)
> name = d->driver->name;
> dev_err(d, "Failed to re-probe to %s\n", name);
> if (lock)
> device_unlock(d);
> }
> put_device(d);
> }
> + kfree(dev);
>
> notifier->v4l2_dev = NULL;
>
> /*
> * Don't care about the waiting list, it is initialised and populated
> * upon notifier registration.
> */
> }
> EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>
> But I suspect that this will cause an OOPS anyway, as the device will be
> only half-removed. So, it would likely OOPS at device removal or if the
> device got probed again, at probing time.
>
> So, IMHO, we should have at least a WARN_ON() for this case.
>
> Do you have a better idea?
This is how Guennadi's patch looked like when it used dynamic allocation:
http://www.spinics.net/lists/linux-sh/msg18194.html
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-05 11:42 ` Sylwester Nawrocki
@ 2013-11-05 12:03 ` Mauro Carvalho Chehab
2013-11-05 12:35 ` Hans Verkuil
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-05 12:03 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski
Em Tue, 05 Nov 2013 12:42:23 +0100
Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:
> On 05/11/13 12:36, Mauro Carvalho Chehab wrote:
> >>> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> >>> > > index c85d69da35bd..071596869036 100644
> >>> > > --- a/drivers/media/v4l2-core/v4l2-async.c
> >>> > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> >>> > > @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> >>> > > struct v4l2_subdev *sd, *tmp;
> >>> > > unsigned int notif_n_subdev = notifier->num_subdevs;
> >>> > > unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> >>> > > - struct device *dev[n_subdev];
> >>> > > + struct device **dev;
> >>> > > int i = 0;
> >>> > >
> >>> > > if (!notifier->v4l2_dev)
> >>> > > return;
> >>> > >
> >>> > > + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> >>> > > +
> >> >
> >> > No check for dev == NULL?
> > Well, what should be done in this case?
> >
> > We could do the changes below:
> >
> > void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> > {
> > struct v4l2_subdev *sd, *tmp;
> > unsigned int notif_n_subdev = notifier->num_subdevs;
> > unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> > - struct device *dev[n_subdev];
> > + struct device **dev;
> > int i = 0;
> >
> > if (!notifier->v4l2_dev)
> > return;
> >
> > + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> > + if (!dev) {
> > + WARN_ON(true);
> > + return;
> > + }
> > +
> > mutex_lock(&list_lock);
> >
> > list_del(¬ifier->list);
> >
> > list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
> > dev[i] = get_device(sd->dev);
> >
> > v4l2_async_cleanup(sd);
> >
> > /* If we handled USB devices, we'd have to lock the parent too */
> > device_release_driver(dev[i++]);
> >
> > if (notifier->unbind)
> > notifier->unbind(notifier, sd, sd->asd);
> > }
> >
> > mutex_unlock(&list_lock);
> >
> > while (i--) {
> > struct device *d = dev[i];
> >
> > if (d && device_attach(d) < 0) {
> > const char *name = "(none)";
> > int lock = device_trylock(d);
> >
> > if (lock && d->driver)
> > name = d->driver->name;
> > dev_err(d, "Failed to re-probe to %s\n", name);
> > if (lock)
> > device_unlock(d);
> > }
> > put_device(d);
> > }
> > + kfree(dev);
> >
> > notifier->v4l2_dev = NULL;
> >
> > /*
> > * Don't care about the waiting list, it is initialised and populated
> > * upon notifier registration.
> > */
> > }
> > EXPORT_SYMBOL(v4l2_async_notifier_unregister);
> >
> > But I suspect that this will cause an OOPS anyway, as the device will be
> > only half-removed. So, it would likely OOPS at device removal or if the
> > device got probed again, at probing time.
> >
> > So, IMHO, we should have at least a WARN_ON() for this case.
> >
> > Do you have a better idea?
>
> This is how Guennadi's patch looked like when it used dynamic allocation:
>
> http://www.spinics.net/lists/linux-sh/msg18194.html
Thanks for the tip!
The following patch should do the trick (generated with -U10, in order
to show the entire function):
[PATCHv3] v4l2-async: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
with is currently 128. That means that the buffer size can be up to
128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
Worse than that, someone could increase it and cause real troubles.
So, let's use dynamically allocated data, instead.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index c85d69da35bd..b56c9f300ecb 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -182,59 +182,84 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
return 0;
}
EXPORT_SYMBOL(v4l2_async_notifier_register);
void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
{
struct v4l2_subdev *sd, *tmp;
unsigned int notif_n_subdev = notifier->num_subdevs;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
- struct device *dev[n_subdev];
+ struct device **dev;
int i = 0;
if (!notifier->v4l2_dev)
return;
+ dev = kmalloc(n_subdev * sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(notifier->v4l2_dev->dev,
+ "Failed to allocate device cache!\n");
+ }
+
mutex_lock(&list_lock);
list_del(¬ifier->list);
list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
- dev[i] = get_device(sd->dev);
+ struct device *d;
+
+ d = get_device(sd->dev);
v4l2_async_cleanup(sd);
/* If we handled USB devices, we'd have to lock the parent too */
- device_release_driver(dev[i++]);
+ device_release_driver(d);
+
+
+ /*
+ * Store device at the device cache, in order to call
+ * put_device() on the final step
+ */
+ if (dev)
+ dev[i++] = d;
+ else
+ put_device(d);
if (notifier->unbind)
notifier->unbind(notifier, sd, sd->asd);
}
mutex_unlock(&list_lock);
+ /*
+ * Call device_attach() to reprobe devices
+ *
+ * NOTE: If dev allocation fails, i is 0, and the hole loop won't be
+ * executed.
+ */
while (i--) {
struct device *d = dev[i];
if (d && device_attach(d) < 0) {
const char *name = "(none)";
int lock = device_trylock(d);
if (lock && d->driver)
name = d->driver->name;
dev_err(d, "Failed to re-probe to %s\n", name);
if (lock)
device_unlock(d);
}
put_device(d);
}
+ kfree(dev);
notifier->v4l2_dev = NULL;
/*
* Don't care about the waiting list, it is initialised and populated
* upon notifier registration.
*/
}
EXPORT_SYMBOL(v4l2_async_notifier_unregister);
Regards,
Mauro
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-05 12:03 ` Mauro Carvalho Chehab
@ 2013-11-05 12:35 ` Hans Verkuil
2013-11-05 13:16 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Hans Verkuil @ 2013-11-05 12:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sylwester Nawrocki, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski
On 11/05/13 13:03, Mauro Carvalho Chehab wrote:
> Em Tue, 05 Nov 2013 12:42:23 +0100
> Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:
>
>> On 05/11/13 12:36, Mauro Carvalho Chehab wrote:
>>>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
>>>>>>> index c85d69da35bd..071596869036 100644
>>>>>>> --- a/drivers/media/v4l2-core/v4l2-async.c
>>>>>>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>>>>>>> @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>>>>>>> struct v4l2_subdev *sd, *tmp;
>>>>>>> unsigned int notif_n_subdev = notifier->num_subdevs;
>>>>>>> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
>>>>>>> - struct device *dev[n_subdev];
>>>>>>> + struct device **dev;
>>>>>>> int i = 0;
>>>>>>>
>>>>>>> if (!notifier->v4l2_dev)
>>>>>>> return;
>>>>>>>
>>>>>>> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
>>>>>>> +
>>>>>
>>>>> No check for dev == NULL?
>>> Well, what should be done in this case?
>>>
>>> We could do the changes below:
>>>
>>> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
>>> {
>>> struct v4l2_subdev *sd, *tmp;
>>> unsigned int notif_n_subdev = notifier->num_subdevs;
>>> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
>>> - struct device *dev[n_subdev];
>>> + struct device **dev;
>>> int i = 0;
>>>
>>> if (!notifier->v4l2_dev)
>>> return;
>>>
>>> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
>>> + if (!dev) {
>>> + WARN_ON(true);
>>> + return;
>>> + }
>>> +
>>> mutex_lock(&list_lock);
>>>
>>> list_del(¬ifier->list);
>>>
>>> list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
>>> dev[i] = get_device(sd->dev);
>>>
>>> v4l2_async_cleanup(sd);
>>>
>>> /* If we handled USB devices, we'd have to lock the parent too */
>>> device_release_driver(dev[i++]);
>>>
>>> if (notifier->unbind)
>>> notifier->unbind(notifier, sd, sd->asd);
>>> }
>>>
>>> mutex_unlock(&list_lock);
>>>
>>> while (i--) {
>>> struct device *d = dev[i];
>>>
>>> if (d && device_attach(d) < 0) {
>>> const char *name = "(none)";
>>> int lock = device_trylock(d);
>>>
>>> if (lock && d->driver)
>>> name = d->driver->name;
>>> dev_err(d, "Failed to re-probe to %s\n", name);
>>> if (lock)
>>> device_unlock(d);
>>> }
>>> put_device(d);
>>> }
>>> + kfree(dev);
>>>
>>> notifier->v4l2_dev = NULL;
>>>
>>> /*
>>> * Don't care about the waiting list, it is initialised and populated
>>> * upon notifier registration.
>>> */
>>> }
>>> EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>>>
>>> But I suspect that this will cause an OOPS anyway, as the device will be
>>> only half-removed. So, it would likely OOPS at device removal or if the
>>> device got probed again, at probing time.
>>>
>>> So, IMHO, we should have at least a WARN_ON() for this case.
>>>
>>> Do you have a better idea?
>>
>> This is how Guennadi's patch looked like when it used dynamic allocation:
>>
>> http://www.spinics.net/lists/linux-sh/msg18194.html
>
> Thanks for the tip!
>
> The following patch should do the trick (generated with -U10, in order
> to show the entire function):
>
> [PATCHv3] v4l2-async: Don't use dynamic static allocation
>
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer.
>
> In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
> with is currently 128. That means that the buffer size can be up to
> 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
>
> Worse than that, someone could increase it and cause real troubles.
>
> So, let's use dynamically allocated data, instead.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> index c85d69da35bd..b56c9f300ecb 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -182,59 +182,84 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
>
> return 0;
> }
> EXPORT_SYMBOL(v4l2_async_notifier_register);
>
> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> {
> struct v4l2_subdev *sd, *tmp;
> unsigned int notif_n_subdev = notifier->num_subdevs;
> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> - struct device *dev[n_subdev];
> + struct device **dev;
> int i = 0;
>
> if (!notifier->v4l2_dev)
> return;
>
> + dev = kmalloc(n_subdev * sizeof(*dev), GFP_KERNEL);
> + if (!dev) {
> + dev_err(notifier->v4l2_dev->dev,
> + "Failed to allocate device cache!\n");
> + }
> +
> mutex_lock(&list_lock);
>
> list_del(¬ifier->list);
>
> list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
> - dev[i] = get_device(sd->dev);
> + struct device *d;
> +
> + d = get_device(sd->dev);
I would combine these two lines in one, but that's just me :-)
>
> v4l2_async_cleanup(sd);
>
> /* If we handled USB devices, we'd have to lock the parent too */
> - device_release_driver(dev[i++]);
> + device_release_driver(d);
> +
> +
> + /*
> + * Store device at the device cache, in order to call
> + * put_device() on the final step
> + */
> + if (dev)
> + dev[i++] = d;
> + else
> + put_device(d);
Shouldn't the put_device be moved to after the unbind? It certainly would
'feel' safer that way...
>
> if (notifier->unbind)
> notifier->unbind(notifier, sd, sd->asd);
> }
>
> mutex_unlock(&list_lock);
>
> + /*
> + * Call device_attach() to reprobe devices
> + *
> + * NOTE: If dev allocation fails, i is 0, and the hole loop won't be
Typo: hole -> whole
> + * executed.
> + */
> while (i--) {
> struct device *d = dev[i];
>
> if (d && device_attach(d) < 0) {
> const char *name = "(none)";
> int lock = device_trylock(d);
>
> if (lock && d->driver)
> name = d->driver->name;
> dev_err(d, "Failed to re-probe to %s\n", name);
> if (lock)
> device_unlock(d);
> }
> put_device(d);
> }
> + kfree(dev);
>
> notifier->v4l2_dev = NULL;
>
> /*
> * Don't care about the waiting list, it is initialised and populated
> * upon notifier registration.
> */
> }
> EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>
> Regards,
> Mauro
>
Regards,
Hans
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
2013-11-05 12:35 ` Hans Verkuil
@ 2013-11-05 13:16 ` Mauro Carvalho Chehab
2013-11-05 14:18 ` Hans Verkuil
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-05 13:16 UTC (permalink / raw)
To: Hans Verkuil
Cc: Sylwester Nawrocki, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski
Em Tue, 05 Nov 2013 13:35:49 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 11/05/13 13:03, Mauro Carvalho Chehab wrote:
> > Em Tue, 05 Nov 2013 12:42:23 +0100
> > Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:
> >
> >> On 05/11/13 12:36, Mauro Carvalho Chehab wrote:
> >>>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> >>>>>>> index c85d69da35bd..071596869036 100644
> >>>>>>> --- a/drivers/media/v4l2-core/v4l2-async.c
> >>>>>>> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >>>>>>> @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> >>>>>>> struct v4l2_subdev *sd, *tmp;
> >>>>>>> unsigned int notif_n_subdev = notifier->num_subdevs;
> >>>>>>> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> >>>>>>> - struct device *dev[n_subdev];
> >>>>>>> + struct device **dev;
> >>>>>>> int i = 0;
> >>>>>>>
> >>>>>>> if (!notifier->v4l2_dev)
> >>>>>>> return;
> >>>>>>>
> >>>>>>> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> >>>>>>> +
> >>>>>
> >>>>> No check for dev == NULL?
> >>> Well, what should be done in this case?
> >>>
> >>> We could do the changes below:
> >>>
> >>> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> >>> {
> >>> struct v4l2_subdev *sd, *tmp;
> >>> unsigned int notif_n_subdev = notifier->num_subdevs;
> >>> unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> >>> - struct device *dev[n_subdev];
> >>> + struct device **dev;
> >>> int i = 0;
> >>>
> >>> if (!notifier->v4l2_dev)
> >>> return;
> >>>
> >>> + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL);
> >>> + if (!dev) {
> >>> + WARN_ON(true);
> >>> + return;
> >>> + }
> >>> +
> >>> mutex_lock(&list_lock);
> >>>
> >>> list_del(¬ifier->list);
> >>>
> >>> list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
> >>> dev[i] = get_device(sd->dev);
> >>>
> >>> v4l2_async_cleanup(sd);
> >>>
> >>> /* If we handled USB devices, we'd have to lock the parent too */
> >>> device_release_driver(dev[i++]);
> >>>
> >>> if (notifier->unbind)
> >>> notifier->unbind(notifier, sd, sd->asd);
> >>> }
> >>>
> >>> mutex_unlock(&list_lock);
> >>>
> >>> while (i--) {
> >>> struct device *d = dev[i];
> >>>
> >>> if (d && device_attach(d) < 0) {
> >>> const char *name = "(none)";
> >>> int lock = device_trylock(d);
> >>>
> >>> if (lock && d->driver)
> >>> name = d->driver->name;
> >>> dev_err(d, "Failed to re-probe to %s\n", name);
> >>> if (lock)
> >>> device_unlock(d);
> >>> }
> >>> put_device(d);
> >>> }
> >>> + kfree(dev);
> >>>
> >>> notifier->v4l2_dev = NULL;
> >>>
> >>> /*
> >>> * Don't care about the waiting list, it is initialised and populated
> >>> * upon notifier registration.
> >>> */
> >>> }
> >>> EXPORT_SYMBOL(v4l2_async_notifier_unregister);
> >>>
> >>> But I suspect that this will cause an OOPS anyway, as the device will be
> >>> only half-removed. So, it would likely OOPS at device removal or if the
> >>> device got probed again, at probing time.
> >>>
> >>> So, IMHO, we should have at least a WARN_ON() for this case.
> >>>
> >>> Do you have a better idea?
> >>
> >> This is how Guennadi's patch looked like when it used dynamic allocation:
> >>
> >> http://www.spinics.net/lists/linux-sh/msg18194.html
> >
> > Thanks for the tip!
> >
> > The following patch should do the trick (generated with -U10, in order
> > to show the entire function):
> >
> > [PATCHv3] v4l2-async: Don't use dynamic static allocation
> >
> > Dynamic static allocation is evil, as Kernel stack is too low, and
> > compilation complains about it on some archs:
> >
> > drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
> >
> > Instead, let's enforce a limit for the buffer.
> >
> > In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
> > with is currently 128. That means that the buffer size can be up to
> > 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
> >
> > Worse than that, someone could increase it and cause real troubles.
> >
> > So, let's use dynamically allocated data, instead.
> >
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > index c85d69da35bd..b56c9f300ecb 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -182,59 +182,84 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
> >
> > return 0;
> > }
> > EXPORT_SYMBOL(v4l2_async_notifier_register);
> >
> > void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
> > {
> > struct v4l2_subdev *sd, *tmp;
> > unsigned int notif_n_subdev = notifier->num_subdevs;
> > unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
> > - struct device *dev[n_subdev];
> > + struct device **dev;
> > int i = 0;
> >
> > if (!notifier->v4l2_dev)
> > return;
> >
> > + dev = kmalloc(n_subdev * sizeof(*dev), GFP_KERNEL);
> > + if (!dev) {
> > + dev_err(notifier->v4l2_dev->dev,
> > + "Failed to allocate device cache!\n");
> > + }
> > +
> > mutex_lock(&list_lock);
> >
> > list_del(¬ifier->list);
> >
> > list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
> > - dev[i] = get_device(sd->dev);
> > + struct device *d;
> > +
> > + d = get_device(sd->dev);
>
> I would combine these two lines in one, but that's just me :-)
Especially inside a function, I think it looks cleaner to have it on
separate lines ;)
Anyway, this is a matter of personal taste.
> >
> > v4l2_async_cleanup(sd);
> >
> > /* If we handled USB devices, we'd have to lock the parent too */
> > - device_release_driver(dev[i++]);
> > + device_release_driver(d);
> > +
> > +
> > + /*
> > + * Store device at the device cache, in order to call
> > + * put_device() on the final step
> > + */
> > + if (dev)
> > + dev[i++] = d;
> > + else
> > + put_device(d);
>
> Shouldn't the put_device be moved to after the unbind? It certainly would
> 'feel' safer that way...
Agreed.
>
> >
> > if (notifier->unbind)
> > notifier->unbind(notifier, sd, sd->asd);
> > }
> >
> > mutex_unlock(&list_lock);
> >
> > + /*
> > + * Call device_attach() to reprobe devices
> > + *
> > + * NOTE: If dev allocation fails, i is 0, and the hole loop won't be
>
> Typo: hole -> whole
Thanks for pointing it. My keyboard seems to have some bad contact:
sometimes, a keypress is missed here. I would be replacing it, but the thing
is that buying an US keyboard in Brazil is not easy, and my KVM switch doesn't
like Brazilian ABNT2 keyboards.
>
> > + * executed.
> > + */
> > while (i--) {
> > struct device *d = dev[i];
> >
> > if (d && device_attach(d) < 0) {
> > const char *name = "(none)";
> > int lock = device_trylock(d);
> >
> > if (lock && d->driver)
> > name = d->driver->name;
> > dev_err(d, "Failed to re-probe to %s\n", name);
> > if (lock)
> > device_unlock(d);
> > }
> > put_device(d);
> > }
> > + kfree(dev);
> >
> > notifier->v4l2_dev = NULL;
> >
> > /*
> > * Don't care about the waiting list, it is initialised and populated
> > * upon notifier registration.
> > */
> > }
> > EXPORT_SYMBOL(v4l2_async_notifier_unregister);
> >
> > Regards,
> > Mauro
> >
>
> Regards,
>
> Hans
New patch enclosed. Please reply with your reviewed-by if you're ok with
it.
Thanks!
Mauro
commit 268e5878716eadfb981977041cb2f6d773b09174
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date: Sat Nov 2 06:20:16 2013 -0300
[media] v4l2-async: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
with is currently 128. That means that the buffer size can be up to
128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
Worse than that, someone could increase it and cause real troubles.
So, let's use dynamically allocated data, instead.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index c85d69da35bd..85a6a34128a8 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -189,30 +189,53 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
struct v4l2_subdev *sd, *tmp;
unsigned int notif_n_subdev = notifier->num_subdevs;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
- struct device *dev[n_subdev];
+ struct device **dev;
int i = 0;
if (!notifier->v4l2_dev)
return;
+ dev = kmalloc(n_subdev * sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(notifier->v4l2_dev->dev,
+ "Failed to allocate device cache!\n");
+ }
+
mutex_lock(&list_lock);
list_del(¬ifier->list);
list_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {
- dev[i] = get_device(sd->dev);
+ struct device *d;
+
+ d = get_device(sd->dev);
v4l2_async_cleanup(sd);
/* If we handled USB devices, we'd have to lock the parent too */
- device_release_driver(dev[i++]);
+ device_release_driver(d);
if (notifier->unbind)
notifier->unbind(notifier, sd, sd->asd);
+
+ /*
+ * Store device at the device cache, in order to call
+ * put_device() on the final step
+ */
+ if (dev)
+ dev[i++] = d;
+ else
+ put_device(d);
}
mutex_unlock(&list_lock);
+ /*
+ * Call device_attach() to reprobe devices
+ *
+ * NOTE: If dev allocation fails, i is 0, and the whole loop won't be
+ * executed.
+ */
while (i--) {
struct device *d = dev[i];
@@ -228,6 +251,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
}
put_device(d);
}
+ kfree(dev);
notifier->v4l2_dev = NULL;
--
Cheers,
Mauro
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCHv2 23/29] cxusb: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (21 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 22/29] v4l2-async: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 24/29] dibusb-common: " Mauro Carvalho Chehab
` (5 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Michael Krufky
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/cxusb.c:209:1: warning: 'cxusb_i2c_xfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/cxusb.c:69:1: warning: 'cxusb_ctrl_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Michael Krufky <mkrufky@linuxtv.org>
---
drivers/media/usb/dvb-usb/cxusb.c | 38 ++++++++++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c
index 3940bb0f9ef6..7d21def6b145 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -57,7 +57,14 @@ static int cxusb_ctrl_msg(struct dvb_usb_device *d,
u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
int wo = (rbuf == NULL || rlen == 0); /* write-only */
- u8 sndbuf[1+wlen];
+ u8 sndbuf[80];
+
+ if (1 + wlen > sizeof(sndbuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ wlen);
+ return -EREMOTEIO;
+ }
+
memset(sndbuf, 0, 1+wlen);
sndbuf[0] = cmd;
@@ -158,7 +165,13 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
if (msg[i].flags & I2C_M_RD) {
/* read only */
- u8 obuf[3], ibuf[1+msg[i].len];
+ u8 obuf[3], ibuf[80];
+
+ if (1 + msg[i].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[i].len);
+ return -EREMOTEIO;
+ }
obuf[0] = 0;
obuf[1] = msg[i].len;
obuf[2] = msg[i].addr;
@@ -172,7 +185,18 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
} else if (i+1 < num && (msg[i+1].flags & I2C_M_RD) &&
msg[i].addr == msg[i+1].addr) {
/* write to then read from same address */
- u8 obuf[3+msg[i].len], ibuf[1+msg[i+1].len];
+ u8 obuf[80], ibuf[80];
+
+ if (3 + msg[i].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[i].len);
+ return -EREMOTEIO;
+ }
+ if (1 + msg[i + 1].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[i + 1].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[i].len;
obuf[1] = msg[i+1].len;
obuf[2] = msg[i].addr;
@@ -191,7 +215,13 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
i++;
} else {
/* write only */
- u8 obuf[2+msg[i].len], ibuf;
+ u8 obuf[80], ibuf;
+
+ if (2 + msg[i].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[i].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[i].addr;
obuf[1] = msg[i].len;
memcpy(&obuf[2], msg[i].buf, msg[i].len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 24/29] dibusb-common: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (22 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 23/29] cxusb: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 25/29] dw2102: " Mauro Carvalho Chehab
` (4 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/dibusb-common.c:124:1: warning: 'dibusb_i2c_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/usb/dvb-usb/dibusb-common.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/dibusb-common.c b/drivers/media/usb/dvb-usb/dibusb-common.c
index c2dded92f1d3..ae9eed810bc2 100644
--- a/drivers/media/usb/dvb-usb/dibusb-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-common.c
@@ -105,11 +105,16 @@ EXPORT_SYMBOL(dibusb2_0_power_ctrl);
static int dibusb_i2c_msg(struct dvb_usb_device *d, u8 addr,
u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
{
- u8 sndbuf[wlen+4]; /* lead(1) devaddr,direction(1) addr(2) data(wlen) (len(2) (when reading)) */
+ u8 sndbuf[80]; /* lead(1) devaddr,direction(1) addr(2) data(wlen) (len(2) (when reading)) */
/* write only ? */
int wo = (rbuf == NULL || rlen == 0),
len = 2 + wlen + (wo ? 0 : 2);
+ if (4 + wlen > sizeof(sndbuf)) {
+ warn("i2c wr: len=%d is too big!\n", wlen);
+ return -EREMOTEIO;
+ }
+
sndbuf[0] = wo ? DIBUSB_REQ_I2C_WRITE : DIBUSB_REQ_I2C_READ;
sndbuf[1] = (addr << 1) | (wo ? 0 : 1);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 25/29] dw2102: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (23 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 24/29] dibusb-common: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 26/29] af9015: " Mauro Carvalho Chehab
` (3 subsequent siblings)
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Igor M. Liplianin, Andrey Pavlenko,
Antti Palosaari, Stephan Hilb
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb/dw2102.c:368:1: warning: 'dw2102_earda_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:449:1: warning: 'dw2104_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:512:1: warning: 'dw3101_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:621:1: warning: 's6x0_i2c_transfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Igor M. Liplianin <liplianin@me.by>
Cc: Andrey Pavlenko <andrey.a.pavlenko@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Stephan Hilb <stephan@ecshi.net>
---
drivers/media/usb/dvb-usb/dw2102.c | 87 +++++++++++++++++++++++++++++++++-----
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c b/drivers/media/usb/dvb-usb/dw2102.c
index 6136a2c7dbfd..1907a242d93f 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -308,7 +308,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg ms
case 2: {
/* read */
/* first write first register number */
- u8 ibuf[msg[1].len + 2], obuf[3];
+ u8 ibuf[80], obuf[3];
+
+ if (2 + msg[1].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr << 1;
obuf[1] = msg[0].len;
obuf[2] = msg[0].buf[0];
@@ -325,7 +332,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg ms
switch (msg[0].addr) {
case 0x68: {
/* write to register */
- u8 obuf[msg[0].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[0].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr << 1;
obuf[1] = msg[0].len;
memcpy(obuf + 2, msg[0].buf, msg[0].len);
@@ -335,7 +349,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg ms
}
case 0x61: {
/* write to tuner */
- u8 obuf[msg[0].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[0].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr << 1;
obuf[1] = msg[0].len;
memcpy(obuf + 2, msg[0].buf, msg[0].len);
@@ -401,7 +422,14 @@ static int dw2104_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], i
default: {
if (msg[j].flags == I2C_M_RD) {
/* read registers */
- u8 ibuf[msg[j].len + 2];
+ u8 ibuf[80];
+
+ if (2 + msg[j].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[j].len);
+ return -EREMOTEIO;
+ }
+
dw210x_op_rw(d->udev, 0xc3,
(msg[j].addr << 1) + 1, 0,
ibuf, msg[j].len + 2,
@@ -430,7 +458,14 @@ static int dw2104_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], i
} while (len > 0);
} else {
/* write registers */
- u8 obuf[msg[j].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[j].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[j].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[j].addr << 1;
obuf[1] = msg[j].len;
memcpy(obuf + 2, msg[j].buf, msg[j].len);
@@ -463,7 +498,13 @@ static int dw3101_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
case 2: {
/* read */
/* first write first register number */
- u8 ibuf[msg[1].len + 2], obuf[3];
+ u8 ibuf[80], obuf[3];
+
+ if (2 + msg[1].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[1].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[0].addr << 1;
obuf[1] = msg[0].len;
obuf[2] = msg[0].buf[0];
@@ -481,7 +522,13 @@ static int dw3101_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
case 0x60:
case 0x0c: {
/* write to register */
- u8 obuf[msg[0].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[0].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[0].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[0].addr << 1;
obuf[1] = msg[0].len;
memcpy(obuf + 2, msg[0].buf, msg[0].len);
@@ -563,7 +610,14 @@ static int s6x0_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
default: {
if (msg[j].flags == I2C_M_RD) {
/* read registers */
- u8 ibuf[msg[j].len];
+ u8 ibuf[80];
+
+ if (msg[j].len > sizeof(ibuf)) {
+ warn("i2c rd: len=%d is too big!\n",
+ msg[j].len);
+ return -EREMOTEIO;
+ }
+
dw210x_op_rw(d->udev, 0x91, 0, 0,
ibuf, msg[j].len,
DW210X_READ_MSG);
@@ -590,7 +644,14 @@ static int s6x0_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
} while (len > 0);
} else if (j < (num - 1)) {
/* write register addr before read */
- u8 obuf[msg[j].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[j].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[j].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[j + 1].len;
obuf[1] = (msg[j].addr << 1);
memcpy(obuf + 2, msg[j].buf, msg[j].len);
@@ -602,7 +663,13 @@ static int s6x0_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
break;
} else {
/* write registers */
- u8 obuf[msg[j].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[j].len > sizeof(obuf)) {
+ warn("i2c wr: len=%d is too big!\n",
+ msg[j].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[j].len + 1;
obuf[1] = (msg[j].addr << 1);
memcpy(obuf + 2, msg[j].buf, msg[j].len);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCHv2 26/29] af9015: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (24 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 25/29] dw2102: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 17:05 ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 27/29] af9035: " Mauro Carvalho Chehab
` (2 subsequent siblings)
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Antti Palosaari
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning: 'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default]
In this specific case, it is a gcc bug, as the size is a const, but
it is easy to just change it from const to a #define, getting rid of
the gcc warning.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Antti Palosaari <crope@iki.fi>
---
drivers/media/usb/dvb-usb-v2/af9015.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c b/drivers/media/usb/dvb-usb-v2/af9015.c
index d556042cf312..da47d2392f2a 100644
--- a/drivers/media/usb/dvb-usb-v2/af9015.c
+++ b/drivers/media/usb/dvb-usb-v2/af9015.c
@@ -397,12 +397,13 @@ error:
return ret;
}
+#define AF9015_EEPROM_SIZE 256
+
/* hash (and dump) eeprom */
static int af9015_eeprom_hash(struct dvb_usb_device *d)
{
struct af9015_state *state = d_to_priv(d);
int ret, i;
- static const unsigned int AF9015_EEPROM_SIZE = 256;
u8 buf[AF9015_EEPROM_SIZE];
struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, NULL};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 26/29] af9015: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 26/29] af9015: " Mauro Carvalho Chehab
@ 2013-11-02 17:05 ` Antti Palosaari
0 siblings, 0 replies; 59+ messages in thread
From: Antti Palosaari @ 2013-11-02 17:05 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
ACK. IIRC I did macro optimization here and that used way gives few
bytes smaller footprint =)
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> ompilation complains about it on some archs:
>
> drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning: 'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default]
>
> In this specific case, it is a gcc bug, as the size is a const, but
> it is easy to just change it from const to a #define, getting rid of
> the gcc warning.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Antti Palosaari <crope@iki.fi>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
> ---
> drivers/media/usb/dvb-usb-v2/af9015.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c b/drivers/media/usb/dvb-usb-v2/af9015.c
> index d556042cf312..da47d2392f2a 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9015.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9015.c
> @@ -397,12 +397,13 @@ error:
> return ret;
> }
>
> +#define AF9015_EEPROM_SIZE 256
> +
> /* hash (and dump) eeprom */
> static int af9015_eeprom_hash(struct dvb_usb_device *d)
> {
> struct af9015_state *state = d_to_priv(d);
> int ret, i;
> - static const unsigned int AF9015_EEPROM_SIZE = 256;
> u8 buf[AF9015_EEPROM_SIZE];
> struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, NULL};
>
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 27/29] af9035: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (25 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 26/29] af9015: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-02 17:19 ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 28/29] mxl111sf: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 29/29] lirc_zilog: " Mauro Carvalho Chehab
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning: 'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/media/usb/dvb-usb-v2/af9035.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c
index 1ea17dc2a76e..f43e9f336204 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -126,10 +126,16 @@ exit:
/* write multiple registers */
static int af9035_wr_regs(struct dvb_usb_device *d, u32 reg, u8 *val, int len)
{
- u8 wbuf[6 + len];
+ u8 wbuf[80];
u8 mbox = (reg >> 16) & 0xff;
struct usb_req req = { CMD_MEM_WR, mbox, sizeof(wbuf), wbuf, 0, NULL };
+ if (6 + len > sizeof(wbuf)) {
+ dev_warn(&d->udev->dev, "%s: i2c wr: len=%d is too big!\n",
+ KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
wbuf[0] = len;
wbuf[1] = 2;
wbuf[2] = 0;
@@ -228,9 +234,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[1].len);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
buf, msg[1].len, msg[1].buf };
+
+ if (5 + msg[0].len > sizeof(buf)) {
+ dev_warn(&d->udev->dev,
+ "%s: i2c xfer: len=%d is too big!\n",
+ KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr & 0x80) >> 3);
buf[0] = msg[1].len;
buf[1] = msg[0].addr << 1;
@@ -257,9 +270,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[0].len - 3);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
0, NULL };
+
+ if (5 + msg[0].len > sizeof(buf)) {
+ dev_warn(&d->udev->dev,
+ "%s: i2c xfer: len=%d is too big!\n",
+ KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr & 0x80) >> 3);
buf[0] = msg[0].len;
buf[1] = msg[0].addr << 1;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 27/29] af9035: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 27/29] af9035: " Mauro Carvalho Chehab
@ 2013-11-02 17:19 ` Antti Palosaari
0 siblings, 0 replies; 59+ messages in thread
From: Antti Palosaari @ 2013-11-02 17:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> ompilation complains about it on some archs:
>
> drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs' uses dynamic stack allocation [enabled by default]
> drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning: 'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer to be the max size of
> a control URB payload data (80 bytes).
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> ---
> drivers/media/usb/dvb-usb-v2/af9035.c | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c
> index 1ea17dc2a76e..f43e9f336204 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
> @@ -126,10 +126,16 @@ exit:
> /* write multiple registers */
> static int af9035_wr_regs(struct dvb_usb_device *d, u32 reg, u8 *val, int len)
> {
> - u8 wbuf[6 + len];
> + u8 wbuf[80];
> u8 mbox = (reg >> 16) & 0xff;
> struct usb_req req = { CMD_MEM_WR, mbox, sizeof(wbuf), wbuf, 0, NULL };
>
> + if (6 + len > sizeof(wbuf)) {
> + dev_warn(&d->udev->dev, "%s: i2c wr: len=%d is too big!\n",
> + KBUILD_MODNAME, len);
> + return -EREMOTEIO;
> + }
> +
> wbuf[0] = len;
> wbuf[1] = 2;
> wbuf[2] = 0;
> @@ -228,9 +234,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
> msg[1].len);
> } else {
> /* I2C */
> - u8 buf[5 + msg[0].len];
> + u8 buf[80];
> struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
> buf, msg[1].len, msg[1].buf };
> +
> + if (5 + msg[0].len > sizeof(buf)) {
> + dev_warn(&d->udev->dev,
> + "%s: i2c xfer: len=%d is too big!\n",
> + KBUILD_MODNAME, msg[0].len);
> + return -EREMOTEIO;
> + }
> req.mbox |= ((msg[0].addr & 0x80) >> 3);
> buf[0] = msg[1].len;
> buf[1] = msg[0].addr << 1;
> @@ -257,9 +270,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
> msg[0].len - 3);
> } else {
> /* I2C */
> - u8 buf[5 + msg[0].len];
> + u8 buf[80];
> struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
> 0, NULL };
> +
> + if (5 + msg[0].len > sizeof(buf)) {
> + dev_warn(&d->udev->dev,
> + "%s: i2c xfer: len=%d is too big!\n",
> + KBUILD_MODNAME, msg[0].len);
> + return -EREMOTEIO;
> + }
> req.mbox |= ((msg[0].addr & 0x80) >> 3);
> buf[0] = msg[0].len;
> buf[1] = msg[0].addr << 1;
>
--
http://palosaari.fi/
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 28/29] mxl111sf: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (26 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 27/29] af9035: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
2013-11-04 0:50 ` Michael Krufky
2013-11-02 13:31 ` [PATCHv2 29/29] lirc_zilog: " Mauro Carvalho Chehab
28 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Michael Krufky
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Michael Krufky <mkrufky@kernellabs.com>
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index e97964ef7f56..6538fd54c84e 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -57,7 +57,12 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
{
int wo = (rbuf == NULL || rlen == 0); /* write-only */
int ret;
- u8 sndbuf[1+wlen];
+ u8 sndbuf[80];
+
+ if (1 + wlen > sizeof(sndbuf)) {
+ pr_warn("%s: len=%d is too big!\n", __func__, wlen);
+ return -EREMOTEIO;
+ }
pr_debug("%s(wlen = %d, rlen = %d)\n", __func__, wlen, rlen);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCHv2 28/29] mxl111sf: Don't use dynamic static allocation
2013-11-02 13:31 ` [PATCHv2 28/29] mxl111sf: " Mauro Carvalho Chehab
@ 2013-11-04 0:50 ` Michael Krufky
2013-11-04 10:58 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 59+ messages in thread
From: Michael Krufky @ 2013-11-04 0:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
On Sat, Nov 2, 2013 at 9:31 AM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> Dynamic static allocation is evil, as Kernel stack is too low, and
> compilation complains about it on some archs:
>
> drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
>
> Instead, let's enforce a limit for the buffer to be the max size of
> a control URB payload data (80 bytes).
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Michael Krufky <mkrufky@kernellabs.com>
> ---
> drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index e97964ef7f56..6538fd54c84e 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -57,7 +57,12 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
> {
> int wo = (rbuf == NULL || rlen == 0); /* write-only */
> int ret;
> - u8 sndbuf[1+wlen];
> + u8 sndbuf[80];
> +
> + if (1 + wlen > sizeof(sndbuf)) {
> + pr_warn("%s: len=%d is too big!\n", __func__, wlen);
> + return -EREMOTEIO;
> + }
>
> pr_debug("%s(wlen = %d, rlen = %d)\n", __func__, wlen, rlen);
>
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't really love this, but I see your point. You're right - this
needs to be fixed.
AFAIK, the largest transfer the driver ever does is 61 bytes, but I'd
have to double check to be sure...
Is there a #define'd macro that we could place there instead of the
hardcoded '80' ? I really don't like the number '80' there,
*especially* not without a comment explaining it. Is 80 even the
maximum size of control urb payload data? Are you sure it isn't 64?
http://wiki.osdev.org/Universal_Serial_Bus#Maximum_Data_Payload_Size
...as per the article above, we should be able to read the actual
maximum size from the USB endpoint itself, but then again, that would
leave us with another dynamic static allocation.
How about if we kzalloc the buffer instead? (maybe not - that isn't
very efficient either)
If it has to be a static allocation (and it probably should be),
please #define the size rather than sticking in the number 80.
This feedback applies to your entire "Don't use dynamic static
allocation" patch series. Please don't merge those without at least
#define'ing the size value and adding an appropriate inline comment to
explain why the maximum is defined as such.
Cheers,
Mike
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 28/29] mxl111sf: Don't use dynamic static allocation
2013-11-04 0:50 ` Michael Krufky
@ 2013-11-04 10:58 ` Mauro Carvalho Chehab
2013-11-04 11:04 ` Michael Krufky
0 siblings, 1 reply; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-04 10:58 UTC (permalink / raw)
To: Michael Krufky; +Cc: Linux Media Mailing List
Em Sun, 3 Nov 2013 19:50:02 -0500
Michael Krufky <mkrufky@kernellabs.com> escreveu:
> On Sat, Nov 2, 2013 at 9:31 AM, Mauro Carvalho Chehab
> <m.chehab@samsung.com> wrote:
> > Dynamic static allocation is evil, as Kernel stack is too low, and
> > compilation complains about it on some archs:
> >
> > drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
> >
> > Instead, let's enforce a limit for the buffer to be the max size of
> > a control URB payload data (80 bytes).
> >
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Michael Krufky <mkrufky@kernellabs.com>
> > ---
> > drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> > index e97964ef7f56..6538fd54c84e 100644
> > --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> > +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> > @@ -57,7 +57,12 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
> > {
> > int wo = (rbuf == NULL || rlen == 0); /* write-only */
> > int ret;
> > - u8 sndbuf[1+wlen];
> > + u8 sndbuf[80];
> > +
> > + if (1 + wlen > sizeof(sndbuf)) {
> > + pr_warn("%s: len=%d is too big!\n", __func__, wlen);
> > + return -EREMOTEIO;
> > + }
> >
> > pr_debug("%s(wlen = %d, rlen = %d)\n", __func__, wlen, rlen);
> >
> > --
> > 1.8.3.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I don't really love this, but I see your point. You're right - this
> needs to be fixed.
>
> AFAIK, the largest transfer the driver ever does is 61 bytes, but I'd
> have to double check to be sure...
>
> Is there a #define'd macro that we could place there instead of the
> hardcoded '80' ? I really don't like the number '80' there,
> *especially* not without a comment explaining it. Is 80 even the
> maximum size of control urb payload data? Are you sure it isn't 64?
>
> http://wiki.osdev.org/Universal_Serial_Bus#Maximum_Data_Payload_Size
>
> ...as per the article above, we should be able to read the actual
> maximum size from the USB endpoint itself, but then again, that would
> leave us with another dynamic static allocation.
There's one driver using 80 bytes for payload (tm6000). Anyway,
I double-checked at USB 2.0 specification: the max size for
control endpoints is 64 bytes for full-speed devices:
"All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum data payload sizes
for full-speed control endpoints, only 8-byte maximum data payload sizes for low-speed control endpoints,
and only 64-byte maximum data payload size for high-speed control endpoints. No Host Controller is
required to support larger or smaller maximum data payload sizes."
Source: USB revision 2.0 - chapter 5.5.3 Control Transfer Packet Size Constraints
http://www.usb.org/developers/docs/usb_20_070113.zip
So, except for devices that violates that, the worse case scenario is
64 bytes.
It should be noticed that the I2C bus could use a different limit,
so, on PCI devices, in theory, it would be possible to use a larger
window.
Yet, I doubt that any sane tuner/frontend design would require a
packet size bigger than the max size supported by the USB bus, as
that would limit their usage. Also, most (if not all) of those
tuners/frontends were added due to USB devices, anyway.
>
> How about if we kzalloc the buffer instead? (maybe not - that isn't
> very efficient either)
Seems an overkill to me to create/delete a buffer for every single I2C
transfer. Of course, a latter patch could optimize the buffer size to
match what's supported by the hardware, or to use a pre-allocated buffer,
but this is out of my scope: all I want is to get rid of dynamically
allocated buffers. I don't intend to read all those datasheets and
optimize each of those drivers, especially since I may not have the
hardware here for testing.
> If it has to be a static allocation (and it probably should be),
> please #define the size rather than sticking in the number 80.
Ok.
> This feedback applies to your entire "Don't use dynamic static
> allocation" patch series. Please don't merge those without at least
> #define'ing the size value and adding an appropriate inline comment to
> explain why the maximum is defined as such.
Well, a comment is provided already at the commit message. I don't
see any need to overbloat the code with a comment like that. In any
case, if I were to add a comment, it would be something like:
"I guess x bytes would be enough"
As only doing a deep code inspection and reading the datasheets, we'll
know for sure what's the maximum size supported by each device.
Regards,
Mauro
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCHv2 28/29] mxl111sf: Don't use dynamic static allocation
2013-11-04 10:58 ` Mauro Carvalho Chehab
@ 2013-11-04 11:04 ` Michael Krufky
0 siblings, 0 replies; 59+ messages in thread
From: Michael Krufky @ 2013-11-04 11:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List
On Mon, Nov 4, 2013 at 5:58 AM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> Em Sun, 3 Nov 2013 19:50:02 -0500
> Michael Krufky <mkrufky@kernellabs.com> escreveu:
>
>> On Sat, Nov 2, 2013 at 9:31 AM, Mauro Carvalho Chehab
>> <m.chehab@samsung.com> wrote:
>> > Dynamic static allocation is evil, as Kernel stack is too low, and
>> > compilation complains about it on some archs:
>> >
>> > drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
>> >
>> > Instead, let's enforce a limit for the buffer to be the max size of
>> > a control URB payload data (80 bytes).
>> >
>> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>> > Cc: Michael Krufky <mkrufky@kernellabs.com>
>> > ---
>> > drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++++++-
>> > 1 file changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
>> > index e97964ef7f56..6538fd54c84e 100644
>> > --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
>> > +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
>> > @@ -57,7 +57,12 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
>> > {
>> > int wo = (rbuf == NULL || rlen == 0); /* write-only */
>> > int ret;
>> > - u8 sndbuf[1+wlen];
>> > + u8 sndbuf[80];
>> > +
>> > + if (1 + wlen > sizeof(sndbuf)) {
>> > + pr_warn("%s: len=%d is too big!\n", __func__, wlen);
>> > + return -EREMOTEIO;
>> > + }
>> >
>> > pr_debug("%s(wlen = %d, rlen = %d)\n", __func__, wlen, rlen);
>> >
>> > --
>> > 1.8.3.1
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> I don't really love this, but I see your point. You're right - this
>> needs to be fixed.
>>
>> AFAIK, the largest transfer the driver ever does is 61 bytes, but I'd
>> have to double check to be sure...
>>
>> Is there a #define'd macro that we could place there instead of the
>> hardcoded '80' ? I really don't like the number '80' there,
>> *especially* not without a comment explaining it. Is 80 even the
>> maximum size of control urb payload data? Are you sure it isn't 64?
>>
>> http://wiki.osdev.org/Universal_Serial_Bus#Maximum_Data_Payload_Size
>>
>> ...as per the article above, we should be able to read the actual
>> maximum size from the USB endpoint itself, but then again, that would
>> leave us with another dynamic static allocation.
>
> There's one driver using 80 bytes for payload (tm6000). Anyway,
> I double-checked at USB 2.0 specification: the max size for
> control endpoints is 64 bytes for full-speed devices:
>
> "All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum data payload sizes
> for full-speed control endpoints, only 8-byte maximum data payload sizes for low-speed control endpoints,
> and only 64-byte maximum data payload size for high-speed control endpoints. No Host Controller is
> required to support larger or smaller maximum data payload sizes."
>
> Source: USB revision 2.0 - chapter 5.5.3 Control Transfer Packet Size Constraints
> http://www.usb.org/developers/docs/usb_20_070113.zip
>
> So, except for devices that violates that, the worse case scenario is
> 64 bytes.
>
> It should be noticed that the I2C bus could use a different limit,
> so, on PCI devices, in theory, it would be possible to use a larger
> window.
>
> Yet, I doubt that any sane tuner/frontend design would require a
> packet size bigger than the max size supported by the USB bus, as
> that would limit their usage. Also, most (if not all) of those
> tuners/frontends were added due to USB devices, anyway.
>
>>
>> How about if we kzalloc the buffer instead? (maybe not - that isn't
>> very efficient either)
>
> Seems an overkill to me to create/delete a buffer for every single I2C
> transfer. Of course, a latter patch could optimize the buffer size to
> match what's supported by the hardware, or to use a pre-allocated buffer,
> but this is out of my scope: all I want is to get rid of dynamically
> allocated buffers. I don't intend to read all those datasheets and
> optimize each of those drivers, especially since I may not have the
> hardware here for testing.
>
>> If it has to be a static allocation (and it probably should be),
>> please #define the size rather than sticking in the number 80.
>
> Ok.
>
>> This feedback applies to your entire "Don't use dynamic static
>> allocation" patch series. Please don't merge those without at least
>> #define'ing the size value and adding an appropriate inline comment to
>> explain why the maximum is defined as such.
>
> Well, a comment is provided already at the commit message. I don't
> see any need to overbloat the code with a comment like that. In any
> case, if I were to add a comment, it would be something like:
> "I guess x bytes would be enough"
>
> As only doing a deep code inspection and reading the datasheets, we'll
> know for sure what's the maximum size supported by each device.
>
> Regards,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I'd really prefer to also see an inline comment, because just in case
we cause a new bug here that may not get identified until time goes
by, the inline comment will give the next developer some clue as to
why this size limit exists.
Then again, if the #define'd macro name is descriptive enough, then
maybe that would be fine.
Thanks & best regards,
Mike
(apologies for sending this twice - accidentally dropped cc to the
list the first time :-P )
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCHv2 29/29] lirc_zilog: Don't use dynamic static allocation
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
` (27 preceding siblings ...)
2013-11-02 13:31 ` [PATCHv2 28/29] mxl111sf: " Mauro Carvalho Chehab
@ 2013-11-02 13:31 ` Mauro Carvalho Chehab
28 siblings, 0 replies; 59+ messages in thread
From: Mauro Carvalho Chehab @ 2013-11-02 13:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/staging/media/lirc/lirc_zilog.c:967:1: warning: 'read' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be 80. That should
be more than enough.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
---
drivers/staging/media/lirc/lirc_zilog.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c
index 11d5338b4f2f..9bcd52a962d4 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -941,7 +941,14 @@ static ssize_t read(struct file *filep, char *outbuf, size_t n, loff_t *ppos)
schedule();
set_current_state(TASK_INTERRUPTIBLE);
} else {
- unsigned char buf[rbuf->chunk_size];
+ unsigned char buf[80];
+
+ if (rbuf->chunk_size > sizeof(buf)) {
+ zilog_error("chunk_size is too big (%d)!\n",
+ rbuf->chunk_size);
+ ret = -EIO;
+ break;
+ }
m = lirc_buffer_read(rbuf, buf);
if (m == rbuf->chunk_size) {
ret = copy_to_user((void *)outbuf+written, buf,
--
1.8.3.1
^ permalink raw reply related [flat|nested] 59+ messages in thread