[PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[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.


>From 66e4e73cbd28b516680b994d9c91deba21b7c727 Mon Sep 17 00:00:00 2001
From: Joe Eloff <kagen101@gmail.com>
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.
Signed-off-by: Joe Eloff <kagen101@gmail.com>
---
 drivers/staging/dt3155/dt3155_drv.c |   43 ++++++++++++++++++++++-------------
 1 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index 66db878..f6edd66 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -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]) {
-- 
1.6.3.3

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Aldo Cedillo]

> diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
> index 66db878..f6edd66 100644
> --- a/drivers/staging/dt3155/dt3155_drv.c
> +++ b/drivers/staging/dt3155/dt3155_drv.c
> @@ -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);
>                                }
>

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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Joe Eloff]

On Tue, 2010-07-06 at 12:25 -0500, Aldo Cedillo wrote:
> > diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
> > index 66db878..f6edd66 100644
> > --- a/drivers/staging/dt3155/dt3155_drv.c
> > +++ b/drivers/staging/dt3155/dt3155_drv.c
> > @@ -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);
> >                                }
> >
> 
> 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

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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Aldo Cedillo]

>
> 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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Simon Horman]

On Tue, Jul 06, 2010 at 12:25:35PM -0500, Aldo Cedillo wrote:
> > diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
> > index 66db878..f6edd66 100644
> > --- a/drivers/staging/dt3155/dt3155_drv.c
> > +++ b/drivers/staging/dt3155/dt3155_drv.c
> > @@ -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);
> >                                }
> >
> 
> 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.

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.

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Aldo Cedillo]

>
> 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.

: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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Greg KH]

On Tue, Jul 06, 2010 at 06:53:18PM +0200, Joe Eloff wrote:
> 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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Joe Eloff]

On Thu, 2010-07-08 at 13:00 -0700, Greg KH wrote:
> On Tue, Jul 06, 2010 at 06:53:18PM +0200, Joe Eloff wrote:
> > 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

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

Re: [PATCH] Staging: dt3155: fix coding style issues in dt3155_drv.c

[Greg KH]

On Sun, Jul 11, 2010 at 11:49:31AM +0200, Joe Eloff wrote:
> On Thu, 2010-07-08 at 13:00 -0700, Greg KH wrote:
> > On Tue, Jul 06, 2010 at 06:53:18PM +0200, Joe Eloff wrote:
> > > 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
> 
> Will redo all against latest tree :(. 
> 
> Did patches over 3 days, is that why it did not take?

I do  not know, sorry.

> Will get up to date and apply the patches again and send.

That would be wonderful.

thanks,

greg k-h