linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dan.carpenter@oracle.com (Dan Carpenter)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 2/2] leds: netxbig: clean up a data type issue
Date: Thu, 9 Apr 2015 22:54:26 +0300	[thread overview]
Message-ID: <20150409195426.GP10964@mwanda> (raw)
In-Reply-To: <20150409192557.GD1509@kw.sim.vm.gnt>

On Thu, Apr 09, 2015 at 09:25:57PM +0200, Simon Guinot wrote:
> On Thu, Apr 09, 2015 at 12:07:12PM +0300, Dan Carpenter wrote:
> > This driver is pretty hardware specific so it's unlikely that we're
> > going to be using it on 64 big endian systems.  Still, the current code
> > causes a static checker warning so we may as well change the type from
> > "unsigned long" to "u32" and remove the casting.
> 
> Hi Dan,
> 
> Thanks for the patch.
> 
> Why do you think it would be an issue to use the u32 type for this
> variables on a 64-bit big-endian machine ? Note that this LED mechanism
> is actually used on ARM 32-bits and x86-64 NAS platforms. The latter are
> not mainlined yet. But indeed, for now, there is no plan to use it on a
> 64-bit big-endian machine.
> 
> Since the whole LED code uses the unsigned long type to hold the delay
> values, if possible, I would prefer to keep the delay_{on,off} variables
> consistent with that.
> 
> Is there an another way to make the "static checker" happy ?

We're writing over 32 bits of a long.  It's a dangerous habbit.

If long is u32 then of_property_read_u32_index() works, obviously.  If
it is a little endian and the last 32 bits have been zeroed out (as they
have been here) then that also works.

If it's big endian and 64 bit then it doesn't work because we're writing
to the wrong 32 bits.

regards,
dan carpenter

  reply	other threads:[~2015-04-09 19:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150409090712.GF17605@mwanda>
2015-04-09 19:25 ` [patch 2/2] leds: netxbig: clean up a data type issue Simon Guinot
2015-04-09 19:54   ` Dan Carpenter [this message]
2015-04-10  0:25     ` Simon Guinot

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=20150409195426.GP10964@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 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).