[PATCH] [media] OMAP1: fix use after free
Even though clk_put() is a no-op on most architectures it is not for some ARM implementations. To not fail on those, release the clock timer before freeing the surrounding structure. This bug was spotted by the semantic patch tool coccinelle using the script found at scripts/coccinelle/free/kfree.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/ Signed-off-by: Mathias Krause --- drivers/media/video/omap1_camera.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/omap1_camera.c b/drivers/media/video/omap1_camera.c index 0a2fb2b..9ed1513 100644 --- a/drivers/media/video/omap1_camera.c +++ b/drivers/media/video/omap1_camera.c @@ -1664,10 +1664,10 @@ static int __exit omap1_cam_remove(struct platform_device *pdev) res = pcdev->res; release_mem_region(res->start, resource_size(res)); - kfree(pcdev); - clk_put(pcdev->clk); + kfree(pcdev); + dev_info(&pdev->dev, "OMAP1 Camera Interface driver unloaded\n"); return 0; -- 1.5.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AF9015 Problem
Hi there, I have a problem using my DIGITRADE DVB-T stick, which is marked as fully supported in the wiki. It works fine for a while, but after some time it crashes and I have to reboot and disconnect the stick to make it work again (for a while) dmesg | grep af9015 says: [ 12.832866] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware [ 13.059483] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [ 13.133595] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [ 13.134316] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) [ 13.837011] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. [ 13.842692] usbcore: registered new interface driver dvb_usb_af9015 [ 854.135480] af9015: bulk message failed:-22 (8/-1) [ 854.135488] af9015: bulk message failed:-22 (8/0) [ 854.135493] af9015: bulk message failed:-22 (9/0) [ 854.135498] af9015: bulk message failed:-22 (8/-30720) [ 854.135503] af9015: bulk message failed:-22 (8/-30720) [ 854.135508] af9015: bulk message failed:-22 (8/-1) [ 1080.430165] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1200.431386] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1320.431408] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1440.430306] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1560.431363] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1680.430227] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1800.430167] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 1920.430438] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 2040.431407] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 2160.430155] [] af9015_usb_device_exit+0x41/0x60 [dvb_usb_af9015] [ 6541.809955] af9015: bulk message failed:-22 (8/-30720) [ 6573.722578] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully deinitialized and disconnected. [ 6573.808899] usbcore: deregistering interface driver dvb_usb_af9015 [ 6574.452270] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [ 6574.452777] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) [ 6575.033328] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. [ 6575.043645] usbcore: registered new interface driver dvb_usb_af9015 [73982.427778] af9015: bulk message failed:-22 (8/-1) [73982.427785] af9015: bulk message failed:-22 (8/0) [73982.427790] af9015: bulk message failed:-22 (9/0) [73982.427795] af9015: bulk message failed:-22 (8/-30720) [73982.427800] af9015: bulk message failed:-22 (8/-30720) [73982.427805] af9015: bulk message failed:-22 (8/-1) by looking at the dmesg, I found out a strange thing: an af9013 (yes, THREE at the end) device is recognized and registred also. dmesg | grep 9013: [ 13.187955] af9013: firmware version:4.95.0 [ 13.190955] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [ 854.135485] af9013: I2C read failed reg:d417 [ 854.135490] af9013: I2C read failed reg:d417 [ 854.135500] af9013: I2C read failed reg:d417 [ 854.135505] af9013: I2C read failed reg:d417 [ 854.135510] af9013: I2C read failed reg:d730 [ 6574.458711] af9013: firmware version:4.95.0 [ 6574.463654] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [73982.427782] af9013: I2C read failed reg:d417 [73982.427787] af9013: I2C read failed reg:d417 [73982.427797] af9013: I2C read failed reg:d417 [73982.427802] af9013: I2C read failed reg:d417 [73982.427807] af9013: I2C read failed reg:d730 is anyone running this device stable and/or have an idea what i could do to get rid of the problem? thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jan 30 19:00:28 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: OK linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tevii s660 still not working properly, hardware donation
try please this patch and patched firmware from vip100 http://linuxdvb.org.ru/wbb/index.php?page=Thread&postID=19310#post19310 > I know you are mantaining the drivers for the tevii s660 usb. > After a few month testing/waiting i still cannot get it to work properly > using the repo: http://mercurial.intuxication.org/hg/s2-liplianin. > > My system intel atom 945dgclf and my laptop are hanging when i try to > tune to a frequency. > The system load goes up not because of cpu or disk io and after > disabling the dvb-usb-dw2102 driver and restarting vdr the system works > fine with the nova hd card. > > Do you have any idea what it could be or would you otherwise receive my > device to test it? Remote access can also be arranged. > > I'm out of ideas. > Any thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] video/saa7164: Fix sparse warning: Using plain integer as NULL pointer
From: Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing
if(var == 0)
with
if (!var)
after an allocation
and all other offending 0s with NULL.
KernelVersion: linus' tree-1f0324c
Signed-off-by: Peter Huewe
---
v2: I changed the patch according to Julia's hints.
i.e. using if(!buf) instead of if(buf==NULL) after the kmalloc family,
and other allocations.
drivers/media/video/saa7164/saa7164-api.c | 10 +-
drivers/media/video/saa7164/saa7164-buffer.c | 16
drivers/media/video/saa7164/saa7164-bus.c |8
drivers/media/video/saa7164/saa7164-cmd.c | 10 +-
drivers/media/video/saa7164/saa7164-core.c|8
drivers/media/video/saa7164/saa7164-dvb.c |4 ++--
drivers/media/video/saa7164/saa7164-encoder.c |8
drivers/media/video/saa7164/saa7164-fw.c |2 +-
drivers/media/video/saa7164/saa7164-vbi.c |8
9 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/saa7164/saa7164-api.c
b/drivers/media/video/saa7164/saa7164-api.c
index bd86d97..8a98ab6 100644
--- a/drivers/media/video/saa7164/saa7164-api.c
+++ b/drivers/media/video/saa7164/saa7164-api.c
@@ -743,7 +743,7 @@ int saa7164_api_configure_dif(struct saa7164_port *port,
u32 std)
int saa7164_api_initialize_dif(struct saa7164_port *port)
{
struct saa7164_dev *dev = port->dev;
- struct saa7164_port *p = 0;
+ struct saa7164_port *p = NULL;
int ret = -EINVAL;
u32 std = 0;
@@ -926,9 +926,9 @@ int saa7164_api_configure_port_mpeg2ps(struct saa7164_dev
*dev,
int saa7164_api_dump_subdevs(struct saa7164_dev *dev, u8 *buf, int len)
{
- struct saa7164_port *tsport = 0;
- struct saa7164_port *encport = 0;
- struct saa7164_port *vbiport = 0;
+ struct saa7164_port *tsport = NULL;
+ struct saa7164_port *encport = NULL;
+ struct saa7164_port *vbiport = NULL;
u32 idx, next_offset;
int i;
struct tmComResDescrHeader *hdr, *t;
@@ -1340,7 +1340,7 @@ int saa7164_api_enum_subdevs(struct saa7164_dev *dev)
/* Allocate enough storage for all of the descs */
buf = kzalloc(buflen, GFP_KERNEL);
- if (buf == NULL)
+ if (!buf)
return SAA_ERR_NO_RESOURCES;
/* Retrieve them */
diff --git a/drivers/media/video/saa7164/saa7164-buffer.c
b/drivers/media/video/saa7164/saa7164-buffer.c
index ddd2521..66696fa 100644
--- a/drivers/media/video/saa7164/saa7164-buffer.c
+++ b/drivers/media/video/saa7164/saa7164-buffer.c
@@ -93,7 +93,7 @@ struct saa7164_buffer *saa7164_buffer_alloc(struct
saa7164_port *port,
u32 len)
{
struct tmHWStreamParameters *params = &port->hw_streamingparams;
- struct saa7164_buffer *buf = 0;
+ struct saa7164_buffer *buf = NULL;
struct saa7164_dev *dev = port->dev;
int i;
@@ -103,7 +103,7 @@ struct saa7164_buffer *saa7164_buffer_alloc(struct
saa7164_port *port,
}
buf = kzalloc(sizeof(struct saa7164_buffer), GFP_KERNEL);
- if (buf == NULL) {
+ if (!buf) {
log_warn("%s() SAA_ERR_NO_RESOURCES\n", __func__);
goto ret;
}
@@ -157,7 +157,7 @@ fail2:
fail1:
kfree(buf);
- buf = 0;
+ buf = NULL;
ret:
return buf;
}
@@ -289,14 +289,14 @@ struct saa7164_user_buffer
*saa7164_buffer_alloc_user(struct saa7164_dev *dev,
struct saa7164_user_buffer *buf;
buf = kzalloc(sizeof(struct saa7164_user_buffer), GFP_KERNEL);
- if (buf == 0)
- return 0;
+ if (!buf)
+ return NULL;
buf->data = kzalloc(len, GFP_KERNEL);
- if (buf->data == 0) {
+ if (!buf->data) {
kfree(buf);
- return 0;
+ return NULL;
}
buf->actual_size = len;
@@ -315,7 +315,7 @@ void saa7164_buffer_dealloc_user(struct saa7164_user_buffer
*buf)
return;
kfree(buf->data);
- buf->data = 0;
+ buf->data = NULL;
kfree(buf);
}
diff --git a/drivers/media/video/saa7164/saa7164-bus.c
b/drivers/media/video/saa7164/saa7164-bus.c
index b2b0d97..466e1b0 100644
--- a/drivers/media/video/saa7164/saa7164-bus.c
+++ b/drivers/media/video/saa7164/saa7164-bus.c
@@ -158,7 +158,7 @@ int saa7164_bus_set(struct saa7164_dev *dev, struct
tmComResInfo* msg,
return SAA_ERR_BAD_PARAMETER;
}
- if ((msg->size > 0) && (buf == 0)) {
+ if ((msg->size > 0) && (buf == NULL)) {
printk(KERN_ERR "%s() Missing message buffer\n", __func__);
return SAA_ERR_BAD_PARAMETER;
}
@@ -315,7 +315,7 @@ int saa7164_bus_get(struct saa7164_dev *dev, struct
tmComResInfo* msg,
saa7164_bus_verify(dev);
- if (msg == 0)
+ if (msg == NULL)
return ret;
Re: [PATCH v2] video/saa7164: Fix sparse warning: Using plain integer as NULL pointer
On Sun, Jan 30, 2011 at 2:33 PM, Peter Huewe wrote:
> From: Peter Huewe
>
> This patch fixes the warning "Using plain integer as NULL pointer",
> generated by sparse, by replacing
> if(var == 0)
> with
> if (!var)
> after an allocation
> and all other offending 0s with NULL.
>
> KernelVersion: linus' tree-1f0324c
>
> Signed-off-by: Peter Huewe
> ---
> v2: I changed the patch according to Julia's hints.
> i.e. using if(!buf) instead of if(buf==NULL) after the kmalloc family,
> and other allocations.
Ok, so now we've gone from "eliminating a couple of sparse warnings"
to "going through the rest of the code and jamming in some alternate
coding style when there was nothing wrong with it in the first place."
Don't get me wrong, I appreciate the role of the kernel janitors in
general, but this patch is crap. It's changes like this that just
lower the signal/noise ratio on *real* work going on, and increasing
the likelihood that some well intentioned janitor screwed up one of
the conversions.
After all, it's not like the author of this patch actually tried the
resulting code. He only has to mess up one of those two line changes
and we go from "driver that works perfectly well" to "driver that is
100% broken".
There are much better uses of the maintainer's time than going through
patches like this to make sure the submitter didn't screw up the a
conversion that provides no real value.
A change like this:
- if (buf == NULL) {
+ if (!buf) {
is a worthless change, and there is is a higher chance that one of
them gets screwed up in the patch than what we had to start with.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] OMAP1: fix use after free
On Sun, 30 Jan 2011, Mathias Krause wrote: > Even though clk_put() is a no-op on most architectures it is not for > some ARM implementations. To not fail on those, release the clock timer > before freeing the surrounding structure. Hm, ok, I guess, it is a noop on OMAP1, otherwise they'd notice this much earlier, so, it, probably, doesn't currently affect the functionality, still, I think, this should go in 2.6.38. Don't think we need it in stable though. I'll queue it for one of -rcX. Thanks Guennadi > > This bug was spotted by the semantic patch tool coccinelle using the > script found at scripts/coccinelle/free/kfree.cocci. > > More information about semantic patching is available at > http://coccinelle.lip6.fr/ > > Signed-off-by: Mathias Krause > --- > drivers/media/video/omap1_camera.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/omap1_camera.c > b/drivers/media/video/omap1_camera.c > index 0a2fb2b..9ed1513 100644 > --- a/drivers/media/video/omap1_camera.c > +++ b/drivers/media/video/omap1_camera.c > @@ -1664,10 +1664,10 @@ static int __exit omap1_cam_remove(struct > platform_device *pdev) > res = pcdev->res; > release_mem_region(res->start, resource_size(res)); > > - kfree(pcdev); > - > clk_put(pcdev->clk); > > + kfree(pcdev); > + > dev_info(&pdev->dev, "OMAP1 Camera Interface driver unloaded\n"); > > return 0; > -- > 1.5.6.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WL1273 FM Radio driver...
Hi Matti, On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote: > Hello > > I have been trying to get the WL1273 FM radio driver into the kernel for > some time. It has been kind of difficult, one of the reasons is that I > didn't realize I should have tried to involve all relevant maintainers > to the discussion form the beginning (AsoC, Media and MFD). At Mark's > suggestion I'm trying to reopen the discussion now. > > The driver consists of an MFD core and two child drivers (the audio > codec and the V4L2 driver). And the question is mainly about the role of > the MFD driver: the original design had the IO functions in the core. > Currently the core is practically empty mainly because Mauro very > strongly wanted to have “everything” in the V4L2 driver. What was Mauro main concerns with having the IO part in the core ? A lot of MFD drivers are going that path already. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Thu, Jan 27, 2011 at 12:22 AM, Anatolij Gustschin wrote: > Reading the commit message again I now realize that there is > a mistake. > > On Wed, 26 Jan 2011 09:49:49 +0100 > Anatolij Gustschin wrote: > ... >> received data. DMA_BUFx_RDY won't be set by the IPU, so waiting >> for this event in the interrupt handler is wrong. > > This should read 'DMAIC_x_CUR_BUF flag won't be flipped here by > the IPU, so waiting for this event in the EOF interrupt handler > is wrong.' > > I'll submit another patch fixing the commit message. > Ok, also looking for a reviewed/acked by Guennadi. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
