All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: Lars-Peter Clausen <lars@metafoo.de>,
	Jonathan Cameron <jic23@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Hartmut Knaack <knaack.h@gmx.de>
Subject: Re: [PULL] IIO - First set of new drivers, core support and cleanups for the 4.5 cycle
Date: Tue, 01 Dec 2015 22:05:32 +0000	[thread overview]
Message-ID: <2C1DBB68-13A5-4A3A-A075-F37173BD250A@jic23.retrosnub.co.uk> (raw)
In-Reply-To: <565E13AB.8050401@metafoo.de>



On 1 December 2015 21:39:55 GMT+00:00, Lars-Peter Clausen <lars@metafoo.de> wrote:
>On 12/01/2015 09:54 PM, Jonathan Cameron wrote:
>> On 01/12/15 17:13, Greg KH wrote:
>>> On Sun, Nov 22, 2015 at 02:31:54PM +0000, Jonathan Cameron wrote:
>>>>
>>>> Hi Greg,
>>>>
>>>> When this one and the fixes set I sent a few minutes ago merge you
>curiously
>>>> get an issue with drivers/staging/iio/Kconfig.  The right
>resolution is
>>>> to dump all the dummy driver stuff.
>>>>
>>>> All the other changes related to that move and various automerge
>stuff that
>>>> occurs looks fine to me.
>>>
>>> Thanks for the merge info, that helped.
>>>
>>> But, I'm now getting these build warnings that I don't think we had
>>> before:
>>>
>>> drivers/staging/iio/adc/mxs-lradc.c: In function
>‘mxs_lradc_complete_touch_event’:
>>> drivers/staging/iio/adc/mxs-lradc.c:325:5: warning: large integer
>implicitly truncated to unsigned type [-Woverflow]
>>>      (((x) << LRADC_DELAY_TRIGGER_LRADCS_OFFSET) & \
>>>      ^
>>> drivers/staging/iio/adc/mxs-lradc.c:734:7: note: in expansion of
>macro ‘LRADC_DELAY_TRIGGER’
>>>        LRADC_DELAY_TRIGGER(1 << TOUCHSCREEN_VCHANNEL1) |
>>>        ^
>>>   LD [M]  drivers/staging/iio/accel/adis16201.o
>>> drivers/staging/iio/adc/mxs-lradc.c: In function
>‘mxs_lradc_buffer_preenable’:
>>> drivers/staging/iio/adc/mxs-lradc.c:322:42: warning: large integer
>implicitly truncated to unsigned type [-Woverflow]
>>>  #define LRADC_DELAY_TRIGGER_LRADCS_MASK  (0xff << 24)
>>>                                           ^
>>> drivers/staging/iio/adc/mxs-lradc.c:1308:29: note: in expansion of
>macro ‘LRADC_DELAY_TRIGGER_LRADCS_MASK’
>>>   mxs_lradc_reg_clear(lradc, LRADC_DELAY_TRIGGER_LRADCS_MASK |
>>>                              ^
>>> drivers/staging/iio/adc/mxs-lradc.c: In function
>‘mxs_lradc_buffer_postdisable’:
>>> drivers/staging/iio/adc/mxs-lradc.c:322:42: warning: large integer
>implicitly truncated to unsigned type [-Woverflow]
>>>  #define LRADC_DELAY_TRIGGER_LRADCS_MASK  (0xff << 24)
>>>                                           ^
>>> drivers/staging/iio/adc/mxs-lradc.c:1327:29: note: in expansion of
>macro ‘LRADC_DELAY_TRIGGER_LRADCS_MASK’
>>>   mxs_lradc_reg_clear(lradc, LRADC_DELAY_TRIGGER_LRADCS_MASK |
>>>                              ^
>>>
>>> Can you fix those up?
>>>
>>> thanks,
>>>
>>> greg k-h
>> oops. I'd forgotten I got that one a while ago and meant to check
>what was causing
>> it - sorry about that - initially assumed it was just a warning that
>had gotten
>> turned on in the autobuilder.
>> 
>> After a lot of digging can be boiled down to statements
>> that end up as
>> 
>> (0xff << 24) | (1UL << 20)
>> Now I'm not entirely sure why it is unhappy with that. 
>> (0xffUL << 24) | (1UL << 20) is and (0xff << 24) | (1 << 20) - the
>original - is fine
>> as well.
>> 
>> The oddity to my mind is that 0xff is supposed to be fitted to the
>smallest possible
>> unsigned type (as it's in hex) so why is this happening?
>
>The type is int, if the value fits into int, see
>http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf#page=82
>
>I guess the right thing to do is to use UL, even though it is a bit
>ugly.
>(Or write 0xff000000 instead of 0xff << 24).
Hmm thanks for the reference.

Maybe using GENMASK(31, 24)...

Will be tomorrow evening before I can turn out a patch.

Jonathan
>
>- Lars
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

      reply	other threads:[~2015-12-01 22:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-22 14:26 [PULL] IIO - First set of new drivers, core support and cleanups for the 4.5 cycle Jonathan Cameron
2015-11-22 14:31 ` Jonathan Cameron
2015-11-29 17:29   ` Jonathan Cameron
2015-12-01  3:59     ` Greg KH
2015-12-01  7:13       ` Jonathan Cameron
2015-12-01 17:13   ` Greg KH
2015-12-01 20:54     ` Jonathan Cameron
2015-12-01 21:39       ` Lars-Peter Clausen
2015-12-01 22:05         ` Jonathan Cameron [this message]

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=2C1DBB68-13A5-4A3A-A075-F37173BD250A@jic23.retrosnub.co.uk \
    --to=jic23@jic23.retrosnub.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    /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.