From: Micky Ching
Add cancel_work_sync() in rtsx_pci_ms_drv_remove(). Using
cancel_work_sync() to cancel pending request handle work when remove
driver.
Signed-off-by: Micky Ching
---
drivers/memstick/host/rtsx_pci_ms.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/memstick/ho
Hello!
On Jun 4, 2014, at 8:34 PM, David Rientjes wrote:
> @@ -5850,23 +5851,39 @@ int percpu_pagelist_fraction_sysctl_handler(ctl_table
> *table, int write,
> void __user *buffer, size_t *length, loff_t *ppos)
> {
> struct zone *zone;
> - unsigned int cpu;
> + int old_percpu_
Dear All,
I came across the link here and decided to write to you, as I am
facing a very similar problem:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-May/037941.html
With the above linux, I have recompiled the kernel and booting the
image with a vme_user.bus=0 vme_tsi14
Added a guaranteed null-terminate after call to strncpy.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/staging/usbip/stub_main.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/usbip/stub_main.c
Hi,
On Wed, Jun 04, 2014 at 06:03:36PM +0300, Eli Billauer wrote:
> I believe that I need a managed dma_map_single() my own driver,
> which doesn't fall in the case of a single use: The driver allocates
> its buffers with __get_free_pages() (or the to-be managed version of
> it). Then it cuts the
On 2014-06-04 19:30, Hartley Sweeten wrote:
On Wednesday, June 04, 2014 11:17 AM, Ian Abbott wrote:
On 2014-05-29 18:38, H Hartley Sweeten wrote:
Introduce a helper function to return the number of bytes that are
ready to read/write from/to the comedi_async buffer. The "write to"
use doesn't re
On 2014-05-29 18:45, H Hartley Sweeten wrote:
Add an (*insn_config) to the counter subdevice to allow the user to select
the clock source for the counters using the INSN_CONFIG_SET_CLOCK_SRC
instruction. The current selection can be queried with the instruction
INSN_CONFIG_GET_CLOCK_SRC.
Also, h
On 2014-05-29 18:42, H Hartley Sweeten wrote:
The Diamond Systems ONYX-MM-DIO board is a PC/104 module with two 8255
chips providing 48 digital I/O channels.
This board can be supported by the pcl724 driver.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
Reviewed-by
On 2014-05-29 18:42, H Hartley Sweeten wrote:
The Diamond Systems IR104-PBF board is a PC/104 module with 20
optoisolated inputs and 20 relay outputs.
This board can be supported by the pcl730 driver.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
Reviewed-by: Ian A
On Wednesday, June 04, 2014 11:17 AM, Ian Abbott wrote:
> On 2014-05-29 18:38, H Hartley Sweeten wrote:
>> Introduce a helper function to return the number of bytes that are
>> ready to read/write from/to the comedi_async buffer. The "write to"
>> use doesn't really make much sense but is handled f
On 2014-05-29 18:38, H Hartley Sweeten wrote:
Introduce a helper function to return the number of bytes that are
ready to read/write from/to the comedi_async buffer. The "write to"
use doesn't really make much sense but is handled for completeness.
Use the helper function in the comedi drivers t
This removes stack arrays of variable length and use kmalloc() instead, thus
removing the sparse warnings "Variable length array is used".
Signed-off-by: Remi Pommarel
---
drivers/staging/rtl8821ae/efuse.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions
On 2014-05-29 18:35, H Hartley Sweeten wrote:
The functions pci9111_trigger_source_set(), pci9111_pretrigger_set(),
and pci9111_autoscan_set() are all used to select the A/D trigger type.
They all do a read/mask/set/write of the A/D Trigger Mode Control register.
Simplify the code by removing th
On 2014-05-29 18:35, H Hartley Sweeten wrote:
This define is only used in the pci_device_id table and doesn't add
any additional clarity to the code. Remove the define and just open
code the value.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
Reviewed-by: Ian Abbot
On 2014-05-29 18:35, H Hartley Sweeten wrote:
This define is only used in a comedi_error() message. The addition of
the driver name to the message is not necessary. Remove the define.
For aesthetics, convert the comedi_error() into a dev_dbg().
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Wednesday, June 4, 2014 10:02 AM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; a...@canonical.com;
> de...@linuxdriverproject.org; h...@infradead.org; linux-
> s...@vger.kernel.org; oher...@su
On Wed, 2014-06-04 at 09:33 -0700, K. Y. Srinivasan wrote:
> Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to derive the
> FLUSH_TIMEOUT from the basic I/O timeout. However, this patch did not use the
> basic I/O timeout of the device. Fix this bug.
>
> Signed-off-by: K. Y. Sriniv
On 2014-05-29 18:29, H Hartley Sweeten wrote:
Many of the ADDI-DATA drivers have been separated from the "addi_common"
code and cleaned up. Because of this cleanup there are some unnecessary
members hanging around in the private data struct and a number of defines
that don't add any sigificant cl
Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to derive the
FLUSH_TIMEOUT from the basic I/O timeout. However, this patch did not use the
basic I/O timeout of the device. Fix this bug.
Signed-off-by: K. Y. Srinivasan
---
drivers/scsi/sd.c |4 +++-
1 files changed, 3 insertio
On Wed, Jun 04, 2014 at 08:28:36PM +0530, Adithya.K wrote:
> From: Adithya K
>
> Fixed few checkpatch.pl warnings.
Be specific about _what_ warnings you fixed. And if you fix more than
one type of warning, please break it up into different patches (each
patch only can do one thing.)
> Signed-o
Hi,
I believe that I need a managed dma_map_single() my own driver, which
doesn't fall in the case of a single use: The driver allocates its
buffers with __get_free_pages() (or the to-be managed version of it).
Then it cuts the allocated memory into smaller buffers (in some cases,
and with ce
From: Adithya K
Fixed few checkpatch.pl warnings.
Signed-off-by: Adithya K
---
drivers/staging/tidspbridge/pmgr/chnl.c |1 +
drivers/staging/tidspbridge/pmgr/dspapi.c |8
drivers/staging/tidspbridge/rmgr/dbdcd.c |1 +
drivers/staging/tidspbridge/rmgr/nldr.c |2 +-
Hello,
On Wed, Jun 04, 2014 at 04:12:11PM +0200, Joerg Roedel wrote:
> Yes, but those drivers usually get DMA buffers at init time with the
> dma_alloc_* interfaces. The dma_map_* interfaces discussed here belong
> to the streaming DMA-API, so they are usually used for only one DMA
> transaction b
On Wed, Jun 04, 2014 at 10:04:08AM -0400, Tejun Heo wrote:
> Hmmm? Don't we have drivers which map dma buffers on device init and
> release them on exit? For dynamic usages, its usefulness is limited
> especially given that dynamic tracking of buffers usually would
> involve tracking of other inf
Hello,
On Wed, Jun 04, 2014 at 01:39:07AM +0200, Joerg Roedel wrote:
> I fully agree with the points Shuah brought up here. I don't think it is
> a good idea to add this kind of resource management to runtime-allocated
> (and de-allocated) resources of device drivers.
>
> Also DMA handles are not
From: Julia Lawall
> On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
>
> > Hi Julia,
> >
> > On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall wrote:
> > > OK, thanks. I was only looking at the C code.
> > >
> > > But the C code contains a loop that is followed by:
> > >
> > > if (!size)
> > >
On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
> Hi Julia,
>
> On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall wrote:
> > OK, thanks. I was only looking at the C code.
> >
> > But the C code contains a loop that is followed by:
> >
> > if (!size)
> > return result;
> >
Hi Julia,
On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall wrote:
> OK, thanks. I was only looking at the C code.
>
> But the C code contains a loop that is followed by:
>
> if (!size)
> return result;
> tmp = *p;
>
> found_first:
> tmp |= ~0UL << size;
>
On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
> Hi Julia,
>
> On Wed, Jun 4, 2014 at 11:52 AM, Julia Lawall wrote:
> >> Maybe the documented return code should be changed to allow for the
> >> existing behaviour.
> >
> > Sorry, I'm not sure to understand what you suggest here.
>
> include/asm-g
Hi Julia,
On Wed, Jun 4, 2014 at 11:52 AM, Julia Lawall wrote:
>> Maybe the documented return code should be changed to allow for the
>> existing behaviour.
>
> Sorry, I'm not sure to understand what you suggest here.
include/asm-generic/bitops/find.h:
| /**
| * find_first_zero_bit - find the
On Wed, 4 Jun 2014, David Laight wrote:
> From: Julia Lawall
> > On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
> >
> > > Hi Julia,
> > >
> > > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall
> > > wrote:
> > > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> > > > ret
Hi Dave,
The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987:
Linux 3.15-rc3 (2014-04-27 19:29:27 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git topic/ipu-destaging
for you to fetch changes up to d6ca8ca7ec555bdd3372687d0d7
From: Julia Lawall
> On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
>
> > Hi Julia,
> >
> > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall wrote:
> > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> > > return a larger number than the maximum position argument if that po
On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
> Hi Julia,
>
> On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall wrote:
> > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> > return a larger number than the maximum position argument if that position
> > is not a multiple of
Hi Julia,
On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall wrote:
> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> return a larger number than the maximum position argument if that position
> is not a multiple of BITS_PER_LONG.
Shouldn't this be fixed in find_first_zero_
Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
return a larger number than the maximum position argument if that position
is not a multiple of BITS_PER_LONG.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.l
From: Julia Lawall
Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
return a larger number than the maximum position argument if that position
is not a multiple of BITS_PER_LONG.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@
37 matches
Mail list logo
