On 08.12.2013 01:49, Steven Luo wrote:
This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.
As far as I can tell
On Tue, Dec 10, 2013 at 04:31:25PM -0700, H Hartley Sweeten wrote:
> Some of the callback functions that upload the firmware in the comedi
> drivers return a positive value indicating the number of bytes sent
> to the device. Detect this condition and just return '0' to indicate
> a successful uplo
On Tue, Dec 10, 2013 at 06:05:29AM -0500, Gary Rookard wrote:
> Fixed coding style issues.
Which issues?
>
> Signed-off-by: Gary Alan Rookard
> ---
> On branch staging-next
> drivers/staging/bcm/DDRInit.c | 1892
> -
> 1 file changed, 946 insertions(+),
On Mon, Dec 9, 2013 at 7:01 PM, Octavian Purdila wrote:
> On Thu, Dec 5, 2013 at 4:02 AM, Arve Hjønnevåg wrote:
>> On Wed, Dec 4, 2013 at 2:02 PM, Greg KH wrote:
>>> On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote:
On Wed, Dec 4, 2013 at 1:43 PM, Greg KH wrote:
> On Wed, D
hacked cfc_check_trigger_src:
-
static inline int cfc_check_trigger_src(unsigned int *src, unsigned int
flags)
{
unsigned int orig_src = *src;
*src = orig_src & flags;
printk("cfc_check_trigger_src: orig_src=%x, *src=%x
\n",orig_src,*sr
Agree with your comments. Let's just do the
return ret < 0 ? ret : 0;
and it's sorted. Thanks for the quick reply.
/Bernd
On 10/12/13 23:24, Hartley Sweeten wrote:
On Tuesday, December 10, 2013 3:28 PM, Dan Carpenter wrote:
On Tue, Dec 10, 2013 at 09:30:43PM +, Ian Abbott wrote:
It mig
Some of the callback functions that upload the firmware in the comedi
drivers return a positive value indicating the number of bytes sent
to the device. Detect this condition and just return '0' to indicate
a successful upload.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartm
On Tuesday, December 10, 2013 4:29 PM, Bernd Porr wrote:
>
> Agree with your comments. Let's just do the
>
> return ret < 0 ? ret : 0;
>
> and it's sorted. Thanks for the quick reply.
Ok. I'll post this as a proper patch in a sec.
Hartley
___
devel mai
On Tuesday, December 10, 2013 3:28 PM, Dan Carpenter wrote:
> On Tue, Dec 10, 2013 at 09:30:43PM +, Ian Abbott wrote:
>>
>> It might be better just to prevent comedi_load_firmware() returning
>> a value greater than zero, since I can't think of any reason why it
>> would need to. That would a
On Tue, Dec 10, 2013 at 09:30:43PM +, Ian Abbott wrote:
>
> It might be better just to prevent comedi_load_firmware() returning
> a value greater than zero, since I can't think of any reason why it
> would need to. That would also work for the usbdux driver.
>
Yeah. It looks like it's usbd
Good point. Nobody cares really how many bytes the firmware uploader
sends to the DUX-board.
/Bernd
On 10/12/13 21:30, Ian Abbott wrote:
On 2013-12-10 21:07, Bernd Porr wrote:
Date: Tue, 10 Dec 2013 19:42:13 +
Subject: [PATCH 1/1] comedi_load_firmware returns the number of
transmitted
b
From: Ivaylo Dimitrov
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
Signed-off-by: Ivaylo Dimitrov
---
drivers/staging/tidspbridge/Makefile |2 +-
drivers/staging/tidspbridge/gen/uu
On 2013-12-10 21:07, Bernd Porr wrote:
Hi all,
here is the patch to fix the original bug. That was easier than I
expected. That's against the latest RC kernel.
However there are a couple other issues now.
There seems to be an issue with comedi generic timed and the commands
correcting the TRIG
On 2013-12-10 21:07, Bernd Porr wrote:
Date: Tue, 10 Dec 2013 19:42:13 +
Subject: [PATCH 1/1] comedi_load_firmware returns the number of transmitted
bytes to the USB controller. The result is negative on failure. Thus, the ret
argument needs to be checked if negative.
Signed-off-by: Bern
Hi all,
here is the patch to fix the original bug. That was easier than I
expected. That's against the latest RC kernel.
However there are a couple other issues now.
There seems to be an issue with comedi generic timed and the commands
correcting the TRIG bit. It ANDs the right bit values fi
On Tuesday, December 10, 2013 4:48 AM, Bernd Porr wrote:
> I've just checked out after a while the newest RC kernel and the
> usb-auto config/attach is broken. Seems so that the driver specific usb
> attach is no longer called and no firmware is loaded. Hartly, can you
> point me to the code bit
On 2013-12-10 00:30, H Hartley Sweeten wrote:
This series cleans up all the comedi_lrange tables to make it easier to
spot common code that could be reduced.
The series is just to make it easier to review. If needed I can repost this
as a single patch.
H Hartley Sweeten (31):
staging: comedi
Hi all,
I've just checked out after a while the newest RC kernel and the
usb-auto config/attach is broken. Seems so that the driver specific usb
attach is no longer called and no firmware is loaded. Hartly, can you
point me to the code bits which should call the driver spcific attach or
give
Fixed a coding style issue.
Signed-off-by: Gary Alan Rookard
---
On branch staging-next
drivers/staging/bcm/DDRInit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
index 100ddf9..43de518 100644
--- a/drivers/stag
On 2013-12-09 22:30, H Hartley Sweeten wrote:
This driver is actually fairly simple but it's a bit confusing with all
the subdevice private data usage.
Clean the driver up and remove all the cruft.
H Hartley Sweeten (48):
staging: comedi: pcmmio: remove unused {lock,unlock}_port()
staging
Fixed coding style issues.
Signed-off-by: Gary Alan Rookard
---
On branch staging-next
drivers/staging/bcm/DDRInit.c | 337 +++---
1 file changed, 148 insertions(+), 189 deletions(-)
diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
i
Fixed coding style issues.
Signed-off-by: Gary Alan Rookard
---
On branch staging-next
drivers/staging/bcm/DDRInit.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
index 53f7191..1
Fixed coding style issues
Signed-off-by: Gary Alan Rookard
---
On branch staging-next
drivers/staging/bcm/DDRInit.c | 99 +--
1 file changed, 49 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
inde
Fixed coding style issues
Signed-off-by: Gary Alan Rookard chip_id)
- {
+ switch (Adapter->chip_id) {
case 0xbece3200:
- switch (Adapter->DDRSetting)
- {
+ switch (Adapter->DDRSetting) {
case DDR_80_MHZ:
This patchset is an attempt to fix the coding style
issues found in the file DDRInit.c
Gary Rookard (7):
Staging: bcm: DDRinit: fixed indentation coding style issues
Staging: bcm: DDRInit: fixed spacing coding style issues
Staging: bcm: DDRInit: fixed brace coding style issues
Staging: bcm
On 2013-12-09 22:30, H Hartley Sweeten wrote:
There is only one ai subdevice in this driver so there is no reason
to hold the last sample written to each channel in the subdevice
private data. Move the data into the device private data,
This gets some of the data out of the subdevice private dat
On 12/10/2013 06:05 PM, Dan Carpenter wrote:
> On Tue, Dec 10, 2013 at 03:27:55PM +0530, Rashika Kheria wrote:
>> Should I attempt to rectify the code in handle_data_in_packet() ?
>
> Yes, please.
>
> So, one thing that I notice is that people freak out when they introduce
> a bug and send a stri
On Tue, Dec 10, 2013 at 03:27:55PM +0530, Rashika Kheria wrote:
> Should I attempt to rectify the code in handle_data_in_packet() ?
Yes, please.
So, one thing that I notice is that people freak out when they introduce
a bug and send a string of panicked buggy patches to try fix it.
Ideally, you c
Hello all,
I tried to refactor this function.
On Tue, Dec 10, 2013 at 3:07 PM, Chen Gang wrote:
> On 12/10/2013 05:10 PM, Dan Carpenter wrote:
>> On Tue, Dec 10, 2013 at 01:07:58PM +0800, Chen Gang wrote:
>>> Hello Maintainers:
>>>
>>> The compiler help me find a warning about it, please help ch
On 12/10/2013 05:10 PM, Dan Carpenter wrote:
> On Tue, Dec 10, 2013 at 01:07:58PM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> The compiler help me find a warning about it, please help check thanks.
>>
>> The related git commit: "b73db54 Staging: dgrp: Refactor the function
>> dgrp_receive()
On Tue, Dec 10, 2013 at 01:07:58PM +0800, Chen Gang wrote:
> Hello Maintainers:
>
> The compiler help me find a warning about it, please help check thanks.
>
> The related git commit: "b73db54 Staging: dgrp: Refactor the function
> dgrp_receive() in drrp_net_ops.c"
>
There are a couple other wr
31 matches
Mail list logo
