linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver
       [not found] ` <20150613001849.GB5234@kroah.com>
@ 2015-06-13  8:58   ` Sudip Mukherjee
  2015-06-13 16:28     ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr Greg KH
  2015-06-19 10:29     ` Dan Carpenter
  0 siblings, 2 replies; 7+ messages in thread
From: Sudip Mukherjee @ 2015-06-13  8:58 UTC (permalink / raw)
  To: Greg KH; +Cc: devel, linux-kernel, dan.carpenter, tomi.valkeinen, linux-fbdev

On Fri, Jun 12, 2015 at 05:18:49PM -0700, Greg KH wrote:
> On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> > This patch series includes new functionality for the Freescale fsl-mc
> > bus driver.
> 
> Why are people working on "new functionality" instead of working on
> getting this out of the staging tree?  I really hate adding new
> functions to staging drivers, as this is not the correct place for
> drivers to be in the tree.  People should be working to get them out of
> this location, and then you can add new functions to them.
Hi Greg,
Your reply above was for a different thread but my doubt started from
this. I was working on adding the Dual-Head support to sm7xxfb. So that
is also a new functionality which is not in the current driver as of now.
Then should i instead concentrate on getting that out of staging? If yes,
can you please have a look (when you are free) at it to see if anything
else needs to be done.

regards
sudip
   

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-13  8:58   ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver Sudip Mukherjee
@ 2015-06-13 16:28     ` Greg KH
  2015-06-13 16:57       ` Joe Perches
  2015-06-19 10:29     ` Dan Carpenter
  1 sibling, 1 reply; 7+ messages in thread
From: Greg KH @ 2015-06-13 16:28 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: devel, linux-fbdev, tomi.valkeinen, linux-kernel, dan.carpenter

On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 12, 2015 at 05:18:49PM -0700, Greg KH wrote:
> > On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> > > This patch series includes new functionality for the Freescale fsl-mc
> > > bus driver.
> > 
> > Why are people working on "new functionality" instead of working on
> > getting this out of the staging tree?  I really hate adding new
> > functions to staging drivers, as this is not the correct place for
> > drivers to be in the tree.  People should be working to get them out of
> > this location, and then you can add new functions to them.
> Hi Greg,
> Your reply above was for a different thread but my doubt started from
> this. I was working on adding the Dual-Head support to sm7xxfb. So that
> is also a new functionality which is not in the current driver as of now.
> Then should i instead concentrate on getting that out of staging? If yes,
> can you please have a look (when you are free) at it to see if anything
> else needs to be done.

Yes, please work on getting it out of staging.

If you think it's ready, then submit a patch that moves it, copying the
proper maintainers, and I'll be glad to review it.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-13 16:28     ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr Greg KH
@ 2015-06-13 16:57       ` Joe Perches
  2015-06-15  5:29         ` Sudip Mukherjee
  0 siblings, 1 reply; 7+ messages in thread
From: Joe Perches @ 2015-06-13 16:57 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
	dan.carpenter

On Sat, 2015-06-13 at 09:28 -0700, Greg KH wrote:
> On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
[]
> > Your reply above was for a different thread but my doubt started from
> > this. I was working on adding the Dual-Head support to sm7xxfb. So that
> > is also a new functionality which is not in the current driver as of now.
> > Then should i instead concentrate on getting that out of staging? If yes,
> > can you please have a look (when you are free) at it to see if anything
> > else needs to be done.
> 
> Yes, please work on getting it out of staging.
> 
> If you think it's ready, then submit a patch that moves it, copying the
> proper maintainers, and I'll be glad to review it.

It seems ready to me.

As far as I can tell, there's just a few niggles
that could be done:

Something like (too lazy to separate them into multiple patches)

o reduce indentation a couple of places
o add newlines to logging messages
o add const to static array
o use consistent function declaration style

It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.

---
 drivers/staging/sm7xxfb/sm7xxfb.c | 203 ++++++++++++++++++--------------------
 1 file changed, 96 insertions(+), 107 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 5db26f1..5be2560 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -94,7 +94,7 @@ struct vesa_mode {
 	u16  lfb_depth;
 };
 
-static struct vesa_mode vesa_mode_table[] = {
+static const struct vesa_mode vesa_mode_table[] = {
 	{"0x301", 640,  480,  8},
 	{"0x303", 800,  600,  8},
 	{"0x305", 1024, 768,  8},
@@ -255,37 +255,32 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
 		/*
 		 * 16/32 bit true-colour, use pseudo-palette for 16 base color
 		 */
-		if (regno < 16) {
-			if (sfb->fb->var.bits_per_pixel = 16) {
-				u32 *pal = sfb->fb->pseudo_palette;
-
-				val = chan_to_field(red, &sfb->fb->var.red);
-				val |= chan_to_field(green,
-						     &sfb->fb->var.green);
-				val |= chan_to_field(blue, &sfb->fb->var.blue);
+		if (regno >= 16)
+			break;
+		if (sfb->fb->var.bits_per_pixel = 16) {
+			u32 *pal = sfb->fb->pseudo_palette;
+
+			val = chan_to_field(red, &sfb->fb->var.red);
+			val |= chan_to_field(green, &sfb->fb->var.green);
+			val |= chan_to_field(blue, &sfb->fb->var.blue);
 #ifdef __BIG_ENDIAN
-				pal[regno] -				    ((red & 0xf800) >> 8) |
-				    ((green & 0xe000) >> 13) |
-				    ((green & 0x1c00) << 3) |
-				    ((blue & 0xf800) >> 3);
+			pal[regno] = (((red & 0xf800) >> 8) |
+				      ((green & 0xe000) >> 13) |
+				      ((green & 0x1c00) << 3) |
+				      ((blue & 0xf800) >> 3));
 #else
-				pal[regno] = val;
+			pal[regno] = val;
 #endif
-			} else {
-				u32 *pal = sfb->fb->pseudo_palette;
+		} else {
+			u32 *pal = sfb->fb->pseudo_palette;
 
-				val = chan_to_field(red, &sfb->fb->var.red);
-				val |= chan_to_field(green,
-						     &sfb->fb->var.green);
-				val |= chan_to_field(blue, &sfb->fb->var.blue);
+			val = chan_to_field(red, &sfb->fb->var.red);
+			val |= chan_to_field(green, &sfb->fb->var.green);
+			val |= chan_to_field(blue, &sfb->fb->var.blue);
 #ifdef __BIG_ENDIAN
-				val -				    (val & 0xff00ff00 >> 8) |
-				    (val & 0x00ff00ff << 8);
+			val = (val & 0xff00ff00 >> 8) | (val & 0x00ff00ff << 8);
 #endif
-				pal[regno] = val;
-			}
+			pal[regno] = val;
 		}
 		break;
 
@@ -302,8 +297,8 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
 }
 
 #ifdef __BIG_ENDIAN
-static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
-				count, loff_t *ppos)
+static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
+			   size_t count, loff_t *ppos)
 {
 	unsigned long p = *ppos;
 
@@ -346,9 +341,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
 		dst = buffer;
 		for (i = c >> 2; i--;) {
 			*dst = fb_readl(src++);
-			*dst -			    (*dst & 0xff00ff00 >> 8) |
-			    (*dst & 0x00ff00ff << 8);
+			*dst = (*dst & 0xff00ff00 >> 8) |
+			       (*dst & 0x00ff00ff << 8);
 			dst++;
 		}
 		if (c & 3) {
@@ -381,9 +375,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
 	return (err) ? err : cnt;
 }
 
-static ssize_t
-smtcfb_write(struct fb_info *info, const char __user *buf, size_t count,
-	     loff_t *ppos)
+static ssize_t smtcfb_write(struct fb_info *info, const char __user *buf,
+			    size_t count, loff_t *ppos)
 {
 	unsigned long p = *ppos;
 
@@ -478,72 +471,69 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
 		sfb->width, sfb->height, sfb->fb->var.bits_per_pixel, sfb->hz);
 
 	for (j = 0; j < numvgamodes; j++) {
-		if (vgamode[j].mmsizex = sfb->width &&
-		    vgamode[j].mmsizey = sfb->height &&
-		    vgamode[j].bpp = sfb->fb->var.bits_per_pixel &&
-		    vgamode[j].hz = sfb->hz) {
-			dev_dbg(&sfb->pdev->dev,
-				"vgamode[j].mmsizex=%d vgamode[j].mmSizeY=%d vgamode[j].bpp=%d vgamode[j].hz=%d\n",
-				vgamode[j].mmsizex, vgamode[j].mmsizey,
-				vgamode[j].bpp, vgamode[j].hz);
-
-			dev_dbg(&sfb->pdev->dev, "vgamode index=%d\n", j);
-
-			smtc_mmiowb(0x0, 0x3c6);
-
-			smtc_seqw(0, 0x1);
-
-			smtc_mmiowb(vgamode[j].init_misc, 0x3c2);
-
-			/* init SEQ register SR00 - SR04 */
-			for (i = 0; i < SIZE_SR00_SR04; i++)
-				smtc_seqw(i, vgamode[j].init_sr00_sr04[i]);
-
-			/* init SEQ register SR10 - SR24 */
-			for (i = 0; i < SIZE_SR10_SR24; i++)
-				smtc_seqw(i + 0x10,
-					  vgamode[j].init_sr10_sr24[i]);
-
-			/* init SEQ register SR30 - SR75 */
-			for (i = 0; i < SIZE_SR30_SR75; i++)
-				if ((i + 0x30) != 0x62 &&
-				    (i + 0x30) != 0x6a &&
-				    (i + 0x30) != 0x6b)
-					smtc_seqw(i + 0x30,
-						  vgamode[j].init_sr30_sr75[i]);
-
-			/* init SEQ register SR80 - SR93 */
-			for (i = 0; i < SIZE_SR80_SR93; i++)
-				smtc_seqw(i + 0x80,
-					  vgamode[j].init_sr80_sr93[i]);
-
-			/* init SEQ register SRA0 - SRAF */
-			for (i = 0; i < SIZE_SRA0_SRAF; i++)
-				smtc_seqw(i + 0xa0,
-					  vgamode[j].init_sra0_sraf[i]);
-
-			/* init Graphic register GR00 - GR08 */
-			for (i = 0; i < SIZE_GR00_GR08; i++)
-				smtc_grphw(i, vgamode[j].init_gr00_gr08[i]);
-
-			/* init Attribute register AR00 - AR14 */
-			for (i = 0; i < SIZE_AR00_AR14; i++)
-				smtc_attrw(i, vgamode[j].init_ar00_ar14[i]);
-
-			/* init CRTC register CR00 - CR18 */
-			for (i = 0; i < SIZE_CR00_CR18; i++)
-				smtc_crtcw(i, vgamode[j].init_cr00_cr18[i]);
-
-			/* init CRTC register CR30 - CR4D */
-			for (i = 0; i < SIZE_CR30_CR4D; i++)
-				smtc_crtcw(i + 0x30,
-					   vgamode[j].init_cr30_cr4d[i]);
-
-			/* init CRTC register CR90 - CRA7 */
-			for (i = 0; i < SIZE_CR90_CRA7; i++)
-				smtc_crtcw(i + 0x90,
-					   vgamode[j].init_cr90_cra7[i]);
+		if (vgamode[j].mmsizex != sfb->width ||
+		    vgamode[j].mmsizey != sfb->height ||
+		    vgamode[j].bpp != sfb->fb->var.bits_per_pixel ||
+		    vgamode[j].hz != sfb->hz)
+			continue;
+
+		dev_dbg(&sfb->pdev->dev,
+			"vgamode[j].mmsizex=%d vgamode[j].mmSizeY=%d vgamode[j].bpp=%d vgamode[j].hz=%d\n",
+			vgamode[j].mmsizex, vgamode[j].mmsizey,
+			vgamode[j].bpp, vgamode[j].hz);
+
+		dev_dbg(&sfb->pdev->dev, "vgamode index=%d\n", j);
+
+		smtc_mmiowb(0x0, 0x3c6);
+
+		smtc_seqw(0, 0x1);
+
+		smtc_mmiowb(vgamode[j].init_misc, 0x3c2);
+
+		/* init SEQ register SR00 - SR04 */
+		for (i = 0; i < SIZE_SR00_SR04; i++)
+			smtc_seqw(i, vgamode[j].init_sr00_sr04[i]);
+
+		/* init SEQ register SR10 - SR24 */
+		for (i = 0; i < SIZE_SR10_SR24; i++)
+			smtc_seqw(i + 0x10, vgamode[j].init_sr10_sr24[i]);
+
+		/* init SEQ register SR30 - SR75 */
+		for (i = 0; i < SIZE_SR30_SR75; i++) {
+			if ((i + 0x30) != 0x62 &&
+			    (i + 0x30) != 0x6a &&
+			    (i + 0x30) != 0x6b)
+				smtc_seqw(i + 0x30,
+					  vgamode[j].init_sr30_sr75[i]);
 		}
+
+		/* init SEQ register SR80 - SR93 */
+		for (i = 0; i < SIZE_SR80_SR93; i++)
+			smtc_seqw(i + 0x80, vgamode[j].init_sr80_sr93[i]);
+
+		/* init SEQ register SRA0 - SRAF */
+		for (i = 0; i < SIZE_SRA0_SRAF; i++)
+			smtc_seqw(i + 0xa0, vgamode[j].init_sra0_sraf[i]);
+
+		/* init Graphic register GR00 - GR08 */
+		for (i = 0; i < SIZE_GR00_GR08; i++)
+			smtc_grphw(i, vgamode[j].init_gr00_gr08[i]);
+
+		/* init Attribute register AR00 - AR14 */
+		for (i = 0; i < SIZE_AR00_AR14; i++)
+			smtc_attrw(i, vgamode[j].init_ar00_ar14[i]);
+
+		/* init CRTC register CR00 - CR18 */
+		for (i = 0; i < SIZE_CR00_CR18; i++)
+			smtc_crtcw(i, vgamode[j].init_cr00_cr18[i]);
+
+		/* init CRTC register CR30 - CR4D */
+		for (i = 0; i < SIZE_CR30_CR4D; i++)
+			smtc_crtcw(i + 0x30, vgamode[j].init_cr30_cr4d[i]);
+
+		/* init CRTC register CR90 - CRA7 */
+		for (i = 0; i < SIZE_CR90_CRA7; i++)
+			smtc_crtcw(i + 0x90, vgamode[j].init_cr90_cra7[i]);
 	}
 	smtc_mmiowb(0x67, 0x3c2);
 
@@ -552,8 +542,7 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
 	writel(0x0, sfb->vp_regs + 0x40);
 
 	/* set data width */
-	m_nscreenstride -		(sfb->width * sfb->fb->var.bits_per_pixel) / 64;
+	m_nscreenstride = (sfb->width * sfb->fb->var.bits_per_pixel) / 64;
 	switch (sfb->fb->var.bits_per_pixel) {
 	case 8:
 		writel(0x0, sfb->vp_regs + 0x0);
@@ -741,7 +730,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
 	int err;
 	unsigned long mmio_base;
 
-	dev_info(&pdev->dev, "Silicon Motion display driver.");
+	dev_info(&pdev->dev, "Silicon Motion display driver\n");
 
 	err = pci_enable_device(pdev);	/* enable SMTC chip */
 	if (err)
@@ -815,12 +804,12 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
 #ifdef __BIG_ENDIAN
 		if (sfb->fb->var.bits_per_pixel = 32) {
 			sfb->lfb += 0x800000;
-			dev_info(&pdev->dev, "sfb->lfb=%p", sfb->lfb);
+			dev_info(&pdev->dev, "sfb->lfb=%p\n", sfb->lfb);
 		}
 #endif
 		if (!smtc_regbaseaddress) {
 			dev_err(&pdev->dev,
-				"%s: unable to map memory mapped IO!",
+				"%s: unable to map memory mapped IO!\n",
 				sfb->fb->fix.id);
 			err = -ENOMEM;
 			goto failed_fb;
@@ -854,7 +843,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
 		break;
 	default:
 		dev_err(&pdev->dev,
-			"No valid Silicon Motion display chip was detected!");
+			"No valid Silicon Motion display chip was detected!\n");
 
 		goto failed_fb;
 	}
@@ -876,14 +865,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
 		goto failed;
 
 	dev_info(&pdev->dev,
-		 "Silicon Motion SM%X Rev%X primary display mode %dx%d-%d Init Complete.",
+		 "Silicon Motion SM%X Rev%X primary display mode %dx%d-%d Init Complete\n",
 		 sfb->chip_id, sfb->chip_rev_id, sfb->fb->var.xres,
 		 sfb->fb->var.yres, sfb->fb->var.bits_per_pixel);
 
 	return 0;
 
 failed:
-	dev_err(&pdev->dev, "Silicon Motion, Inc. primary display init fail.");
+	dev_err(&pdev->dev, "Silicon Motion, Inc. primary display init failed\n");
 
 	smtc_unmap_smem(sfb);
 	smtc_unmap_mmio(sfb);



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-13 16:57       ` Joe Perches
@ 2015-06-15  5:29         ` Sudip Mukherjee
  2015-06-15  6:36           ` Joe Perches
  0 siblings, 1 reply; 7+ messages in thread
From: Sudip Mukherjee @ 2015-06-15  5:29 UTC (permalink / raw)
  To: Joe Perches
  Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
	dan.carpenter

On Sat, Jun 13, 2015 at 09:57:05AM -0700, Joe Perches wrote:
> 
> It seems ready to me.
> 
> As far as I can tell, there's just a few niggles
> that could be done:
> 
> Something like (too lazy to separate them into multiple patches)
Thanks.	I will break into patches. Call me lazy for not having it done
till now.
> 
> o reduce indentation a couple of places
> o add newlines to logging messages
> o add const to static array
> o use consistent function declaration style
> 
> It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.
instead of #ifdef __BIG_ENDIAN can i then use a bool flag to check by if-else?

regards
sudip

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-15  5:29         ` Sudip Mukherjee
@ 2015-06-15  6:36           ` Joe Perches
  0 siblings, 0 replies; 7+ messages in thread
From: Joe Perches @ 2015-06-15  6:36 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
	dan.carpenter

On Mon, 2015-06-15 at 10:47 +0530, Sudip Mukherjee wrote:
> On Sat, Jun 13, 2015 at 09:57:05AM -0700, Joe Perches wrote:
> > It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.
> instead of #ifdef __BIG_ENDIAN can i then use a bool flag to check by if-else?

I think that'd be worse.  Moving the #ifdef into the .h
may be better, but <shrug>, whatever works well enough.

Another thing may be to move the vgamode array declaration
in fb7xx.h to the .c file and make it const and remove the
#define numvgamodes and just use ARRAY_SIZE directly in
the one place it's used.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-13  8:58   ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver Sudip Mukherjee
  2015-06-13 16:28     ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr Greg KH
@ 2015-06-19 10:29     ` Dan Carpenter
  2015-06-20 11:32       ` Sudip Mukherjee
  1 sibling, 1 reply; 7+ messages in thread
From: Dan Carpenter @ 2015-06-19 10:29 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Greg KH, devel, linux-kernel, tomi.valkeinen, linux-fbdev

On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
>
> can you please have a look (when you are free) at it to see if anything
> else needs to be done.

Remove any unused macros.
Cleanup indenting in the .h file.
drivers/staging/sm7xxfb/sm7xxfb.c:821 smtcfb_pci_probe() warn: 'smtc_regbaseaddress' can't be NULL.
move the BIG_ENDIAN ifdefs to the .h file.  I don't understand why only
big endian systems get a fb_read/write?  Cleanup casts in fb_read/write.
cleanup comments.  make sure they are up to date and make sense.
cleanup function declarations.  Make the style consistent.
run checkpatch.pl --strict
Remind me we need the #ifndef MODULE?

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
  2015-06-19 10:29     ` Dan Carpenter
@ 2015-06-20 11:32       ` Sudip Mukherjee
  0 siblings, 0 replies; 7+ messages in thread
From: Sudip Mukherjee @ 2015-06-20 11:32 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: Greg KH, devel, linux-kernel, tomi.valkeinen, linux-fbdev

On Fri, Jun 19, 2015 at 01:29:13PM +0300, Dan Carpenter wrote:
> On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
> >
> > can you please have a look (when you are free) at it to see if anything
> > else needs to be done.
> 
> Remove any unused macros.
I will check.
> Cleanup indenting in the .h file.
done.
> drivers/staging/sm7xxfb/sm7xxfb.c:821 smtcfb_pci_probe() warn: 'smtc_regbaseaddress' can't be NULL.
i dont see this warning. Is it smatch?
> move the BIG_ENDIAN ifdefs to the .h file.  I don't understand why only
> big endian systems get a fb_read/write?
Greg asked to remove the BIG_ENDIAN ifdefs. for BIG_ENDIAN some
calculations are involved that is why the functions are defined.
LITTLE_ENDIAN will use the default read/write provided by fb core.
> cleanup comments.  make sure they are up to date and make sense.
will do.
> cleanup function declarations.  Make the style consistent.
i think its already done, with Joe's help.
> run checkpatch.pl --strict
done.
> Remind me we need the #ifndef MODULE?
This one I introduced with the plan that if it is built-in then it will
use the commandline to get the mode, but if it is a module then it will
use module parameters. But later Greg told that framebuffers should not
use module_param. I dont see any reason why a module can nor get the mode
values from the command line. I will test that during this period of the
merge window and prepare the final patch.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-06-20 11:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1433887148-2310-1-git-send-email-German.Rivera@freescale.com>
     [not found] ` <20150613001849.GB5234@kroah.com>
2015-06-13  8:58   ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver Sudip Mukherjee
2015-06-13 16:28     ` doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr Greg KH
2015-06-13 16:57       ` Joe Perches
2015-06-15  5:29         ` Sudip Mukherjee
2015-06-15  6:36           ` Joe Perches
2015-06-19 10:29     ` Dan Carpenter
2015-06-20 11:32       ` Sudip Mukherjee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).