The spectra driver doesn't compile with today linux-next
The problem is that it tries to use a blk_fs_request macro. Searching for this
macro I saw that it used to exist in linux/blkdev.h as
#define blk_fs_request(rq) ((rq)->cmd_type == REQ_TYPE_FS)
This patch solves the issue eliminating the u
Hi,
On Thu, Jun 24, 2010 at 09:45:38PM +0200, Jiri Slaby wrote:
> On 06/24/2010 08:02 PM, Charles Clément wrote:
> > Replace all occurrences with unsigned long type, except for pointer fields
> > that
> > should be u32 in packed structures and 8-byte-aligned 8 byte long structure
> > QWORD.
> >
Add another device ID as listed in the vendor driver version
0003.0825.2009.
Signed-off-by: Ben Hutchings
---
drivers/staging/rtl8192u/r8192U_core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U
Signed-off-by: Ben Hutchings
---
drivers/staging/rtl8192su/r8192U_core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/rtl8192su/r8192U_core.c
b/drivers/staging/rtl8192su/r8192U_core.c
index 15e9579..b69e198 100644
--- a/drivers/staging/rtl8192su/r8192U
On Thu, Jun 24, 2010 at 01:42:02AM +0100, Ben Hutchings wrote:
> On Tue, 2010-06-22 at 15:34 -0700, Greg KH wrote:
> > On Fri, Jun 18, 2010 at 01:00:35AM +0100, Ben Hutchings wrote:
> > > The rtl8192s_usb driver was claiming a number of device IDs which are
> > > actually supported by the code in t
fined reference to `snd_card_create'
Signed-off-by: Randy Dunlap
Cc: Ben Collins
---
drivers/staging/solo6x10/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20100624.orig/drivers/staging/solo6x10/Kconfig
+++ linux-next-20100624/drivers/staging/solo6x10/
Here's a list package on sale this week only:
Real Estate Agents - 1 million records with emails
USA Lawyers Database - 269,787 records with 235,244 emails
US New Business Database - 4.8 million records all with emails
American Consumer Database - 1,300,000 records all with emails
American Homeown
On 06/24/2010 08:02 PM, Charles Clément wrote:
> Replace all occurrences with unsigned long type, except for pointer fields
> that
> should be u32 in packed structures and 8-byte-aligned 8 byte long structure
> QWORD.
>
> Thanks to Jiri Slaby for pointing out that simply replacing by unsigned lon
On Thursday, June 24, 2010 10:38 AM, Joe Perches wrote:
> On Thu, 2010-06-24 at 09:31 -0700, H Hartley Sweeten wrote:
> The global symbol dt3155_fbuffer[], declared in dt3155_isr.c, is really
>> just a pointer to dt3155_status[].fbuffer. To improve readability, make
>> some of the really long lines
Hi,
> >> size_t memrar_allocator_largest_free_area(struct memrar_allocator
> *allocator)
> >> {
> >> - if (allocator == NULL)
> >> - return 0;
> >> - return allocator->largest_free_area;
> >> + size_t tmp = 0;
> >> +
> >> + if (allocator != NULL) {
> >> + mutex_lock(&allocato
On Thu, 2010-06-24 at 09:31 -0700, H Hartley Sweeten wrote:
> The global symbol dt3155_fbuffer[], declared in dt3155_isr.c, is really
> just a pointer to dt3155_status[].fbuffer. To improve readability, make
> some of the really long lines shorter, and make the buffer access more
> consistent, use
Hi Alan,
> > size_t memrar_allocator_largest_free_area(struct memrar_allocator
> *allocator)
> > {
> > - if (allocator == NULL)
> > - return 0;
> > - return allocator->largest_free_area;
> > + size_t tmp = 0;
> > +
> > + if (allocator != NULL) {
> > + mutex_lock(&allo
The global symbol dt3155_fbuffer[], declared in dt3155_isr.c, is really
just a pointer to dt3155_status[].fbuffer. To improve readability, make
some of the really long lines shorter, and make the buffer access more
consistent, use &dt3155_status[].fbuffer to access the buffer structure.
Signed-off
On 06/24/2010 09:23 PM, Randy Dunlap wrote:
> On 06/24/10 08:47, Nitin Gupta wrote:
>> On 06/24/2010 08:02 PM, Randy Dunlap wrote:
>>> On 06/23/10 21:36, Nitin Gupta wrote:
On 06/24/2010 08:57 AM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix 49 zram build errors in one swoop.
On 06/24/10 08:47, Nitin Gupta wrote:
> On 06/24/2010 08:02 PM, Randy Dunlap wrote:
>> On 06/23/10 21:36, Nitin Gupta wrote:
>>> On 06/24/2010 08:57 AM, Randy Dunlap wrote:
From: Randy Dunlap
Fix 49 zram build errors in one swoop. Examples:
drivers/staging/zram/zram_drv.c
On 06/24/2010 08:02 PM, Randy Dunlap wrote:
> On 06/23/10 21:36, Nitin Gupta wrote:
>> On 06/24/2010 08:57 AM, Randy Dunlap wrote:
>>> From: Randy Dunlap
>>>
>>> Fix 49 zram build errors in one swoop. Examples:
>>>
>>> drivers/staging/zram/zram_drv.c:225: error: dereferencing pointer to
>>> inco
On 06/23/10 21:36, Nitin Gupta wrote:
> On 06/24/2010 08:57 AM, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> Fix 49 zram build errors in one swoop. Examples:
>>
>> drivers/staging/zram/zram_drv.c:225: error: dereferencing pointer to
>> incomplete type
>> drivers/staging/zram/zram_drv.c:226: e
On 24.6.2010, at 12.09, Alan Cox wrote:
>> size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
>> {
>> -if (allocator == NULL)
>> -return 0;
>> -return allocator->largest_free_area;
>> +size_t tmp = 0;
>> +
>> +if (allocator != NULL) {
>> +
On 24.6.2010, at 12.16, Alan Cox wrote:
>> +size_t memrar_allocator_largest_free_area(struct memrar_allocator
>> *allocator)
>> +{
>> +if (allocator == NULL)
>> +return 0;
>> +return allocator->largest_free_area;
>> +}
>
> static ?
The entire point of these two patches was t
> +size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
> +{
> + if (allocator == NULL)
> + return 0;
> + return allocator->largest_free_area;
> +}
static ?
___
devel mailing list
devel@linuxdriverproject.org
> size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
> {
> - if (allocator == NULL)
> - return 0;
> - return allocator->largest_free_area;
> + size_t tmp = 0;
> +
> + if (allocator != NULL) {
> + mutex_lock(&allocator->lock);
> +
On 06/24/2010 01:15 AM, Charles Clément wrote:
> Yes, no problem, although won't just changing these to u32 for the first
> case take the problem elsewhere in the driver?
No, it can't. As Greg wrote, apparently it has never ever been tested on
64-bit (it wouldn't work) and long on 32-bit is 32-bit
Fixed memrar_handler.c to use the new memrar_allocator API. Removed
the corresponding issue from TODO. Implemented locking in
memrar_allocator_largest_free_area().
Signed-off-by: Henri Häkkinen largest_free_area;
+ size_t tmp = 0;
+
+ if (allocator != NULL) {
+ mutex_lo
Forward declared memrar_allocator structure in memrar_allocator.h and
moved the definition to memrar_allocator.c. Implemented
memrar_allocator_capacity() and memrar_allocator_largest_free_area().
Signed-off-by: Henri Häkkinen
---
drivers/staging/memrar/memrar_allocator.c | 43 +
24 matches
Mail list logo
