Staging: dt3155: fix coding style issues in dt3155_drv.c
PATCH 1/1 Staging: dt3155: fix coding style issues in dt3155_drv.c
I just realised how the commit chaining works after messing it up so I have already uploaded a 1/2 and 2/2 and now it made another 2/2 for this patch which is different.
I have realised how it works now and wont mess it up again and have no idea how to reverse chain the 3 patches.
This now fixes up all checkpatch.pl issues bar 1.
Quoted 1 line
From
66e4e73cbd28b516680b994d9c91deba21b7c727Mon Sep 17 00:00:00 2001
From: Joe Eloff <[email protected]>
Date: Tue, 6 Jul 2010 18:43:02 +0200
Subject: [PATCH 2/2] Staging: dt3155: fix coding style issues in dt3155_drv.c
This is a patch to the dt3155_drv.c file that fixes up all the line lengths over 80 by the checkpatch.pl tool.
--- drivers/staging/dt3155/dt3155_drv.c | 43 ++++++++++++++++++++++------------- 1 files changed, 27 insertions(+), 16 deletions(-)
drivers/staging/dt3155/dt3155_drv.c +27 -16
@@ -308,33 +308,42 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)#endif if (fb->nbuffers >2 ) {if (!are_empty_buffers (minor)) { -/* The number of active + locked buffers is -* at most 2, and since there are none empty, there -* must be at least nbuffers-2 ready buffers. -* This is where we 'drop frames', oldest first. */ +/* The number of active + +* locked buffers is at most 2, +* and since there are none empty, +* there must be at least nbuffers-2 +* ready buffers. +* This is where we 'drop frames', +* oldest first. */ push_empty (pop_ready (minor), minor); }/* The ready_que can't be full, since we know -* there is one active buffer right now, so it's safe -* to push the active buf on the ready_que. */ +* there is one active buffer right now, +* so it's safe to push the active buf on the +ready_que. */ push_ready (minor, fb->active_buf);/* There's at least 1 empty -- make it active */ fb->active_buf =pop_empty (minor); - fb->frame_info[fb->active_buf].tag = ++unique_tag; + fb->frame_info[fb->active_buf].tag = + ++unique_tag; }else {/* nbuffers == 2, special case */ /* There is 1 active buffer. -* If there is a locked buffer, keep the active buffer -* the same -- that means we drop a frame. +* If there is a locked buffer, +* keep the active buffer the same +* -- that means we drop a frame. */ if (fb->locked_buf <0 ) {push_ready (minor, fb->active_buf);if (are_empty_buffers (minor)) - fb->active_buf =pop_empty (minor); + fb->active_buf = +pop_empty (minor);else { -/* no empty or locked buffers, so use a readybuf */ - fb->active_buf =pop_ready (minor); +/* no empty or locked buffers, +so use a readybuf */ + fb->active_buf = +pop_ready (minor); } } }
@@ -358,7 +367,8 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)else {writel (buffer_addr, mmio +EVEN_DMA_START ); -writel (buffer_addr + dts->config.cols, mmio +ODD_DMA_START ); +writel (buffer_addr + dts->config.cols, + mmio +ODD_DMA_START ); }/* Do error checking */
@@ -855,15 +865,16 @@ static int find_PCI(void) goto err; } -DT_3155_DEBUG_MSG (KERN_INFO "DT3155: Base address 0 for device is %lx\n" , - base); +DT_3155_DEBUG_MSG (KERN_INFO "DT3155: " +"Base address 0 for device is %lx\n" , base); dts->reg_addr = base;/* Remap the base address to a logical address through which we * can access it. */ dt3155_lbase[pci_index -1 ] =ioremap (base,PCI_PAGE_SIZE ); dts->reg_addr = base; -DT_3155_DEBUG_MSG (KERN_INFO "DT3155: New logical address is %p\n" , +DT_3155_DEBUG_MSG (KERN_INFO "DT3155: " +"New logical address is %p\n" , dt3155_lbase[pci_index-1 ]);if (!dt3155_lbase[pci_index-1 ]) {
Signature · 1 line
1.6.3.3
Quoted 12 lines
drivers/staging/dt3155/dt3155_drv.c +0
-4@@ -308,33 +308,42 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs) #endif if (fb->nbuffers > 2) { if (!are_empty_buffers(minor)) { - /* The number of active + locked buffers is -* at most 2, and since there are none empty, there -* must be at least nbuffers-2 ready buffers. -* This is where we 'drop frames', oldest first. */
drivers/staging/dt3155/dt3155_drv.c static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs) · line 320
Quoted 10 lines
drivers/staging/dt3155/dt3155_drv.c +7
-0+ /* The number of active + + * locked buffers is at most 2, + * and since there are none empty, + * there must be at least nbuffers-2 + * ready buffers. + * This is where we 'drop frames', + * oldest first. */ push_empty(pop_ready(minor), minor); }
In the CodingStyle in the kernel you can read:
The preferred style for long (multi-line) comments is:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines. */
Again I ask about the coding style because I have seen in many parts of the kernel I've seen discrepancies with what is said in the CodingStyle file. So I want to get it clear maybe I can help to clean those things.
Thanks,
Aldo Brett
Quoted 36 lines · Aldo Cedillo
Quoted 12 lines
drivers/staging/dt3155/dt3155_drv.c +0
-4@@ -308,33 +308,42 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs)#endif if (fb->nbuffers >2 ) {if (!are_empty_buffers (minor)) { -/* The number of active + locked buffers is -* at most 2, and since there are none empty, there -* must be at least nbuffers-2 ready buffers. -* This is where we 'drop frames', oldest first. */ drivers/staging/dt3155/dt3155_drv.c static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs) · line 320
Quoted 10 lines
drivers/staging/dt3155/dt3155_drv.c +7
-0+/* The number of active + +* locked buffers is at most 2, +* and since there are none empty, +* there must be at least nbuffers-2 +* ready buffers. +* This is where we 'drop frames', +* oldest first. */ push_empty (pop_ready (minor), minor); }In the CodingStyle in the kernel you can read:
The preferred style for long (multi-line) comments is:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines. */
Quoted 6 lines
Again I ask about the coding style because I have seen in many parts of the kernel I've seen discrepancies with what is said in the CodingStyle file. So I want to get it clear maybe I can help to clean those things.
Thanks,
Aldo Brett
I presumed all issues would be incorporated into checkpatch.pl. I guess it isn't.
I think the safest be here then would be to fix the script as to then have a single point of failure rather than interpretation and reference documentation in conjunction to the script.
Regards,
Joe
Quoted 10 lines
I presumed all issues would be incorporated into checkpatch.pl. I guess it isn't.
I think the safest be here then would be to fix the script as to then have a single point of failure rather than interpretation and reference documentation in conjunction to the script.Regards,
Joe
I think it's a good idea, I don't know thoroughly this script but I think stuff like this one should be included in the script. Regards,
Aldo Brett
Quoted 36 lines · Aldo Cedillo
Quoted 12 lines
drivers/staging/dt3155/dt3155_drv.c +0
-4@@ -308,33 +308,42 @@ static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs) #endif if (fb->nbuffers > 2) { if (!are_empty_buffers(minor)) { - /* The number of active + locked buffers is -* at most 2, and since there are none empty, there -* must be at least nbuffers-2 ready buffers. -* This is where we 'drop frames', oldest first. */ drivers/staging/dt3155/dt3155_drv.c static void dt3155_isr(int irq, void *dev_id, struct pt_regs *regs) · line 320
Quoted 10 lines
drivers/staging/dt3155/dt3155_drv.c +7
-0+ /* The number of active + + * locked buffers is at most 2, + * and since there are none empty, + * there must be at least nbuffers-2 + * ready buffers. + * This is where we 'drop frames', + * oldest first. */ push_empty(pop_ready(minor), minor); }In the CodingStyle in the kernel you can read:
The preferred style for long (multi-line) comments is:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines. */
Quoted 3 lines
Again I ask about the coding style because I have seen in many parts of the kernel I've seen discrepancies with what is said in the CodingStyle file. So I want to get it clear maybe I can help to clean those things.
I believe that you will find both of the following styles in abundance and that both are acceptable.
/*
* This
* is a multi-line comment
*/
And
/* This
* is a also multi-line comment
*/
Though one may be more acceptable to a given maintainer than the other. Other variants may also be common and acceptable to some maintainers, which I suspect is why checkpatch.pl is lenient.
Quoted 11 lines
I believe that you will find both of the following styles in abundance and that both are acceptable.
/*
* This
* is a multi-line comment
*/And
Quoted 7 lines
/* This
* is a also multi-line comment
*/Though one may be more acceptable to a given maintainer than the other. Other variants may also be common and acceptable to some maintainers, which I suspect is why checkpatch.pl is lenient.
:S , so I believe both are correct... as you stated this doesn't help to make a single
tool to check. Well thanks for the comment.
Aldo Brett
Quoted 7 lines · Joe Eloff
I just realised how the commit chaining works after messing it up so I have already uploaded a 1/2 and 2/2 and now it made another 2/2 for this patch which is different.
I have realised how it works now and wont mess it up again and have no idea how to reverse chain the 3 patches.
This now fixes up all checkpatch.pl issues bar 1.
This doesn't apply either :(
care to redo all of these against the latest linux-next?
thanks,
greg k-h
Quoted 9 lines · Greg KH
Quoted 7 lines · Joe Eloff
I just realised how the commit chaining works after messing it up so I have already uploaded a 1/2 and 2/2 and now it made another 2/2 for this patch which is different.
I have realised how it works now and wont mess it up again and have no idea how to reverse chain the 3 patches.
This now fixes up all checkpatch.pl issues bar 1.
Quoted 7 lines
This doesn't apply either :(
care to redo all of these against the latest linux-next?
thanks,
greg k-h
Will redo all against latest tree :(.
Did patches over 3 days, is that why it did not take?
Will get up to date and apply the patches again and send.
Regards,
Joe
Quoted 14 lines · Joe Eloff
Quoted 13 lines · Greg KH
Quoted 7 lines · Joe Eloff
I just realised how the commit chaining works after messing it up so I have already uploaded a 1/2 and 2/2 and now it made another 2/2 for this patch which is different.
I have realised how it works now and wont mess it up again and have no idea how to reverse chain the 3 patches.
This now fixes up all checkpatch.pl issues bar 1.
This doesn't apply either :(
care to redo all of these against the latest linux-next?
Quoted 7 lines
Quoted 3 lines
thanks,
greg k-h
Will redo all against latest tree :(.
Did patches over 3 days, is that why it did not take?
I do not know, sorry.
Quoted 1 line
Will get up to date and apply the patches again and send.
That would be wonderful.
thanks,
greg k-h