From: Wei Yongjun
Add the missing unlock before return from function bcm2048_rds_fifo_receive()
in the error handling case.
Signed-off-by: Wei Yongjun
---
drivers/staging/media/bcm2048/radio-bcm2048.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/bcm2048/radio-bcm20
On Wed, Dec 11, 2013 at 01:27:17PM +0300, Dan Carpenter wrote:
> On Wed, Dec 11, 2013 at 11:57:04AM +0200, Ivaylo Dimitrov wrote:
> > On 11.12.2013 10:33, Dan Carpenter wrote:
> > >On Wed, Dec 11, 2013 at 09:45:52AM +0200, Ivajlo Dimitrov wrote:
> > >>I can pick your changes and re-send the origina
On 11/15/2013 01:53 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard DMA DT bindings.
>
> Histor
On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
wrote:
> On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg wrote:
>>
>> Assuming you are talking about a kernel compat layer that translates
>> the flat_binder_object structs as they pass between 32 bit and 64 bit
>> processes, that will not always
From: Steven Luo
Commit 559c71fe5dc3 ("Staging: TIDSPBRIDGE: Use vm_iomap_memory for
mmap-ing instead of remap_pfn_range") had the effect of inadvertently
shifting the start of the physical memory area mapped by
pdata->phys_mempool_base. Correct this by subtracting that shift before
calling vm_i
On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg wrote:
>
> Assuming you are talking about a kernel compat layer that translates
> the flat_binder_object structs as they pass between 32 bit and 64 bit
> processes, that will not always work. The data portion of the message
> sometimes contain size v
From: Bernd Porr
If the channel list is not set in userspace we get an error at
PTR_ERR(async->cmd.chanlist). However, do_become_nonbusy(dev, s) cleans
up this pointer which causes a kernel ooops. Setting the channel list in
async to NULL and checking this in do_become_nonbusy prevents the oops.
On 2013-12-11 11:58, Bernd Porr wrote:
From d83a3e0cda7559e9b91759ab4ef8a6c3eb19fbc0 Mon Sep 17 00:00:00 2001
From: Bernd Porr
Date: Wed, 11 Dec 2013 11:45:09 +
Subject: [PATCH 1/1] If the channel list is not set in userspace we get an
error at PTR_ERR(async->cmd.chanlist). However, do_bec
When a dynamically allocated `struct comedi_device` gets automatically
unconfigured by a call to `comedi_auto_unconfig()` from a lower-level
driver's bus removal function (e.g. when a USB device is disconnected),
the class device in `dev->class_dev` (where `dev` points to the `struct
comedi_device`
When a dynamically created comedi device is being automatically removed
by a call to `comedi_auto_unconfig()` from the lower level driver,
`comedi_device_cleanup()` is called to perform the detachment from the
lower level driver. If the comedi device is open at the time,
`dev->use_count` will be t
Fix some bugs related to removing dynamically allocated comedi devices
that have open file objects.
1) staging/comedi: keep reference to class device after destroyed
2) staging/comedi: bug fix for module usage count on device removal
drivers/staging/comedi/comedi_fops.c | 39 ++--
On 09/12/13 16:05, Aaron Sierra wrote:
> This patch updates the vme_master and vme_slave structures to use
> types with well defined size and to prevent the compiler from
> inserting padding (between enable and vme_addr for one).
>
> The original vme_master and vme_slave structs would be different
Hi all,
I think with this patch everything seems to be running fine now. The
kernel oops was actually caused by a bug in one of my userspace programs
(forgot to set the channel list in cmd) but of course that shouldn't
have been possible. That's now properly dealt with and we get a "bad
addre
On 05/12/13 00:29, Aaron Sierra wrote:
>
> Martyn,
> Your suggestion resolves the kernel panic associated with the vme_user
> driver being initialized before the VME bus core driver, but it doesn't
> address the issue of the vme_user driver being registered before any
> buses have been probed:
>
On Wed, Dec 11, 2013 at 11:57:04AM +0200, Ivaylo Dimitrov wrote:
> On 11.12.2013 10:33, Dan Carpenter wrote:
> >On Wed, Dec 11, 2013 at 09:45:52AM +0200, Ivajlo Dimitrov wrote:
> >>I can pick your changes and re-send the original patch with them
> >>incorporated if there are no objections. Are you
On 2013-12-10 23:31, 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 upload.
Acked-by: Ian Abbott
On 11.12.2013 10:33, Dan Carpenter wrote:
On Wed, Dec 11, 2013 at 09:45:52AM +0200, Ivajlo Dimitrov wrote:
I can pick your changes and re-send the original patch with them
incorporated if there are no objections. Are you fine with that?
Do it on top of staging-next, don't redo the original.
r
Hi all,
I've drilled down further. After an async command has run the channel
list is kfree'd in do_become_nonbusy. The pointer is not NULL but I
guess that's been kfree'd already somewhere else and there is no need to
do it here?
The comedi_command_test is actually OK. Ignore the report her
On Wed, Dec 11, 2013 at 09:45:52AM +0200, Ivajlo Dimitrov wrote:
> I can pick your changes and re-send the original patch with them
> incorporated if there are no objections. Are you fine with that?
>
Do it on top of staging-next, don't redo the original.
regards,
dan carpenter
_
19 matches
Mail list logo
