Re: [PATCH 4/9] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY
On Tue, Mar 17, 2015 at 05:41:56PM -0700, K. Y. Srinivasan wrote: > From: Nick Meier > > HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number. Depending on the usage context, > the value may be truncated. This patch is in response from the following > email from Intel: Subject should have "hv:" at the beginning :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/9] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY
On Tue, Mar 17, 2015 at 05:41:56PM -0700, K. Y. Srinivasan wrote: > From: Nick Meier > > HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number. Depending on the usage context, > the value may be truncated. This patch is in response from the following > email from Intel: "from Intel:" is really vague, please be nice and report who told you about this problem. > > [char-misc:char-misc-testing 25/45] drivers/hv/vmbus_drv.c:67:9: sparse: >constant 0x8000 is so big it is unsigned long > > tree: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > char-misc-testing > head: b3de8e3719e582f3182bb504295e4a8e43c8c96f > commit: 96c1d0581d00f7abe033350edb021a9d947d8d81 [25/45] Drivers: hv: > vmbus: Add support for VMBus panic notifier handler > reproduce: > # apt-get install sparse > git checkout 96c1d0581d00f7abe033350edb021a9d947d8d81 > make ARCH=x86_64 allmodconfig > make C=1 CF=-D__CHECK_ENDIAN__ > > sparse warnings: (new ones prefixed by >>) > > drivers/hv/vmbus_drv.c:67:9: sparse: constant 0x8000 is so > big it is unsigned long > ... > > The current char-next branch is broken and this patch fixes > the bug. > > Signed-off-by: Nick Meier > Signed-off-by: K. Y. Srinivasan You forgot a "Reported-by:" here. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: sm750fb: Fixed no space and indent warns
On Mon, Mar 16, 2015 at 10:16:09PM -0700, Ragavendra Nagraj wrote: > This patch fixes the no spaces and indent warnings identified by the > checkpath.pl script for the entire ddk750_chip.c file by using > appropriate tab spaces and indents accordingly. your patch is no longer applying to linux-next. please refresh it against staging-testing. regards sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/6] staging: sm750fb: Remove spinlock helper function
On Wed, Mar 11, 2015 at 03:03:39PM +, Lorenzo Stoakes wrote: > On 11 March 2015 at 14:58, Sudip Mukherjee wrote: > > I am more than happy to resend the whole series as necessary if that > makes it easier for Greg or anyone else :) I have previously > resubmitted an entire patch series only for people to find the v2 > resubmits of unchanged code to be confusing. I am absolutely happy to > do whatever works for Greg of course! your series is not applying anymore to linux-next. looks like some patches came from the Outreachy and were already applied. please redo it against staging-testing. regards sudip > > Best, > > -- > Lorenzo Stoakes > https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/6] staging: sm750fb: Remove spinlock helper function
On 18 March 2015 at 07:52, Sudip Mukherjee wrote: > your series is not applying anymore to linux-next. > looks like some patches came from the Outreachy and were already > applied. > please redo it against staging-testing. Will do that now! I think at this point it'll be easier for me to resend the whole series to make it clear which is applicable right now. Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
This patch uses memset_io instead of memset when using memset on __iomem
qualified pointers. This fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1
(different address spaces)
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/sm750.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..3e36b6a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)
crtc->cursor.share = share;
-memset(crtc->cursor.vstart, 0, crtc->cursor.size);
+memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if(!g_hwcursor){
lynxfb_ops.fb_cursor = NULL;
crtc->cursor.disable(&crtc->cursor);
@@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
}
#endif
- memset(share->pvMem,0,share->vidmem_size);
+ memset_io(share->pvMem,0,share->vidmem_size);
pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
--
2.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND 2/5] staging: sm750fb: Make internal functions static
This patch declares externally unavailable functions static. This fixes
the following sparse warnings:-
drivers/staging/sm750fb/ddk750_swi2c.c:223:6: warning: symbol 'swI2CStart' was
not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:234:6: warning: symbol 'swI2CStop' was
not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:252:6: warning: symbol 'swI2CWriteByte'
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:320:15: warning: symbol 'swI2CReadByte'
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:361:6: warning: symbol
'swI2CInit_SM750LE' was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:63:6: warning: symbol 'hwI2CWaitTXDone'
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:93:14: warning: symbol 'hwI2CWriteData'
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:160:14: warning: symbol 'hwI2CReadData'
was not declared. Should it be static?
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 6 +++---
drivers/staging/sm750fb/ddk750_swi2c.c | 10 +-
drivers/staging/sm750fb/sm750_accel.c | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 84dfb6f..7826376 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -60,7 +60,7 @@ void hwI2CClose(void)
}
-long hwI2CWaitTXDone(void)
+static long hwI2CWaitTXDone(void)
{
unsigned int timeout;
@@ -90,7 +90,7 @@ long hwI2CWaitTXDone(void)
* Return Value:
* Total number of bytes those are actually written.
*/
-unsigned int hwI2CWriteData(
+static unsigned int hwI2CWriteData(
unsigned char deviceAddress,
unsigned int length,
unsigned char *pBuffer
@@ -157,7 +157,7 @@ unsigned int hwI2CWriteData(
* Return Value:
* Total number of actual bytes read from the slave device
*/
-unsigned int hwI2CReadData(
+static unsigned int hwI2CReadData(
unsigned char deviceAddress,
unsigned int length,
unsigned char *pBuffer
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 1249759..516f5bb 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -220,7 +220,7 @@ static void swI2CAck(void)
/*
* This function sends the start command to the slave device
*/
-void swI2CStart(void)
+static void swI2CStart(void)
{
/* Start I2C */
swI2CSDA(1);
@@ -231,7 +231,7 @@ void swI2CStart(void)
/*
* This function sends the stop command to the slave device
*/
-void swI2CStop(void)
+static void swI2CStop(void)
{
/* Stop the I2C */
swI2CSCL(1);
@@ -249,7 +249,7 @@ void swI2CStop(void)
* 0 - Success
* -1 - Fail to write byte
*/
-long swI2CWriteByte(unsigned char data)
+static long swI2CWriteByte(unsigned char data)
{
unsigned char value = data;
int i;
@@ -317,7 +317,7 @@ long swI2CWriteByte(unsigned char data)
* Return Value:
* One byte data read from the Slave device
*/
-unsigned char swI2CReadByte(unsigned char ack)
+static unsigned char swI2CReadByte(unsigned char ack)
{
int i;
unsigned char data = 0;
@@ -358,7 +358,7 @@ unsigned char swI2CReadByte(unsigned char ack)
* -1 - Fail to initialize the i2c
* 0 - Success
*/
-long swI2CInit_SM750LE(
+static long swI2CInit_SM750LE(
unsigned char i2cClkGPIO,
unsigned char i2cDataGPIO
)
--
2.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND 5/5] staging: sm750fb: Remove spinlock helper function
This patch removes the unnecessary spinlock helper function and instead
calls spin_lock and spin_unlock directly.
This does *not* resolve sparse warnings about context imbalances but these are
spurious.
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/sm750.c | 53 +++--
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index be35429..a6658e1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -56,23 +56,6 @@ static char * g_settings = NULL;
static int g_dualview;
static char * g_option = NULL;
-/* if not use spin_lock,system will die if user load driver
- * and immediatly unload driver frequently (dual)*/
-static inline void myspin_lock(spinlock_t * sl){
- struct lynx_share * share;
- share = container_of(sl,struct lynx_share,slock);
- if(share->dual){
- spin_lock(sl);
- }
-}
-
-static inline void myspin_unlock(spinlock_t * sl){
- struct lynx_share * share;
- share = container_of(sl,struct lynx_share,slock);
- if(share->dual){
- spin_unlock(sl);
- }
-}
static const struct fb_videomode lynx750_ext[] = {
/* 1024x600-60 VESA[1.71:1]*/
{NULL, 60, 1024, 600, 20423, 144, 40, 18, 1, 104, 3,
@@ -209,13 +192,21 @@ static void lynxfb_ops_fillrect(struct fb_info*
info,const struct fb_fillrect* r
color = (Bpp ==
1)?region->color:((u32*)info->pseudo_palette)[region->color];
rop = ( region->rop != ROP_COPY ) ? HW_ROP2_XOR:HW_ROP2_COPY;
- myspin_lock(&share->slock);
+ /*
+* If not use spin_lock,system will die if user load driver
+* and immediatly unload driver frequently (dual)
+*/
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_fillrect(&share->accel,
base,pitch,Bpp,
region->dx,region->dy,
region->width,region->height,
color,rop);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea
* region)
@@ -233,12 +224,20 @@ static void lynxfb_ops_copyarea(struct fb_info *
info,const struct fb_copyarea *
pitch = info->fix.line_length;
Bpp = info->var.bits_per_pixel >> 3;
- myspin_lock(&share->slock);
+ /*
+* If not use spin_lock, system will die if user load driver
+* and immediatly unload driver frequently (dual)
+*/
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_copyarea(&share->accel,
base,pitch,region->sx,region->sy,
base,pitch,Bpp,region->dx,region->dy,
region->width,region->height,HW_ROP2_COPY);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image*
image)
@@ -272,14 +271,22 @@ static void lynxfb_ops_imageblit(struct
fb_info*info,const struct fb_image* imag
}
return;
_do_work:
- myspin_lock(&share->slock);
+ /*
+* If not use spin_lock, system will die if user load driver
+* and immediatly unload driver frequently (dual)
+*/
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_imageblit(&share->accel,
image->data,image->width>>3,0,
base,pitch,Bpp,
image->dx,image->dy,
image->width,image->height,
fgcol,bgcol,HW_ROP2_COPY);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
--
2.3.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND 3/5] staging: sm750fb: Remove unused function
This patch removes the unused hw712_fillrect function. This patch fixes
the following sparse warning:-
drivers/staging/sm750fb/sm750_accel.c:95:5: warning: symbol 'hw712_fillrect'
was not declared. Should it be static?
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/sm750_accel.c | 78 ---
1 file changed, 78 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index 6521c3b..c5a3726 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -89,84 +89,6 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt)
write_dpr(accel,DE_STRETCH_FORMAT,reg);
}
-/* seems sm712 RectFill command is broken,so need use BitBlt to
- * replace it. */
-
-int hw712_fillrect(struct lynx_accel * accel,
- u32 base,u32 pitch,u32 Bpp,
- u32 x,u32 y,u32 width,u32 height,
- u32 color,u32 rop)
-{
- u32 deCtrl;
- if(accel->de_wait() != 0)
- {
- /* int time wait and always busy,seems hardware
-* got something error */
- pr_debug("%s:De engine always bussy\n",__func__);
- return -1;
- }
- /* 24bpp 2d acceleration still not work,we already support 2d on
-* both 8/16/32 bpp now, so there is no harm if we disable 2d on
-* 24bpp for current stage. */
-#if 0
- if(Bpp == 3){
- width *= 3;
- x *= 3;
- write_dpr(accel,DE_PITCH,
- FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch)|
- FIELD_VALUE(0,DE_PITCH,SOURCE,pitch));//dpr10
- }
- else
-#endif
- {
- write_dpr(accel,DE_PITCH,
- FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch/Bpp)|
- FIELD_VALUE(0,DE_PITCH,SOURCE,pitch/Bpp));//dpr10
-
- }
-
- write_dpr(accel,DE_FOREGROUND,color);//DPR14
- write_dpr(accel,DE_MONO_PATTERN_HIGH,~0);//DPR34
- write_dpr(accel,DE_MONO_PATTERN_LOW,~0);//DPR38
-
- write_dpr(accel,DE_WINDOW_SOURCE_BASE,base);//dpr44
- write_dpr(accel,DE_WINDOW_DESTINATION_BASE,base);//dpr40
-
-
- write_dpr(accel,DE_WINDOW_WIDTH,
- FIELD_VALUE(0,DE_WINDOW_WIDTH,DESTINATION,pitch/Bpp)|
- FIELD_VALUE(0,DE_WINDOW_WIDTH,SOURCE,pitch/Bpp));//dpr3c
-
-
- write_dpr(accel,DE_DESTINATION,
- FIELD_SET(0,DE_DESTINATION,WRAP,DISABLE)|
- FIELD_VALUE(0,DE_DESTINATION,X,x)|
- FIELD_VALUE(0,DE_DESTINATION,Y,y));//dpr4
-
- write_dpr(accel,DE_DIMENSION,
- FIELD_VALUE(0,DE_DIMENSION,X,width)|
- FIELD_VALUE(0,DE_DIMENSION,Y_ET,height));//dpr8
-
- deCtrl =
- FIELD_SET(0,DE_CONTROL,STATUS,START)|
- FIELD_SET(0,DE_CONTROL,COMMAND,BITBLT)|
- FIELD_SET(0,DE_CONTROL,ROP2_SOURCE,PATTERN)|
- FIELD_SET(0,DE_CONTROL,ROP_SELECT,ROP2)|
- FIELD_VALUE(0,DE_CONTROL,ROP,rop);//dpr0xc
-#if 0
- /* dump registers */
- int i;
- inf_msg("x,y,w,h = %d,%d,%d,%d\n",x,y,width,height);
- for(i=0x04;i<=0x44;i+=4){
- inf_msg("dpr%02x = %08x\n",i,read_dpr(accel,i));
- }
- inf_msg("deCtrl = %08x\n",deCtrl);
-#endif
-
- write_dpr(accel,DE_CONTROL,deCtrl);
- return 0;
-}
-
int hw_fillrect(struct lynx_accel * accel,
u32 base,u32 pitch,u32 Bpp,
u32 x,u32 y,u32 width,u32 height,
--
2.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND 4/5] staging: sm750fb: Fix __iomem pointer types
This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address
space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address
space of expression
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/sm750_cursor.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c
b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color,mask,opr;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem * pbuffer,*pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
/*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
}
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
#if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color, mask;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem * pbuffer,*pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
for(i=0;ihttp://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: i2o: Use kstrdup rather than duplicating its implementation
The semantic patch that makes this change is available
in scripts/coccinelle/api/kstrdup.cocci
Signed-off-by: Abdul Hussain S
---
drivers/staging/i2o/memory.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/i2o/memory.c b/drivers/staging/i2o/memory.c
index 8f9509d..78b702c 100644
--- a/drivers/staging/i2o/memory.c
+++ b/drivers/staging/i2o/memory.c
@@ -270,10 +270,9 @@ EXPORT_SYMBOL_GPL(i2o_dma_realloc);
int i2o_pool_alloc(struct i2o_pool *pool, const char *name,
size_t size, int min_nr)
{
- pool->name = kmalloc(strlen(name) + 1, GFP_KERNEL);
+ pool->name = kstrdup(name, GFP_KERNEL);
if (!pool->name)
goto exit;
- strcpy(pool->name, name);
pool->slab =
kmem_cache_create(pool->name, size, 0, SLAB_HWCACHE_ALIGN, NULL);
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
Hello, My name is Lina duc Kien,the daughter of Nguyen Duc Kien.I look very good before writing you and I am sorry i do not write english good.I want to know if there is chance or project i can make with you in your country.why i am asking was that my father who co-founded the Asia Commercial Joint Stock Bank (ACB)was suspended and arrested. because of the problem my father have,the government is taking all his properties.I want to make investment in your country with his money before the government will seize all. I want to discuss with you confidentially,i can not use phone as the authority is monitoring my family to know if there is any asset under my father name. please make this confidential because authorities are watching on my family. I wait for your email back to me Kien ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
Hello, My name is Lina duc Kien,the daughter of Nguyen Duc Kien.I look very good before writing you and I am sorry i do not write english good.I want to know if there is chance or project i can make with you in your country.why i am asking was that my father who co-founded the Asia Commercial Joint Stock Bank (ACB)was suspended and arrested. because of the problem my father have,the government is taking all his properties.I want to make investment in your country with his money before the government will seize all. I want to discuss with you confidentially,i can not use phone as the authority is monitoring my family to know if there is any asset under my father name. please make this confidential because authorities are watching on my family. I wait for your email back to me Kien ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
Hello, My name is Lina duc Kien,the daughter of Nguyen Duc Kien.I look very good before writing you and I am sorry i do not write english good.I want to know if there is chance or project i can make with you in your country.why i am asking was that my father who co-founded the Asia Commercial Joint Stock Bank (ACB)was suspended and arrested. because of the problem my father have,the government is taking all his properties.I want to make investment in your country with his money before the government will seize all. I want to discuss with you confidentially,i can not use phone as the authority is monitoring my family to know if there is any asset under my father name. please make this confidential because authorities are watching on my family. I wait for your email back to me Kien ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] staging: sm750fb: Fixed no space and indent warns
This patch fixes the no spaces and indent warnings identified by the
checkpath.pl script for the entire ddk750_chip.c file by using
appropriate tab spaces and indents accordingly.
Signed-off-by: Ragavendra Nagraj
---
Changes in v5:
- Created patch for latest staging-next branch.
drivers/staging/sm750fb/ddk750_chip.c | 460 -
1 file changed, 230 insertions(+), 230 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c
b/drivers/staging/sm750fb/ddk750_chip.c
index 33add64..02f9326 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -20,22 +20,22 @@ logical_chip_type_t getChipType(void)
physicalID = devId750;//either 0x718 or 0x750
physicalRev = revId750;
-if (physicalID == 0x718)
-{
-chip = SM718;
-}
-else if (physicalID == 0x750)
-{
-chip = SM750;
+ if (physicalID == 0x718)
+ {
+ chip = SM718;
+ }
+ else if (physicalID == 0x750)
+ {
+ chip = SM750;
/* SM750 and SM750LE are different in their revision ID only. */
if (physicalRev == SM750LE_REVISION_ID){
chip = SM750LE;
}
-}
-else
-{
-chip = SM_UNKNOWN;
-}
+ }
+ else
+ {
+ chip = SM_UNKNOWN;
+ }
return chip;
}
@@ -43,63 +43,63 @@ logical_chip_type_t getChipType(void)
inline unsigned int twoToPowerOfx(unsigned long x)
{
-unsigned long i;
-unsigned long result = 1;
+ unsigned long i;
+ unsigned long result = 1;
-for (i=1; i<=x; i++)
-result *= 2;
-return result;
+ for (i=1; i<=x; i++)
+ result *= 2;
+ return result;
}
inline unsigned int calcPLL(pll_value_t *pPLL)
{
-return (pPLL->inputFreq * pPLL->M / pPLL->N / twoToPowerOfx(pPLL->OD) /
twoToPowerOfx(pPLL->POD));
+ return (pPLL->inputFreq * pPLL->M / pPLL->N / twoToPowerOfx(pPLL->OD) /
twoToPowerOfx(pPLL->POD));
}
unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL)
{
-unsigned int ulPllReg = 0;
-
-pPLL->inputFreq = DEFAULT_INPUT_CLOCK;
-pPLL->clockType = clockType;
-
-switch (clockType)
-{
-case MXCLK_PLL:
-ulPllReg = PEEK32(MXCLK_PLL_CTRL);
-break;
-case PRIMARY_PLL:
-ulPllReg = PEEK32(PANEL_PLL_CTRL);
-break;
-case SECONDARY_PLL:
-ulPllReg = PEEK32(CRT_PLL_CTRL);
-break;
-case VGA0_PLL:
-ulPllReg = PEEK32(VGA_PLL0_CTRL);
-break;
-case VGA1_PLL:
-ulPllReg = PEEK32(VGA_PLL1_CTRL);
-break;
-}
-
-pPLL->M = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, M);
-pPLL->N = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, N);
-pPLL->OD = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, OD);
-pPLL->POD = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, POD);
-
-return calcPLL(pPLL);
+ unsigned int ulPllReg = 0;
+
+ pPLL->inputFreq = DEFAULT_INPUT_CLOCK;
+ pPLL->clockType = clockType;
+
+ switch (clockType)
+ {
+ case MXCLK_PLL:
+ ulPllReg = PEEK32(MXCLK_PLL_CTRL);
+ break;
+ case PRIMARY_PLL:
+ ulPllReg = PEEK32(PANEL_PLL_CTRL);
+ break;
+ case SECONDARY_PLL:
+ ulPllReg = PEEK32(CRT_PLL_CTRL);
+ break;
+ case VGA0_PLL:
+ ulPllReg = PEEK32(VGA_PLL0_CTRL);
+ break;
+ case VGA1_PLL:
+ ulPllReg = PEEK32(VGA_PLL1_CTRL);
+ break;
+ }
+
+ pPLL->M = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, M);
+ pPLL->N = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, N);
+ pPLL->OD = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, OD);
+ pPLL->POD = FIELD_GET(ulPllReg, PANEL_PLL_CTRL, POD);
+
+ return calcPLL(pPLL);
}
unsigned int getChipClock(void)
{
-pll_value_t pll;
+ pll_value_t pll;
#if 1
if(getChipType() == SM750LE)
return MHz(130);
#endif
-return getPllValue(MXCLK_PLL, &pll);
+ return getPllValue(MXCLK_PLL, &pll);
}
@@ -110,75 +110,75 @@ unsigned int getChipClock(void)
*/
void setChipClock(unsigned int frequency)
{
-pll_value_t pll;
-unsigned int ulActualMxClk;
+ pll_value_t pll;
+ unsigned int ulActualMxClk;
#if 1
- /* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to
set. */
- if (getChipType() == SM750LE)
- return;
+ /* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
+ if (getChipType() == SM750LE)
+ return;
#endif
-if (frequency != 0)
-{
-/*
- * Set up PLL, a structure to hold the value to be set in clocks.
- */
-pll.inputFreq = DEFAULT_INPUT_CLOCK; /* Defined in CLOCK.H */
-pll.clockTyp
Re: [PATCH 4/4] staging/lustre: use __packed instead of __attribute__(packed)
On Tue, Mar 10, 2015 at 12:02:05PM -0300, Mario J. Rugiero wrote: > Replace __attribute__(packed) by __packed as suggested by checkpatch. > > Signed-off-by: Mario J. Rugiero > --- > .../include/linux/libcfs/libcfs_kernelcomm.h | 2 +- > .../staging/lustre/include/linux/lnet/lib-types.h | 2 +- > .../lustre/lustre/include/lustre/lustre_idl.h | 44 > +++--- > .../lustre/lustre/include/lustre/lustre_user.h | 14 +++ > 4 files changed, 31 insertions(+), 31 deletions(-) This patch also doesn't apply :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] staging/lustre: use __aligned(size) instead of __attribute__(aligned(size))
On Tue, Mar 10, 2015 at 12:02:04PM -0300, Mario J. Rugiero wrote:
> Replace uses of __attribute__(aligned(size)) by __aligned(size), as suggested
> by checkpatch.
>
> Signed-off-by: Mario J. Rugiero
> ---
> drivers/staging/lustre/include/linux/libcfs/libcfs_kernelcomm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_kernelcomm.h
> b/drivers/staging/lustre/include/linux/libcfs/libcfs_kernelcomm.h
> index f19a121..4688770 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_kernelcomm.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_kernelcomm.h
> @@ -58,7 +58,7 @@ struct kuc_hdr {
> __u8 kuc_flags;
> __u16 kuc_msgtype;/* Message type or opcode, transport-specific */
> __u16 kuc_msglen; /* Including header */
> -} __attribute__((aligned(sizeof(__u64;
> +} __aligned(sizeof(__u64));
>
> #define KUC_CHANGELOG_MSG_MAXSIZE (sizeof(struct kuc_hdr)+CR_MAXSIZE)
>
This patch doesn't apply to my tree :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
Why is there a RESEND in the subject. On Wed, Mar 18, 2015 at 08:57:22AM +, Lorenzo Stoakes wrote: > This patch uses memset_io instead of memset when using memset on __iomem > qualified pointers. This fixes the following sparse warnings:- > > drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 > (different address spaces) > drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 > (different address spaces) > drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 > (different address spaces) > drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 > (different address spaces) > drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 > (different address spaces) > drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 > (different address spaces) > This changelog still sucks. It doesn't describe the effect of this behavior change for the user. It doesn't even make it clear that you are aware that this is a behavior change. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 01:17:17PM +0300, Dan Carpenter wrote: > Why is there a RESEND in the subject. > > On Wed, Mar 18, 2015 at 08:57:22AM +, Lorenzo Stoakes wrote: > > This patch uses memset_io instead of memset when using memset on __iomem > > qualified pointers. This fixes the following sparse warnings:- > > > > drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument > > 1 (different address spaces) > > drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument > > 1 (different address spaces) > > drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument > > 1 (different address spaces) > > drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument > > 1 (different address spaces) > > drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument > > 1 (different address spaces) > > drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument > > 1 (different address spaces) > > > > This changelog still sucks. It doesn't describe the effect of this > behavior change for the user. It doesn't even make it clear that you > are aware that this is a behavior change. It doesn't say to me that you have asked yourself if the sparse annotations are correct. Many times they are wrong. We have had this discussion before but you still sent the same exact bad changelog. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: fix sparse warnings for static declaration
This patch fixes following sparse warning
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1924:6: warning: symbol
'ieee80211_check_auth_response' was not declared. Should it be static?
Signed-off-by: Vibi Sreenivasan
---
.../staging/rtl8192u/ieee80211/ieee80211_softmac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 9d57c65..9342765 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -1921,7 +1921,7 @@ static void ieee80211_process_action(struct
ieee80211_device *ieee,
}
-void ieee80211_check_auth_response(struct ieee80211_device *ieee,
+static void ieee80211_check_auth_response(struct ieee80211_device *ieee,
struct sk_buff *skb)
{
/* default support N mode, disable halfNmode */
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:18, Dan Carpenter wrote: >> >> This changelog still sucks. It doesn't describe the effect of this >> behavior change for the user. It doesn't even make it clear that you >> are aware that this is a behavior change. > > It doesn't say to me that you have asked yourself if the sparse > annotations are correct. Many times they are wrong. My understanding, which as a new contributor is of course limited and likely simply wrong in many aspects, is - these memset's are referring to I/O mapped memory, which as far as I can tell is actually the case here, so in order to make it explicit that this is the case and we know it is, we use memset_io. As far as I understand the pointers simply have a modifier applied which marks them as I/O mapped memory for the purposes of sparse checking whether they are used consistently as such and are not treated like they are a normal kernel pointer. In this case the cursor->vstart and crtc->vScreen pointers, looking through the source, explicitly refer to memory which is I/O mapped, and is annotated as __iomem accordingly throughout. I will update the message accordingly, obviously if I'm misunderstanding something let me know. > We have had this discussion before but you still sent the same exact > bad changelog. Actually you said:- > When I see a patch like this, then I worry, "What if the Sparse > annotations are wrong? The patch description doesn't say anything about > that." After review then I think the annotations are correct so that's > fine. And:- > Yes. The patch is correct. I wasn't asking you to redo it. From later > patches it's actually clear that you know that this change is a bugfix > and a behavior change. But we get a lot of patches where people just > randomly change things to please Sparse and it maybe silences a warning > but it's not correct. I can think of a few recentish examples where > people used standard struct types which hold __iomem or __user pointers > but they used them in non-standard ways so the pointers were actually > normal kernel pointers. So it wasn't clear *to me* you wanted me to change that, given you asked me *not* to redo it explicitly (which I assumed applied to the message too) - apologies if I misinterpreted this! Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:17, Dan Carpenter wrote: > Why is there a RESEND in the subject. To avoid confusion (and Sudip explicitly mentioned there might be some), and in addition I had to update my patch series to take into account that it no longer applied due to another patch which applies the ANSI C function prototype fixes having already been applied. Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
Lorenzo Stoakes writes:
> This patch uses memset_io instead of memset when using memset on __iomem
> qualified pointers. This fixes the following sparse warnings:-
>
> drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1
> (different address spaces)
>
> Signed-off-by: Lorenzo Stoakes
> ---
> drivers/staging/sm750fb/sm750.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index aa0888c..3e36b6a 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
> par = info->par;
> crtc = &par->crtc;
> cursor = &crtc->cursor;
> - memset(cursor->vstart, 0x0, cursor->size);
> - memset(crtc->vScreen,0x0,crtc->vidmem_size);
> + memset_io(cursor->vstart, 0x0, cursor->size);
> + memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
ERROR is reported by scripts/checkpatch.pl (spaces are missing after
','). This coding style problem was there before your patch but I don't
think it makes sense to preserve it.
> lynxfb_ops_set_par(info);
> fb_set_suspend(info, 0);
> }
> @@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
> par = info->par;
> crtc = &par->crtc;
> cursor = &crtc->cursor;
> - memset(cursor->vstart, 0x0, cursor->size);
> - memset(crtc->vScreen,0x0,crtc->vidmem_size);
> + memset_io(cursor->vstart, 0x0, cursor->size);
> + memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
the same
> lynxfb_ops_set_par(info);
> fb_set_suspend(info, 0);
> }
> @@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int
> index)
>
> crtc->cursor.share = share;
> -memset(crtc->cursor.vstart, 0, crtc->cursor.size);
> +memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
WARNING: please, no spaces at the start of a line
#137: FILE: drivers/staging/sm750fb/sm750.c:833:
+memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);$
> if(!g_hwcursor){
> lynxfb_ops.fb_cursor = NULL;
> crtc->cursor.disable(&crtc->cursor);
> @@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
> }
> #endif
>
> - memset(share->pvMem,0,share->vidmem_size);
> + memset_io(share->pvMem,0,share->vidmem_size);
the same missing spaces
>
> pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
>
> --
> 2.3.2
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 10:44:53AM +, Lorenzo Stoakes wrote: > On 18 March 2015 at 10:18, Dan Carpenter wrote: > >> > >> This changelog still sucks. It doesn't describe the effect of this > >> behavior change for the user. It doesn't even make it clear that you > >> are aware that this is a behavior change. > > > > It doesn't say to me that you have asked yourself if the sparse > > annotations are correct. Many times they are wrong. > > My understanding, which as a new contributor is of course limited and > likely simply wrong in many aspects, is - these memset's are referring > to I/O mapped memory, which as far as I can tell is actually the case > here, so in order to make it explicit that this is the case and we > know it is, we use memset_io. As far as I understand the pointers > simply have a modifier applied which marks them as I/O mapped memory > for the purposes of sparse checking whether they are used consistently > as such and are not treated like they are a normal kernel pointer. > > In this case the cursor->vstart and crtc->vScreen pointers, looking > through the source, explicitly refer to memory which is I/O mapped, > and is annotated as __iomem accordingly throughout. > > I will update the message accordingly, obviously if I'm > misunderstanding something let me know. This is all fine. > > > We have had this discussion before but you still sent the same exact > > bad changelog. > > Actually you said:- > > > When I see a patch like this, then I worry, "What if the Sparse > > annotations are wrong? The patch description doesn't say anything about > > that." After review then I think the annotations are correct so that's > > fine. > > And:- The patch is fine. The changelog is not. > > > Yes. The patch is correct. I wasn't asking you to redo it. From later > > patches it's actually clear that you know that this change is a bugfix > > and a behavior change. But we get a lot of patches where people just > > randomly change things to please Sparse and it maybe silences a warning > > but it's not correct. I can think of a few recentish examples where > > people used standard struct types which hold __iomem or __user pointers > > but they used them in non-standard ways so the pointers were actually > > normal kernel pointers. > > So it wasn't clear *to me* you wanted me to change that, given you > asked me *not* to redo it explicitly (which I assumed applied to the > message too) - apologies if I misinterpreted this! I often say "don't resend" because something is minor and I don't want to slow you down but since you were resending it anyway then please fix it. Also changelogs are really easy to fix. In mutt, you can do it without leaving your email client. So I have revised my earlier statement, please fix it. :) regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:52, Dan Carpenter wrote: > I often say "don't resend" because something is minor and I don't want > to slow you down but since you were resending it anyway then please fix > it. Also changelogs are really easy to fix. In mutt, you can do it > without leaving your email client. So I have revised my earlier > statement, please fix it. :) Will do! I have experimented with mutt, I tend to just use git send-email directly at the moment and edit patch files manually and use the gmail web interface for reading/discussion, I am sure I will learn to do things a little more sanely in time, the hard way :) Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 10:46:52AM +, Lorenzo Stoakes wrote: > On 18 March 2015 at 10:17, Dan Carpenter wrote: > > Why is there a RESEND in the subject. > > To avoid confusion (and Sudip explicitly mentioned there might be > some), and in addition I had to update my patch series to take into > account that it no longer applied due to another patch which applies > the ANSI C function prototype fixes having already been applied. Btw, sorry for coming down hard on you. You're a newbie and expected to make these mistakes. Your patches are good and appreciated. Call it a v2 patch. Put a note under the --- cut off line: v2: updated to apply to latest linux-next http://kernelnewbies.org/PatchTipsAndTricks regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:50, Vitaly Kuznetsov wrote: > ERROR is reported by scripts/checkpatch.pl (spaces are missing after > ','). This coding style problem was there before your patch but I don't > think it makes sense to preserve it. [snip] > WARNING: please, no spaces at the start of a line > #137: FILE: drivers/staging/sm750fb/sm750.c:833: [snip] Hi Vitaly, these style issues have vexed me and I was not sure whether to make changes or preserve all the obvious errors so as not to blend the two changes inappropriately, however it does indeed make sense to fix these on the lines I'm changing, will fix these! Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:59, Dan Carpenter wrote: > Btw, sorry for coming down hard on you. You're a newbie and expected to > make these mistakes. Your patches are good and appreciated. Thanks and no problem, I expect to receive robust criticism given the high standards in the kernel and see it as a means to improve my contributions :) > > Call it a v2 patch. Put a note under the --- cut off line: > v2: updated to apply to latest linux-next > > http://kernelnewbies.org/PatchTipsAndTricks > Great, thanks, will do! Very useful link! Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 11:12:20AM +, Lorenzo Stoakes wrote: > On 18 March 2015 at 10:50, Vitaly Kuznetsov wrote: > > ERROR is reported by scripts/checkpatch.pl (spaces are missing after > > ','). This coding style problem was there before your patch but I don't > > think it makes sense to preserve it. > > [snip] > > > WARNING: please, no spaces at the start of a line > > #137: FILE: drivers/staging/sm750fb/sm750.c:833: > > [snip] > > Hi Vitaly, these style issues have vexed me and I was not sure whether > to make changes or preserve all the obvious errors so as not to blend > the two changes inappropriately, however it does indeed make sense to > fix these on the lines I'm changing, will fix these! If it's a white space thing on the same line then it's generally ok to fix it. The "one thing per patch" is meant to make patches easier to review. If it's a trivial thing and it doesn't make it harder to review then we are reasonable people. Could you read your patches again and find other similar white space issues. + void __iomem * pbuffer,*pstart; Should be: + void __iomem *pbuffer, *pstart; regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Prezado usuário
Prezado usuário Seu e-mail excedeu 2 GB criado pelo webmaster, você está atualmente rodando a 2,30 GB, que não pode enviar ou receber mensagem nova dentro o próximo 24 horas até que você verificar que a conta de e-mail. Por favor, digite seus dados abaixo para verificar a sua conta: (1) e-mail: (2) nome: (3) senha: (4) confirme a senha: Obrigado Administrador do sistema ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] staging/lustre: use __aligned(size) instead of __attribute__(aligned(size))
I didn't expect that. Maybe I used the wrong linux-next? Just to make sure, what should I be making the patches against? I made them against the latest next branch I was able to find on Linus tree, is that right? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: dgnc: release the lock before testing for nullity
Fixes: c84a083b995b ("Staging: dgnc: Use goto for spinlock release before
return")
Signed-off-by: Quentin Lambert
---
drivers/staging/dgnc/dgnc_tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 8445f84ddaa3..f1c4d07a0aaa 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -656,9 +656,9 @@ void dgnc_input(struct channel_t *ch)
return;
exit_unlock:
+ spin_unlock_irqrestore(&ch->ch_lock, flags);
if (ld)
tty_ldisc_deref(ld);
- spin_unlock_irqrestore(&ch->ch_lock, flags);
}
--
2.3.2.223.g7a9409c
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: dgnc: release the lock before testing for nullity
This patch has no changelog. What's the bug?
On Wed, Mar 18, 2015 at 01:51:52PM +0100, Quentin Lambert wrote:
> Fixes: c84a083b995b ("Staging: dgnc: Use goto for spinlock release before
> return")
>
Don't put a blank line here.
> Signed-off-by: Quentin Lambert
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] staging/lustre: use __aligned(size) instead of __attribute__(aligned(size))
On Wed, Mar 18, 2015 at 09:30:24AM -0300, Mario J. Rugiero wrote: > I didn't expect that. Maybe I used the wrong linux-next? > Just to make sure, what should I be making the patches against? I made them > against the latest next branch I was able to find on Linus tree, is that > right? linux-next is usually the correct thing to use here, but note that I get lots of patches from lots of people and sometimes there are conflicts. Odds are someone had sent me patches that touched these files before you, and I applied them earlier in the day. If you want to work on staging patches, I suggest working off of my staging-testing branch of staging.git on git.kernel.org as that always has the latest set of patches I've accepted. There will always be conflicts at times, which is normal, but that should reduce them to a managable level. Hope this helps, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 02:25:09PM +0300, Dan Carpenter wrote: > On Wed, Mar 18, 2015 at 11:12:20AM +, Lorenzo Stoakes wrote: > > On 18 March 2015 at 10:50, Vitaly Kuznetsov wrote: > If it's a white space thing on the same line then it's generally ok to > fix it. The "one thing per patch" is meant to make patches easier to > review. If it's a trivial thing and it doesn't make it harder to review > then we are reasonable people. > but Greg K-H has explisitely mentiond not to do so. I did just that and fixed few whitespace things in the patch to fix the build failure. https://lkml.org/lkml/2015/3/10/685 regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging: dgnc: release the lock before testing for nullity
The refactoring intrduced in
c84a083b995b ("Staging: dgnc: Use goto for spinlock release before return")
inverts the order in which the lock is released and ld is tested for nullity.
This patch restores the execution flow.
Fixes: c84a083b995b ("Staging: dgnc: Use goto for spinlock release before
return")
Signed-off-by: Quentin Lambert
---
Changes since v1:
- the commit message details the point of the patch
- remove a blank line between the Fixes line and the signed-off line.
drivers/staging/dgnc/dgnc_tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 8445f84ddaa3..f1c4d07a0aaa 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -656,9 +656,9 @@ void dgnc_input(struct channel_t *ch)
return;
exit_unlock:
+ spin_unlock_irqrestore(&ch->ch_lock, flags);
if (ld)
tty_ldisc_deref(ld);
- spin_unlock_irqrestore(&ch->ch_lock, flags);
}
--
2.3.2.223.g7a9409c
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 06:36:07PM +0530, Sudip Mukherjee wrote: > On Wed, Mar 18, 2015 at 02:25:09PM +0300, Dan Carpenter wrote: > > On Wed, Mar 18, 2015 at 11:12:20AM +, Lorenzo Stoakes wrote: > > > On 18 March 2015 at 10:50, Vitaly Kuznetsov wrote: > > If it's a white space thing on the same line then it's generally ok to > > fix it. The "one thing per patch" is meant to make patches easier to > > review. If it's a trivial thing and it doesn't make it harder to review > > then we are reasonable people. > > > but Greg K-H has explisitely mentiond not to do so. > I did just that and fixed few whitespace things in the patch to fix the > build failure. > > https://lkml.org/lkml/2015/3/10/685 > You were making random white space changes and not on the same line. It was hard to review because you had to count how many u32 arguments there were (a million) and really look at it to see what the compile warning was. There was no compile warning in the end. Very annoying. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On Wed, Mar 18, 2015 at 04:23:39PM +0300, Dan Carpenter wrote: > > https://lkml.org/lkml/2015/3/10/685 > > > > You were making random white space changes and not on the same line. It > was hard to review because you had to count how many u32 arguments there > were (a million) and really look at it to see what the compile warning > was. There was no compile warning in the end. Very annoying. ok, now understood. Thanks. like you said once - combining different changes in a single patch is an art. :) regards sudip > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: dgnc: release the lock before testing for nullity
On Wed, Mar 18, 2015 at 02:21:08PM +0100, Quentin Lambert wrote:
> The refactoring intrduced in
> c84a083b995b ("Staging: dgnc: Use goto for spinlock release before return")
> inverts the order in which the lock is released and ld is tested for nullity.
>
> This patch restores the execution flow.
>
This changelog still doesn't make sense so I took a look at the code.
tty_ldisc_deref() is an unlock function. So this is a lock ordering
bug. What makes you think the original ordering was correct? Who
reported this bug? What are the effects of this bug?
Please answer the questions and we can work together on a proper fix if
needed.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: dgnc: release the lock before testing for nullity
On 18/03/2015 14:36, Dan Carpenter wrote: This changelog still doesn't make sense so I took a look at the code. tty_ldisc_deref() is an unlock function. So this is a lock ordering bug. What makes you think the original ordering was correct? Who reported this bug? What are the effects of this bug? I was the one who introduced the ordering change in the first place. I am just trying to fix it because although nobody complained I am not sure of the impact and restoring the previous control flow seems to be the right thing to do. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: dgnc: release the lock before testing for nullity
On Wed, Mar 18, 2015 at 02:43:01PM +0100, Quentin Lambert wrote: > > > On 18/03/2015 14:36, Dan Carpenter wrote: > >This changelog still doesn't make sense so I took a look at the code. > > > >tty_ldisc_deref() is an unlock function. So this is a lock ordering > >bug. What makes you think the original ordering was correct? Who > >reported this bug? What are the effects of this bug? > I was the one who introduced the ordering change in the first place. > I am just trying to fix it because although nobody complained I am not > sure of the impact and restoring the previous control flow seems to be the > right thing to do. Your changelog should tell me this stuff. The original code is wrong. We take "spin_lock_irqsave(&ch->ch_lock, flags);" before we do "ld = tty_ldisc_ref(tp);" so we should deref before we unlock. It's normally: lock_outer(); lock_inner(); unlock_inner(); unlock_outer(); On the success path we unlock first then deref and that is a mistake. This kind of change is a bit dangerous though so it requires testing. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: dgnc: release the lock before testing for nullity
On 18/03/2015 14:54, Dan Carpenter wrote: On Wed, Mar 18, 2015 at 02:43:01PM +0100, Quentin Lambert wrote: On 18/03/2015 14:36, Dan Carpenter wrote: This changelog still doesn't make sense so I took a look at the code. tty_ldisc_deref() is an unlock function. So this is a lock ordering bug. What makes you think the original ordering was correct? Who reported this bug? What are the effects of this bug? I was the one who introduced the ordering change in the first place. I am just trying to fix it because although nobody complained I am not sure of the impact and restoring the previous control flow seems to be the right thing to do. Your changelog should tell me this stuff. Should I send a third version then? The original code is wrong. We take "spin_lock_irqsave(&ch->ch_lock, flags);" before we do "ld = tty_ldisc_ref(tp);" so we should deref before we unlock. It's normally: lock_outer(); lock_inner(); unlock_inner(); unlock_outer(); On the success path we unlock first then deref and that is a mistake. I didn't know that thank you. This kind of change is a bit dangerous though so it requires testing. Ok, should I act on that? What do you advice? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: dgnc: release the lock before testing for nullity
I don't know anyone with this hardware who can test a patch. If you find someone then you should send a patch to reorder the other original unlock and deref. Otherwise, I would just leave it alone for now. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] clocking-wizard: fix one coding style problem.
On Mon, Feb 16, 2015 at 12:14:09AM +0700, Tan Nguyen wrote: > Added one line after variable declaration. > > Signed-off-by: Tan Nguyen > --- > drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 + > 1 file changed, 1 insertion(+) Patch does not apply to my tree, someone else already made this change a while ago :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 4/9] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, March 18, 2015 12:27 AM > To: KY Srinivasan > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; Nick Meier > Subject: Re: [PATCH 4/9] Correcting truncation error for constant > HV_CRASH_CTL_CRASH_NOTIFY > > On Tue, Mar 17, 2015 at 05:41:56PM -0700, K. Y. Srinivasan wrote: > > From: Nick Meier > > > > HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number. Depending on the > usage context, > > the value may be truncated. This patch is in response from the following > > email from Intel: > > "from Intel:" is really vague, please be nice and report who told you > about this problem. > > > > > [char-misc:char-misc-testing 25/45] drivers/hv/vmbus_drv.c:67:9: sparse: > >constant 0x8000 is so big it is unsigned long > > > > tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > char-misc-testing > > head: b3de8e3719e582f3182bb504295e4a8e43c8c96f > > commit: 96c1d0581d00f7abe033350edb021a9d947d8d81 [25/45] Drivers: > hv: vmbus: Add support for VMBus panic notifier handler > > reproduce: > > # apt-get install sparse > > git checkout 96c1d0581d00f7abe033350edb021a9d947d8d81 > > make ARCH=x86_64 allmodconfig > > make C=1 CF=-D__CHECK_ENDIAN__ > > > > sparse warnings: (new ones prefixed by >>) > > > > drivers/hv/vmbus_drv.c:67:9: sparse: constant 0x8000 is so > big it is unsigned long > > ... > > > > The current char-next branch is broken and this patch fixes > > the bug. > > > > Signed-off-by: Nick Meier > > Signed-off-by: K. Y. Srinivasan > > You forgot a "Reported-by:" here. Greg, Should I resend the set with corrections to this patch. Thanks, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/9] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY
On Wed, Mar 18, 2015 at 02:23:09PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Wednesday, March 18, 2015 12:27 AM > > To: KY Srinivasan > > Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; Nick Meier > > Subject: Re: [PATCH 4/9] Correcting truncation error for constant > > HV_CRASH_CTL_CRASH_NOTIFY > > > > On Tue, Mar 17, 2015 at 05:41:56PM -0700, K. Y. Srinivasan wrote: > > > From: Nick Meier > > > > > > HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number. Depending on the > > usage context, > > > the value may be truncated. This patch is in response from the following > > > email from Intel: > > > > "from Intel:" is really vague, please be nice and report who told you > > about this problem. > > > > > > > > [char-misc:char-misc-testing 25/45] drivers/hv/vmbus_drv.c:67:9: > > > sparse: > > >constant 0x8000 is so big it is unsigned > > > long > > > > > > tree: > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > char-misc-testing > > > head: b3de8e3719e582f3182bb504295e4a8e43c8c96f > > > commit: 96c1d0581d00f7abe033350edb021a9d947d8d81 [25/45] Drivers: > > hv: vmbus: Add support for VMBus panic notifier handler > > > reproduce: > > > # apt-get install sparse > > > git checkout 96c1d0581d00f7abe033350edb021a9d947d8d81 > > > make ARCH=x86_64 allmodconfig > > > make C=1 CF=-D__CHECK_ENDIAN__ > > > > > > sparse warnings: (new ones prefixed by >>) > > > > > > drivers/hv/vmbus_drv.c:67:9: sparse: constant 0x8000 is so > > big it is unsigned long > > > ... > > > > > > The current char-next branch is broken and this patch fixes > > > the bug. > > > > > > Signed-off-by: Nick Meier > > > Signed-off-by: K. Y. Srinivasan > > > > You forgot a "Reported-by:" here. > > Greg, > > Should I resend the set with corrections to this patch. Why wouldn't you? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH octeon-usb] fix 'line over 80 characters'
This file contained a warning of a line being over 80 characters and
so the file has been edited to remove that warning.
Signed-off-by: Amitoj Kaur Chawla
---
drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index 1daeb31..c8df0c3 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -2884,7 +2884,7 @@ static int __cvmx_usb_poll_channel(struct cvmx_usb_state
*usb, int channel)
pipe->pid_toggle = 1;
if (__cvmx_usb_pipe_needs_split(usb, pipe))
transaction->stage =
-
CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE;
+ CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE;
else {
struct usb_ctrlrequest *header =
cvmx_phys_to_ptr(transaction->control_header);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH octeon-usb] fix 'line over 80 characters'
On Wed, Mar 18, 2015 at 08:12:32PM +0530, Amitoj Kaur Chawla wrote: > > This file contained a warning of a line being over 80 characters and > so the file has been edited to remove that warning. > > Signed-off-by: Amitoj Kaur Chawla Why did you put the driver name within the []? It needs to go outside of it. > --- > drivers/staging/octeon-usb/octeon-hcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.c > b/drivers/staging/octeon-usb/octeon-hcd.c > index 1daeb31..c8df0c3 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.c > +++ b/drivers/staging/octeon-usb/octeon-hcd.c > @@ -2884,7 +2884,7 @@ static int __cvmx_usb_poll_channel(struct > cvmx_usb_state *usb, int channel) > pipe->pid_toggle = 1; > if (__cvmx_usb_pipe_needs_split(usb, pipe)) > transaction->stage = > - > CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; > + CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; This really doesn't help much, the original code is fine, there are better things to fix in this file :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] staging/lustre: use __aligned(size) instead of __attribute__(aligned(size))
OK, I'll do that, thanks. Mario. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] octeon-usb: fix 'too many leading tabs'
This file contained a lot of warnings of line of over 80 characters
and that the code needs to be refactored due to nested if else
conditions.
The file was accordingly edited to remove some of the warnings.
Signed-off-by: Amitoj Kaur Chawla
---
drivers/staging/octeon-usb/octeon-hcd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index c8df0c3..e944292 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -2920,11 +2920,11 @@ static int __cvmx_usb_poll_channel(struct
cvmx_usb_state *usb, int channel)
*/
if (!usbc_hcchar.s.epdir) {
if (buffer_space_left <
pipe->max_packet)
-
transaction->actual_bytes +=
-
buffer_space_left;
+ transaction->actual_bytes +=
+ buffer_space_left;
else
-
transaction->actual_bytes +=
-
pipe->max_packet;
+ transaction->actual_bytes +=
+ pipe->max_packet;
}
} else if ((buffer_space_left == 0) ||
(bytes_in_last_packet <
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: Use strcmp instead of strncmp
Since both buffers are null terminated, strncmp
is not needed.
Signed-off-by: Madhusudhanan Ravindran
---
drivers/staging/fbtft/fbtft_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft_device.c
b/drivers/staging/fbtft/fbtft_device.c
index 1afeebb..ee21607 100644
--- a/drivers/staging/fbtft/fbtft_device.c
+++ b/drivers/staging/fbtft/fbtft_device.c
@@ -1334,7 +1334,7 @@ static int __init fbtft_device_init(void)
}
/* name=list lists all supported displays */
- if (strncmp(name, "list", 32) == 0) {
+ if (strcmp(name, "list") == 0) {
pr_info(DRVNAME": Supported displays:\n");
for (i = 0; i < ARRAY_SIZE(displays); i++)
@@ -1355,7 +1355,7 @@ static int __init fbtft_device_init(void)
}
for (i = 0; i < ARRAY_SIZE(displays); i++) {
- if (strncmp(name, displays[i].name, 32) == 0) {
+ if (strcmp(name, displays[i].name) == 0) {
if (displays[i].spi) {
spi = displays[i].spi;
spi->chip_select = cs;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 01/10] Drivers: hv: vmbus: Perform device register in the per-channel work element
This patch is a continuation of the rescind handling cleanup work. We cannot
block in the global message handling work context especially if we are blocking
waiting for the host to wake us up. I would like to thank
Dexuan Cui for observing this problem.
The current char-next branch is broken and this patch fixes
the bug.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 143 +++-
drivers/hv/connection.c |6 ++-
drivers/hv/hyperv_vmbus.h |2 +-
3 files changed, 107 insertions(+), 44 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 6117891..5f8e47b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,6 +38,10 @@ struct vmbus_channel_message_table_entry {
void (*message_handler)(struct vmbus_channel_message_header *msg);
};
+struct vmbus_rescind_work {
+ struct work_struct work;
+ struct vmbus_channel *channel;
+};
/**
* vmbus_prep_negotiate_resp() - Create default response for Hyper-V Negotiate
message
@@ -134,20 +139,6 @@ fw_error:
EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
-static void vmbus_process_device_unregister(struct work_struct *work)
-{
- struct device *dev;
- struct vmbus_channel *channel = container_of(work,
- struct vmbus_channel,
- work);
-
- dev = get_device(&channel->device_obj->device);
- if (dev) {
- vmbus_device_unregister(channel->device_obj);
- put_device(dev);
- }
-}
-
static void vmbus_sc_creation_cb(struct work_struct *work)
{
struct vmbus_channel *newchannel = container_of(work,
@@ -220,6 +211,40 @@ static void free_channel(struct vmbus_channel *channel)
queue_work(vmbus_connection.work_queue, &channel->work);
}
+static void process_rescind_fn(struct work_struct *work)
+{
+ struct vmbus_rescind_work *rc_work;
+ struct vmbus_channel *channel;
+ struct device *dev;
+
+ rc_work = container_of(work, struct vmbus_rescind_work, work);
+ channel = rc_work->channel;
+
+ /*
+* We have already acquired a reference on the channel
+* and so it cannot vanish underneath us.
+* It is possible (while very unlikely) that we may
+* get here while the processing of the initial offer
+* is still not complete. Deal with this situation by
+* just waiting until the channel is in the correct state.
+*/
+
+ while (channel->work.func != release_channel)
+ msleep(1000);
+
+ if (channel->device_obj) {
+ dev = get_device(&channel->device_obj->device);
+ if (dev) {
+ vmbus_device_unregister(channel->device_obj);
+ put_device(dev);
+ }
+ } else {
+ hv_process_channel_removal(channel,
+ channel->offermsg.child_relid);
+ }
+ kfree(work);
+}
+
static void percpu_channel_enq(void *arg)
{
struct vmbus_channel *channel = arg;
@@ -282,6 +307,46 @@ void vmbus_free_channels(void)
}
}
+static void vmbus_do_device_register(struct work_struct *work)
+{
+ struct hv_device *device_obj;
+ int ret;
+ unsigned long flags;
+ struct vmbus_channel *newchannel = container_of(work,
+struct vmbus_channel,
+work);
+
+ ret = vmbus_device_register(newchannel->device_obj);
+ if (ret != 0) {
+ pr_err("unable to add child device object (relid %d)\n",
+ newchannel->offermsg.child_relid);
+ spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
+ list_del(&newchannel->listentry);
+ device_obj = newchannel->device_obj;
+ newchannel->device_obj = NULL;
+ spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
+
+ if (newchannel->target_cpu != get_cpu()) {
+ put_cpu();
+ smp_call_function_single(newchannel->target_cpu,
+percpu_channel_deq, newchannel, true);
+ } else {
+ percpu_channel_deq(newchannel);
+ put_cpu();
+ }
+
+ kfree(device_obj);
+ if (!newchannel->rescind) {
+ free_channel(newchannel);
+ return;
+ }
+ }
+ /*
+* The next state for this channel is to be freed.
+*/
+ INIT_WORK(&newchannel->work, release_channel);
+}
+
/*
* vmbus_process_offer - Process the offer
[PATCH V2 03/10] Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural
From: Vitaly Kuznetsov
Memory blocks can be onlined in random order. When this order is not natural
some memory pages are not onlined because of the redundant check in
hv_online_page().
Here is a real world scenario:
1) Host tries to hot-add the following (process_hot_add):
pg_start=rg_start=0x48000, pfn_cnt=111616, rg_size=262144
2) This results in adding 4 memory blocks:
[ 109.057866] init_memory_mapping: [mem 0x4800-0x4fff]
[ 114.102698] init_memory_mapping: [mem 0x5000-0x57ff]
[ 119.168039] init_memory_mapping: [mem 0x5800-0x5fff]
[ 124.233053] init_memory_mapping: [mem 0x6000-0x67ff]
The last one is incomplete but we have special has->covered_end_pfn counter to
avoid onlining non-backed frames and hv_bring_pgs_online() function to bring
them online later on.
3) Now we have 4 offline memory blocks: /sys/devices/system/memory/memory9-12
$ for f in /sys/devices/system/memory/memory*/state; do echo $f `cat $f`; done
| grep -v onlin
/sys/devices/system/memory/memory10/state offline
/sys/devices/system/memory/memory11/state offline
/sys/devices/system/memory/memory12/state offline
/sys/devices/system/memory/memory9/state offline
4) We bring them online in non-natural order:
$grep MemTotal /proc/meminfo
MemTotal: 966348 kB
$echo online > /sys/devices/system/memory/memory12/state && grep MemTotal
/proc/meminfo
MemTotal:1019596 kB
$echo online > /sys/devices/system/memory/memory11/state && grep MemTotal
/proc/meminfo
MemTotal:1150668 kB
$echo online > /sys/devices/system/memory/memory9/state && grep MemTotal
/proc/meminfo
MemTotal:1150668 kB
As you can see memory9 block gives us zero additional memory. We can also
observe a huge discrepancy between host- and guest-reported memory sizes.
The root cause of the issue is the redundant pg >= covered_start_pfn check (and
covered_start_pfn advancing) in hv_online_page(). When upper memory block in
being onlined before the lower one (memory12 and memory11 in the above case) we
advance the covered_start_pfn pointer and all memory9 pages do not pass the
check. If the assumption that host always gives us requests in sequential order
and pg_start always equals rg_start when the first request for the new HA
region is received (that's the case in my testing) is correct than we can get
rid of covered_start_pfn and pg >= start_pfn check in hv_online_page() is
sufficient.
The current char-next branch is broken and this patch fixes
the bug.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_balloon.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index f1f17c5..014256a 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -428,14 +428,13 @@ struct dm_info_msg {
* currently hot added. We hot add in multiples of 128M
* chunks; it is possible that we may not be able to bring
* online all the pages in the region. The range
- * covered_start_pfn : covered_end_pfn defines the pages that can
+ * covered_end_pfn defines the pages that can
* be brough online.
*/
struct hv_hotadd_state {
struct list_head list;
unsigned long start_pfn;
- unsigned long covered_start_pfn;
unsigned long covered_end_pfn;
unsigned long ha_end_pfn;
unsigned long end_pfn;
@@ -679,8 +678,7 @@ static void hv_online_page(struct page *pg)
list_for_each(cur, &dm_device.ha_region_list) {
has = list_entry(cur, struct hv_hotadd_state, list);
- cur_start_pgp = (unsigned long)
- pfn_to_page(has->covered_start_pfn);
+ cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
if (((unsigned long)pg >= cur_start_pgp) &&
@@ -692,7 +690,6 @@ static void hv_online_page(struct page *pg)
__online_page_set_limits(pg);
__online_page_increment_counters(pg);
__online_page_free(pg);
- has->covered_start_pfn++;
}
}
}
@@ -736,10 +733,9 @@ static bool pfn_covered(unsigned long start_pfn, unsigned
long pfn_cnt)
* is, update it.
*/
- if (has->covered_end_pfn != start_pfn) {
+ if (has->covered_end_pfn != start_pfn)
has->covered_end_pfn = start_pfn;
- has->covered_start_pfn = start_pfn;
- }
+
return true;
}
@@ -784,7 +780,6 @@ static unsigned long handle_pg_range(unsigned long pg_start,
pgs_ol = pfn_cnt;
hv_bring_pgs_online(start_pfn, pgs_ol);
has->covered_end_pfn += pgs_ol;
- has->covered_start_pfn += pgs_ol;
[PATCH V2 04/10] Drivers: hv: vmbus: Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY
From: Nick Meier
HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number. Depending on the usage context,
the value may be truncated. This patch is in response from the following
email from Wu Fengguang :
From: Wu Fengguang
Subject: [char-misc:char-misc-testing 25/45] drivers/hv/vmbus_drv.c:67:9:
sparse:
constant 0x8000 is so big it is unsigned long
tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-testing
head: b3de8e3719e582f3182bb504295e4a8e43c8c96f
commit: 96c1d0581d00f7abe033350edb021a9d947d8d81 [25/45] Drivers: hv:
vmbus: Add support for VMBus panic notifier handler
reproduce:
# apt-get install sparse
git checkout 96c1d0581d00f7abe033350edb021a9d947d8d81
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/hv/vmbus_drv.c:67:9: sparse: constant 0x8000 is so big
it is unsigned long
...
Signed-off-by: Nick Meier
Reported-by: Wu Fengguang
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hyperv_vmbus.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 6339589..c8e27e0 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -58,7 +58,7 @@ enum hv_cpuid_function {
#define HV_X64_MSR_CRASH_P4 0x4104
#define HV_X64_MSR_CRASH_CTL 0x4105
-#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000
+#define HV_CRASH_CTL_CRASH_NOTIFY (1ULL << 63)
/* Define version of the synthetic interrupt controller. */
#define HV_SYNIC_VERSION (1)
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 09/10] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
Export the vmbus_sendpacket_pagebuffer_ctl() interface. This export will be used by the netvsc driver. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 2c8206d..fddd3b5 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -707,6 +707,7 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, return ret; } +EXPORT_SYMBOL_GPL(vmbus_sendpacket_pagebuffer_ctl); /* * vmbus_sendpacket_pagebuffer - Send a range of single-page buffer -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 05/10] hv: vmbus: missing curly braces in vmbus_process_offer()
From: Dan Carpenter
The indenting makes it clear that there were curly braces intended here.
Fixes: 2dd37cb81580 ('Drivers: hv: vmbus: Handle both rescind and offer
messages in the same context')
Signed-off-by: Dan Carpenter
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 5f8e47b..25dbbaf 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -415,7 +415,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
newchannel->state = CHANNEL_OPEN_STATE;
channel->num_sc++;
- if (channel->sc_creation_callback != NULL)
+ if (channel->sc_creation_callback != NULL) {
/*
* We need to invoke the sub-channel creation
* callback; invoke this in a seperate work
@@ -427,6 +427,7 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
vmbus_sc_creation_cb);
queue_work(newchannel->controlwq,
&newchannel->work);
+ }
return;
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 06/10] tools: hv: fcopy_daemon: support >2GB files for x86_32 guest
From: Dexuan Cui Without this patch, hv_fcopy_daemon's hv_copy_data() -> pwrite() will fail for >2GB file offset. The current char-next branch is broken and this patch fixes the bug. Signed-off-by: Alex Ng Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Signed-off-by: K. Y. Srinivasan --- tools/hv/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/hv/Makefile b/tools/hv/Makefile index 99ffe61..a8ab795 100644 --- a/tools/hv/Makefile +++ b/tools/hv/Makefile @@ -3,7 +3,7 @@ CC = $(CROSS_COMPILE)gcc PTHREAD_LIBS = -lpthread WARNINGS = -Wall -Wextra -CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) +CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS) all: hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon %: %.c -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 08/10] hv: hypervvssd: call endmntent before call setmntent again
From: Vaughan Cao
If freeze fails, vss_operate will re-enter itself to thaw. But it forgets
to call endmntent() before it recalls setmntent() again.
Signed-off-by: Vaughan Cao
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_vss_daemon.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 5e63f70..506dd01 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -81,6 +81,7 @@ static int vss_operate(int operation)
char match[] = "/dev/";
FILE *mounts;
struct mntent *ent;
+ char errdir[1024] = {0};
unsigned int cmd;
int error = 0, root_seen = 0, save_errno = 0;
@@ -115,6 +116,8 @@ static int vss_operate(int operation)
goto err;
}
+ endmntent(mounts);
+
if (root_seen) {
error |= vss_do_freeze("/", cmd);
if (error && operation == VSS_OP_FREEZE)
@@ -124,16 +127,19 @@ static int vss_operate(int operation)
goto out;
err:
save_errno = errno;
+ if (ent) {
+ strncpy(errdir, ent->mnt_dir, sizeof(errdir)-1);
+ endmntent(mounts);
+ }
vss_operate(VSS_OP_THAW);
/* Call syslog after we thaw all filesystems */
if (ent)
syslog(LOG_ERR, "FREEZE of %s failed; error:%d %s",
- ent->mnt_dir, save_errno, strerror(save_errno));
+ errdir, save_errno, strerror(save_errno));
else
syslog(LOG_ERR, "FREEZE of / failed; error:%d %s", save_errno,
strerror(save_errno));
out:
- endmntent(mounts);
return error;
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 00/10] Drivers: hv: vmbus: Some miscellaneous fixes
Some miscellaneous fixes to the vmbus driver and the balloon driver. Currently the char-next tree is broken and some of the patches in this set fix the issue. In this version of the set, Nick has addressed review comments from Greg on the patch: 0004-Drivers-hv-vmbus-Correcting-truncation-error-for-con.patch I have also included an aditional patch to fix a host signalling issue. Dan Carpenter (1): hv: vmbus: missing curly braces in vmbus_process_offer() Dexuan Cui (1): tools: hv: fcopy_daemon: support >2GB files for x86_32 guest K. Y. Srinivasan (4): Drivers: hv: vmbus: Perform device register in the per-channel work element Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal() Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl() Drivers: hv: vmbus: Fix a siganlling host signalling issue Nick Meier (1): Drivers: hv: vmbus: Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY Vaughan Cao (1): hv: hypervvssd: call endmntent before call setmntent again Vitaly Kuznetsov (2): Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural drivers/hv/channel.c | 44 ++ drivers/hv/channel_mgmt.c | 146 +++- drivers/hv/connection.c |6 ++- drivers/hv/hv_balloon.c | 15 ++--- drivers/hv/hyperv_vmbus.h |4 +- tools/hv/Makefile |2 +- tools/hv/hv_vss_daemon.c | 10 +++- 7 files changed, 157 insertions(+), 70 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 07/10] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()
When a channel has been rescinded, the close operation is a noop.
Restructure the code so we deal with the rescind condition after
we properly cleanup the channel. I would like to thank
Dexuan Cui for observing this problem.
The current code leaks memory when the channel is rescinded.
The current char-next branch is broken and this patch fixes
the bug.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index da53180..2c8206d 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -501,15 +501,6 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
put_cpu();
}
- /*
-* If the channel has been rescinded; process device removal.
-*/
- if (channel->rescind) {
- hv_process_channel_removal(channel,
- channel->offermsg.child_relid);
- return 0;
- }
-
/* Send a closing message */
msg = &channel->close_msg.msg;
@@ -549,6 +540,12 @@ static int vmbus_close_internal(struct vmbus_channel
*channel)
free_pages((unsigned long)channel->ringbuffer_pages,
get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
+ /*
+* If the channel has been rescinded; process device removal.
+*/
+ if (channel->rescind)
+ hv_process_channel_removal(channel,
+ channel->offermsg.child_relid);
return ret;
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 02/10] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure
From: Vitaly Kuznetsov When add_memory() fails the following BUG is observed: [ 743.646107] hv_balloon: hot_add memory failed error is -17 [ 743.679973] [ 743.680930] = [ 743.680930] [ BUG: bad unlock balance detected! ] [ 743.680930] 3.19.0-rc5_bug1131426+ #552 Not tainted [ 743.680930] - [ 743.680930] kworker/0:2/255 is trying to release lock (&dm_device.ha_region_mutex) at: [ 743.680930] [] mutex_unlock+0xe/0x10 [ 743.680930] but there are no more locks to release! This happens as we don't acquire ha_region_mutex and hot_add_req() expects us to as it does unconditional mutex_unlock(). Acquire the lock on the error path. The current char-next branch is broken and this patch fixes the bug. Signed-off-by: Vitaly Kuznetsov Acked-by: Jason Wang Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv_balloon.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index c5bb872..f1f17c5 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -652,6 +652,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size, } has->ha_end_pfn -= HA_CHUNK; has->covered_end_pfn -= processed_pfn; + mutex_lock(&dm_device.ha_region_mutex); break; } -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 10/10] Drivers: hv: vmbus: Fix a siganlling host signalling issue
Handle the case when the write to the ringbuffer fails. In this case, unconditionally signal the host. Since we may have deferred signalling the host based on the kick_q parameter, signalling the host unconditionally in this case deals with the issue. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c | 28 ++-- 1 files changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index fddd3b5..54da66d 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -611,7 +611,19 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); - if ((ret == 0) && kick_q && signal) + /* +* Signalling the host is conditional on many factors: +* 1. The ring state changed from being empty to non-empty. +*This is tracked by the variable "signal". +* 2. The variable kick_q tracks if more data will be placed +*on the ring. We will not signal if more data is +*to be placed. +* +* If we cannot write to the ring-buffer; signal the host +* even if we may not have written anything. This is a rare +* enough condition that it should not matter. +*/ + if (((ret == 0) && kick_q && signal) || (ret)) vmbus_setevent(channel); return ret; @@ -702,7 +714,19 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, ret = hv_ringbuffer_write(&channel->outbound, bufferlist, 3, &signal); - if ((ret == 0) && kick_q && signal) + /* +* Signalling the host is conditional on many factors: +* 1. The ring state changed from being empty to non-empty. +*This is tracked by the variable "signal". +* 2. The variable kick_q tracks if more data will be placed +*on the ring. We will not signal if more data is +*to be placed. +* +* If we cannot write to the ring-buffer; signal the host +* even if we may not have written anything. This is a rare +* enough condition that it should not matter. +*/ + if (((ret == 0) && kick_q && signal) || (ret)) vmbus_setevent(channel); return ret; -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH octeon-usb] fix 'line over 80 characters'
Hi, On Wed, Mar 18, 2015 at 08:12:32PM +0530, Amitoj Kaur Chawla wrote: > This file contained a warning of a line being over 80 characters and > so the file has been edited to remove that warning. > > Signed-off-by: Amitoj Kaur Chawla > --- > drivers/staging/octeon-usb/octeon-hcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.c > b/drivers/staging/octeon-usb/octeon-hcd.c > index 1daeb31..c8df0c3 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.c > +++ b/drivers/staging/octeon-usb/octeon-hcd.c > @@ -2884,7 +2884,7 @@ static int __cvmx_usb_poll_channel(struct > cvmx_usb_state *usb, int channel) > pipe->pid_toggle = 1; > if (__cvmx_usb_pipe_needs_split(usb, pipe)) > transaction->stage = > - > CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; > + CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE; This is not an improvement. The proper fix is to refactor the code to avoid deep nesting. A. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: linux: linux-prim: fixed coding style warnings and errors
From: Roberto Medina
Coding style fixes due to exported symbols and comment style.
Signed-off-by: Roberto Medina
---
.../lustre/lustre/libcfs/linux/linux-prim.c| 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
index fde2819..838f5f3 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-prim.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL(cfs_timer_deadline);
void cfs_enter_debugger(void)
{
#if defined(CONFIG_KGDB)
-// BREAKPOINT();
+ /* BREAKPOINT(); */
#else
/* nothing */
#endif
}
+EXPORT_SYMBOL(cfs_enter_debugger);
sigset_t
@@ -138,6 +139,7 @@ cfs_block_allsigs(void)
return old;
}
+EXPORT_SYMBOL(cfs_block_allsigs);
sigset_t cfs_block_sigs(unsigned long sigs)
{
@@ -151,6 +153,7 @@ sigset_t cfs_block_sigs(unsigned long sigs)
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
return old;
}
+EXPORT_SYMBOL(cfs_block_sigs);
/* Block all signals except for the @sigs */
sigset_t cfs_block_sigsinv(unsigned long sigs)
@@ -166,9 +169,10 @@ sigset_t cfs_block_sigsinv(unsigned long sigs)
return old;
}
+EXPORT_SYMBOL(cfs_block_sigsinv);
void
-cfs_restore_sigs (sigset_t old)
+cfs_restore_sigs(sigset_t old)
{
unsigned long flags;
@@ -177,12 +181,14 @@ cfs_restore_sigs (sigset_t old)
recalc_sigpending();
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
+EXPORT_SYMBOL(cfs_restore_sigs);
int
cfs_signal_pending(void)
{
return signal_pending(current);
}
+EXPORT_SYMBOL(cfs_signal_pending);
void
cfs_clear_sigpending(void)
@@ -193,25 +199,19 @@ cfs_clear_sigpending(void)
clear_tsk_thread_flag(current, TIF_SIGPENDING);
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
+EXPORT_SYMBOL(cfs_clear_sigpending);
int
libcfs_arch_init(void)
{
return 0;
}
+EXPORT_SYMBOL(libcfs_arch_init);
void
libcfs_arch_cleanup(void)
{
return;
}
-
-EXPORT_SYMBOL(libcfs_arch_init);
EXPORT_SYMBOL(libcfs_arch_cleanup);
-EXPORT_SYMBOL(cfs_enter_debugger);
-EXPORT_SYMBOL(cfs_block_allsigs);
-EXPORT_SYMBOL(cfs_block_sigs);
-EXPORT_SYMBOL(cfs_block_sigsinv);
-EXPORT_SYMBOL(cfs_restore_sigs);
-EXPORT_SYMBOL(cfs_signal_pending);
-EXPORT_SYMBOL(cfs_clear_sigpending);
+
--
2.3.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] octeon-usb: fix 'too many leading tabs'
Hi,
On Wed, Mar 18, 2015 at 10:18:29PM +0530, Amitoj Kaur Chawla wrote:
> This file contained a lot of warnings of line of over 80 characters
> and that the code needs to be refactored due to nested if else
> conditions.
>
> The file was accordingly edited to remove some of the warnings.
>
> Signed-off-by: Amitoj Kaur Chawla
> ---
> drivers/staging/octeon-usb/octeon-hcd.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
> b/drivers/staging/octeon-usb/octeon-hcd.c
> index c8df0c3..e944292 100644
> --- a/drivers/staging/octeon-usb/octeon-hcd.c
> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
> @@ -2920,11 +2920,11 @@ static int __cvmx_usb_poll_channel(struct
> cvmx_usb_state *usb, int channel)
>*/
> if (!usbc_hcchar.s.epdir) {
> if (buffer_space_left <
> pipe->max_packet)
> -
> transaction->actual_bytes +=
> -
> buffer_space_left;
> + transaction->actual_bytes +=
> + buffer_space_left;
> else
> -
> transaction->actual_bytes +=
> -
> pipe->max_packet;
> + transaction->actual_bytes +=
> +pipe->max_packet;
You could reduce deep indentation here by moving the whole ACK bit
handling into a separate function.
A.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND v2 4/5] staging: sm750fb: Fix __iomem pointer types
This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address
space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address
space of expression
Signed-off-by: Lorenzo Stoakes
---
v2: Whitespace fixups
drivers/staging/sm750fb/sm750_cursor.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c
b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color,mask,opr;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem *pbuffer, *pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
/*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
}
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
#if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color, mask;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem *pbuffer, *pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
for(i=0;ihttp://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND v2 1/5] staging: sm750fb: Use memset_io instead of memset
This patch takes into account that cursor->vstart, crtc->vScreen and
share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
to make this explicit. In addition, some architectures require special treatment
of memory-mapped I/O so the previous code could actually break without this
change.
This fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1
(different address spaces)
Signed-off-by: Lorenzo Stoakes
---
v2: Whitespace fixups, updated commit message
drivers/staging/sm750fb/sm750.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..3e36b6a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)
crtc->cursor.share = share;
-memset(crtc->cursor.vstart, 0, crtc->cursor.size);
+ memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if(!g_hwcursor){
lynxfb_ops.fb_cursor = NULL;
crtc->cursor.disable(&crtc->cursor);
@@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
}
#endif
- memset(share->pvMem,0,share->vidmem_size);
+ memset_io(share->pvMem, 0, share->vidmem_size);
pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
--
2.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 11:25, Dan Carpenter wrote: > Could you read your patches again and find other similar white space > issues. Done. Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
On 18 March 2015 at 10:59, Dan Carpenter wrote: > Call it a v2 patch. Put a note under the --- cut off line: > v2: updated to apply to latest linux-next > > http://kernelnewbies.org/PatchTipsAndTricks Since each changed patch in the resend already incorporates changes to update to apply to the latest linux-next, I instead referenced whitespace/description changes (let me know if this isn't usually something you'd reference) to avoid confusion, as otherwise I'd have to resend other patches unchanged with just a v2 applied, then additionally update the ones that need changes. Let me know if you'd like this done differently! Best, -- Lorenzo Stoakes https:/ljs.io ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: lustre: file.c: fix coding style
Several warnings and errors of coding style rules corrected.
Compile tested.
Signed-off-by: Pierre-Yves Péneau
---
drivers/staging/lustre/lustre/llite/file.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index 6dab3ba..5c13b9a 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -270,7 +270,7 @@ static int ll_md_close(struct obd_export *md_exp, struct
inode *inode,
int lockmode;
__u64 flags = LDLM_FL_BLOCK_GRANTED | LDLM_FL_TEST_LOCK;
struct lustre_handle lockh;
- ldlm_policy_data_t policy = {.l_inodebits = {MDS_INODELOCK_OPEN}};
+ ldlm_policy_data_t policy = { .l_inodebits = {MDS_INODELOCK_OPEN} };
int rc = 0;
/* clear group lock, if present */
@@ -640,7 +640,8 @@ restart:
result in a deadlock */
mutex_unlock(&lli->lli_och_mutex);
it->it_create_mode |= M_CHECK_STALE;
- rc = ll_intent_file_open(file->f_path.dentry, NULL, 0,
it);
+ rc = ll_intent_file_open(file->f_path.dentry,
+ NULL, 0, it);
it->it_create_mode &= ~M_CHECK_STALE;
if (rc)
goto out_openerr;
@@ -2682,7 +2683,7 @@ ll_file_flock(struct file *file, int cmd, struct
file_lock *file_lock)
};
struct md_op_data *op_data;
struct lustre_handle lockh = {0};
- ldlm_policy_data_t flock = {{0}};
+ ldlm_policy_data_t flock = { {0} };
__u64 flags = 0;
int rc;
int rc2 = 0;
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: fbtft: add declaration of non-static functions
This patch fixes these sparse warnings:
drivers/staging/fbtft/fbtft-sysfs.c:23:5: warning: symbol
'fbtft_gamma_parse_str' was not declared. Should it be static?
drivers/staging/fbtft/fbtft-sysfs.c:153:6: warning: symbol
'fbtft_expand_debug_value' was not declared. Should it be static?
drivers/staging/fbtft/fbtft-sysfs.c:209:6: warning: symbol 'fbtft_sysfs_init'
was not declared. Should it be static?
drivers/staging/fbtft/fbtft-sysfs.c:216:6: warning: symbol 'fbtft_sysfs_exit'
was not declared. Should it be static?
Signed-off-by: Peter Poklop
---
drivers/staging/fbtft/fbtft-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-sysfs.c
b/drivers/staging/fbtft/fbtft-sysfs.c
index 45f8de3..738a1c5 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -1,5 +1,5 @@
#include "fbtft.h"
-
+#include "internal.h"
static int get_next_ulong(char **str_p, unsigned long *val, char *sep, int
base)
{
--
2.1.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] MAINTAINERS: change Arve's last name encoding to UTF-8
All other non ASCII names in this file are also UTF-8 encoded. Signed-off-by: Baruch Siach --- I'm pretty sure this patch as it goes through the mail system will fail to apply using 'git am', because the email encoding is not well defined, but the intention is clear. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0e1abe8cc684..4ce99a8f8b2a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -725,7 +725,7 @@ F: staging/iio/trigger/iio-trig-bfin-timer.c ANDROID DRIVERS M: Greg Kroah-Hartman -M: Arve Hj�nnev�g +M: Arve Hjønnevåg M: Riley Andrews T: git git://git.kernel.org/pub/scm/linux/kernel/gregkh/staging.git L: de...@driverdev.osuosl.org -- 2.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] Staging: lustre: file.c: fix coding style
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+ rc = ll_intent_file_open(file->f_path.dentry,
+ NULL, 0, it);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] Staging: lustre: file.c: fix coding style
Uck, my reply made the formatting even worse. I'm trying to say it
should look like this:
+rc = ll_intent_file_open(file->f_path.dentry,
+NULL, 0, it);
Not like this:
+rc = ll_intent_file_open(file->f_path.dentry,
+ NULL, 0, it);
On 03/18/2015 02:31 PM, Patrick Farrell wrote:
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+rc = ll_intent_file_open(file->f_path.dentry,
+NULL, 0, it);
___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: lustre: file.c: fix coding style
Fix your email client From header to use your full name. The subject is very vague. On Wed, Mar 18, 2015 at 08:08:48PM +0100, p...@amd48-systeme.lip6.fr wrote: > Several warnings and errors of coding style rules corrected. Which? > Compile tested. Put this under the --- cut off. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: lustre: ldlm_pool: fix coding style
Errors and warnings of coding style rules corrected.
Signed-off-by: Guillaume Turchini
---
drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
index 7574502..f4f3d0d 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
@@ -605,8 +605,8 @@ int ldlm_pool_recalc(struct ldlm_pool *pl)
pl->pl_recalc_period;
if (recalc_interval_sec <= 0) {
/* Prevent too frequent recalculation. */
- CDEBUG(D_DLMTRACE, "Negative interval(%ld), "
- "too short period(%ld)",
+ CDEBUG(D_DLMTRACE,
+ "Negative interval(%ld), too short period(%ld)",
recalc_interval_sec,
pl->pl_recalc_period);
recalc_interval_sec = 1;
@@ -634,7 +634,8 @@ int ldlm_pool_shrink(struct ldlm_pool *pl, int nr,
lprocfs_counter_add(pl->pl_stats,
LDLM_POOL_SHRINK_FREED_STAT,
cancel);
- CDEBUG(D_DLMTRACE, "%s: request to shrink %d locks,
shrunk %d\n",
+ CDEBUG(D_DLMTRACE,
+ "%s: request to shrink %d locks, shrunk %d\n",
pl->pl_name, nr, cancel);
}
}
@@ -1364,8 +1365,8 @@ static int ldlm_pools_thread_main(void *arg)
if (thread_test_and_clear_flags(thread, SVC_STOPPING))
break;
- else
- thread_test_and_clear_flags(thread, SVC_EVENT);
+
+ thread_test_and_clear_flags(thread, SVC_EVENT);
}
thread_set_flags(thread, SVC_STOPPED);
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 1/1] X86: hyperv: Enable MSR based APIC access
If the hypervisor supports MSR based access to the APIC registers
(EOI, TPR and ICR), implement the MSR based access.
Signed-off-by: K. Y. Srinivasan
---
Changes from V1: Addressed comments from Ingo Molnar
arch/x86/kernel/cpu/mshyperv.c | 62
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 939155f..76833c6 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -110,6 +110,57 @@ static struct clocksource hyperv_cs = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
+static u64 ms_hv_apic_icr_read(void)
+{
+ u64 reg_val;
+
+ rdmsrl(HV_X64_MSR_ICR, reg_val);
+ return reg_val;
+}
+
+static void ms_hv_apic_icr_write(u32 low, u32 id)
+{
+ u64 reg_val;
+
+ reg_val = SET_APIC_DEST_FIELD(id);
+ reg_val = reg_val << 32;
+ reg_val |= low;
+
+ wrmsrl(HV_X64_MSR_ICR, reg_val);
+}
+
+static u32 ms_hv_apic_read(u32 reg)
+{
+ u32 reg_val, hi;
+
+ switch (reg) {
+ case APIC_EOI:
+ rdmsr(HV_X64_MSR_EOI, reg_val, hi);
+ return reg_val;
+ case APIC_TASKPRI:
+ rdmsr(HV_X64_MSR_TPR, reg_val, hi);
+ return reg_val;
+
+ default:
+ return native_apic_mem_read(reg);
+ }
+}
+
+static void ms_hv_apic_write(u32 reg, u32 val)
+{
+ switch (reg) {
+ case APIC_EOI:
+ wrmsr(HV_X64_MSR_EOI, val, 0);
+ break;
+ case APIC_TASKPRI:
+ wrmsr(HV_X64_MSR_TPR, val, 0);
+ break;
+ default:
+ native_apic_mem_write(reg, val);
+ }
+}
+
+
static void __init ms_hyperv_init_platform(void)
{
/*
@@ -143,6 +194,17 @@ static void __init ms_hyperv_init_platform(void)
no_timer_check = 1;
#endif
+ if (ms_hyperv.features & HV_X64_MSR_APIC_ACCESS_AVAILABLE) {
+ /*
+* Setup the hooks for optimized APIC read/write.
+*/
+ apic->read = ms_hv_apic_read;
+ apic->write = ms_hv_apic_write;
+ apic->icr_write = ms_hv_apic_icr_write;
+ apic->icr_read = ms_hv_apic_icr_read;
+ apic->eoi_write = ms_hv_apic_write;
+ }
+
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 0/5] ft1000 driver checkpatch.pl fixes
Minor changes to fix ft1000 driver checkpatch.pl warnings Janakarajan Natarajan (5): Drivers: Staging: ft1000: Single line if-statement changes Drivers: Staging: ft1000: Fix extra parenthesis warnings Drivers: Staging: ft1000: Refactoring if-else statement Drivers: Staging: ft1000: Fix blank line after declartion warning Drivers: Staging: ft1000: checkpatch.pl header file warning fix v2: if-else refactored as suggested by Joe Perches drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 16 +++- drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 6 ++ 2 files changed, 9 insertions(+), 13 deletions(-) -- 1.9.1 --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 5/5] Drivers: Staging: ft1000: checkpatch.pl header file warning fix
Replaces and with and Signed-off-by: Janakarajan Natarajan --- drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c index b43a6fd..a93eaf5 100644 --- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c +++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c @@ -28,8 +28,8 @@ #include #include #include -#include -#include +#include +#include #include #include -- 1.9.1 --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 1/5] Drivers: Staging: ft1000: Single line if-statement changes
Minor change to remove {} for single line if statements
Signed-off-by: Janakarajan Natarajan
---
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index c8d2782..8fb0f5a 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -317,9 +317,8 @@ static int ft1000_open(struct inode *inode, struct file
*file)
/* Search for available application info block */
for (i = 0; i < MAX_NUM_APP; i++) {
- if ((dev->app_info[i].fileobject == NULL)) {
+ if ((dev->app_info[i].fileobject == NULL))
break;
- }
}
/* Fail due to lack of application info block */
@@ -575,9 +574,8 @@ static long ft1000_ioctl(struct file *file, unsigned int
command,
} else {
/* Check if this message came from a registered
application */
for (i = 0; i < MAX_NUM_APP; i++) {
- if (ft1000dev->app_info[i].fileobject
== &file->f_owner) {
+ if (ft1000dev->app_info[i].fileobject
== &file->f_owner)
break;
- }
}
if (i == MAX_NUM_APP) {
pr_debug("No matching application
fileobject\n");
--
1.9.1
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 2/5] Drivers: Staging: ft1000: Fix extra parenthesis warnings
Minor changes to remove extra parenthesis
Signed-off-by: Janakarajan Natarajan
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 2 +-
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 017c3b9..d4006a4 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -911,7 +911,7 @@ static bool ft1000_receive_cmd(struct net_device *dev, u16
*pbuffer,
tempword = *ppseudohdr++;
for (i = 1; i < 7; i++)
tempword ^= *ppseudohdr++;
- if ((tempword != *ppseudohdr)) {
+ if (tempword != *ppseudohdr) {
pr_debug("Pseudo header checksum mismatch\n");
/* Drop this message */
return false;
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index 8fb0f5a..8c1e5fc 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -317,7 +317,7 @@ static int ft1000_open(struct inode *inode, struct file
*file)
/* Search for available application info block */
for (i = 0; i < MAX_NUM_APP; i++) {
- if ((dev->app_info[i].fileobject == NULL))
+ if (!dev->app_info[i].fileobject)
break;
}
--
1.9.1
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 3/5] Drivers: Staging: ft1000: Refactoring if-else statement
Minor change to convert if-else to if statement
Signed-off-by: Janakarajan Natarajan
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index d4006a4..973bfbf 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -1948,11 +1948,10 @@ static irqreturn_t ft1000_interrupt(int irq, void
*dev_id)
ft1000_read_reg(dev,
FT1000_REG_MAG_DFSR);
}
- if (tempword & 0x1f) {
- ft1000_copy_up_pkt(dev);
- } else {
+ if (!(tempword & 0x1f))
break;
- }
+
+ ft1000_copy_up_pkt(dev);
cnt++;
} while (cnt < MAX_RCV_LOOP);
--
1.9.1
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 4/5] Drivers: Staging: ft1000: Fix blank line warning
Merges variable declaration and definition.
Signed-off-by: Janakarajan Natarajan
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 973bfbf..b43a6fd 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -2006,8 +2006,7 @@ void stop_ft1000_card(struct net_device *dev)
static void ft1000_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
- struct ft1000_info *ft_info;
- ft_info = netdev_priv(dev);
+ struct ft1000_info *ft_info = netdev_priv(dev);
strlcpy(info->driver, "ft1000", sizeof(info->driver));
snprintf(info->bus_info, sizeof(info->bus_info), "PCMCIA 0x%lx",
--
1.9.1
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: linux: linux-prim: fixed coding style warnings and errors
On Wed, Mar 18, 2015 at 07:22:49PM +0100, Roberto Medina wrote: > From: Roberto Medina > > Coding style fixes due to exported symbols and comment style. > > Signed-off-by: Roberto Medina As we spoke in person, it's best to do only one logical thing per patch, but this one is just so easy to review, I'll take it as-is :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: lustre: ldlm_pool: fix coding style
On Wed, Mar 18, 2015 at 09:11:22PM +0100, Guillaume Turchini wrote: > Errors and warnings of coding style rules corrected. You need to be a bit more specific and say what exact errors and warnings were fixed. And please only fix one type of error or warning per patch you send out. This patch should be broken up into a few smaller patches. Can you please do that and resend it? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HPDD-discuss] [PATCH] Staging: lustre: file.c: fix coding style
On Wed, 18 Mar 2015, Patrick Farrell wrote:
> Uck, my reply made the formatting even worse. I'm trying to say it should
> look like this:
> +rc = ll_intent_file_open(file->f_path.dentry,
> +NULL, 0, it);
> Not like this:
> +rc = ll_intent_file_open(file->f_path.dentry,
> + NULL, 0, it);
Both look wrong to me. Are your tabs equivalent to 8 spaces?
julia
>
> On 03/18/2015 02:31 PM, Patrick Farrell wrote:
> > Perhaps this is just a formatting error in my email client, but shouldn't
> > NULL be one more space over to line up with the '(' above?
> >
> > On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
> > > +rc = ll_intent_file_open(file->f_path.dentry,
> > > +NULL, 0, it);
> >
> > ___
> > HPDD-discuss mailing list
> > hpdd-disc...@lists.01.org
> > https://lists.01.org/mailman/listinfo/hpdd-discuss
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
