All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jingoo Han <jg1.han@samsung.com>
Cc: 'Dan Carpenter' <dan.carpenter@oracle.com>,
	'Inki Dae' <inki.dae@samsung.com>,
	'Richard Purdie' <rpurdie@rpsys.net>,
	'Florian Tobias Schandinat' <FlorianSchandinat@gmx.de>,
	linux-fbdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] backlight: s6e63m0: report ->gamma_table_count correctly
Date: Wed, 30 Jan 2013 01:01:07 +0000	[thread overview]
Message-ID: <20130129170107.f27c1ed3.akpm@linux-foundation.org> (raw)
In-Reply-To: <00c601cdfaa2$c52d03c0$4f870b40$%han@samsung.com>

On Fri, 25 Jan 2013 11:22:06 +0900
Jingoo Han <jg1.han@samsung.com> wrote:

> On Thursday, January 24, 2013 10:45 PM, Dan Carpenter wrote
> 
> CC'ed Andrew Morton, Inki Dae.
> 
> > 
> > gamma_table has 3 arrays which each hold MAX_GAMMA_LEVEL pointers to
> > int.
> > 
> > The current code sets ->gamma_table_count to 6 on 64bit arches and to 3
> > on 32 bit arches.  It should be 3 on everything.
> 
> Actually, I don't know it is right.
> However, it is certain that this panel is currently used on 32 bit arches
> such as ARM SoCs.

I don't know what gamma_table_count is supposed to do.  The only place
it is used is in s6e63m0_sysfs_show_gamma_table().  That function
doesn't actually show the table - it just prints out gamme_table_count.
Why is that useful?

Ho hum, the patch is clearly correct - the array stores int*'s and the
sysfs file should display "3" for all architectures.  However I suspect
we could just remove the whole sysfs file and nobody would care...


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Jingoo Han <jg1.han@samsung.com>
Cc: "'Dan Carpenter'" <dan.carpenter@oracle.com>,
	"'Inki Dae'" <inki.dae@samsung.com>,
	"'Richard Purdie'" <rpurdie@rpsys.net>,
	"'Florian Tobias Schandinat'" <FlorianSchandinat@gmx.de>,
	linux-fbdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] backlight: s6e63m0: report ->gamma_table_count correctly
Date: Tue, 29 Jan 2013 17:01:07 -0800	[thread overview]
Message-ID: <20130129170107.f27c1ed3.akpm@linux-foundation.org> (raw)
In-Reply-To: <00c601cdfaa2$c52d03c0$4f870b40$%han@samsung.com>

On Fri, 25 Jan 2013 11:22:06 +0900
Jingoo Han <jg1.han@samsung.com> wrote:

> On Thursday, January 24, 2013 10:45 PM, Dan Carpenter wrote
> 
> CC'ed Andrew Morton, Inki Dae.
> 
> > 
> > gamma_table has 3 arrays which each hold MAX_GAMMA_LEVEL pointers to
> > int.
> > 
> > The current code sets ->gamma_table_count to 6 on 64bit arches and to 3
> > on 32 bit arches.  It should be 3 on everything.
> 
> Actually, I don't know it is right.
> However, it is certain that this panel is currently used on 32 bit arches
> such as ARM SoCs.

I don't know what gamma_table_count is supposed to do.  The only place
it is used is in s6e63m0_sysfs_show_gamma_table().  That function
doesn't actually show the table - it just prints out gamme_table_count.
Why is that useful?

Ho hum, the patch is clearly correct - the array stores int*'s and the
sysfs file should display "3" for all architectures.  However I suspect
we could just remove the whole sysfs file and nobody would care...


  reply	other threads:[~2013-01-30  1:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24  7:05 [patch] backlight: s6e63m0: report ->gamma_table_count correctly Dan Carpenter
2013-01-25  2:22 ` Jingoo Han
2013-01-25  2:22   ` Jingoo Han
2013-01-30  1:01   ` Andrew Morton [this message]
2013-01-30  1:01     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130129170107.f27c1ed3.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=FlorianSchandinat@gmx.de \
    --cc=dan.carpenter@oracle.com \
    --cc=inki.dae@samsung.com \
    --cc=jg1.han@samsung.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.