From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Khoronzhuk Date: Wed, 9 Sep 2015 21:58:58 +0300 Subject: [U-Boot] [PATCH v5] bitops: introduce BIT() definition In-Reply-To: <1441818637.29081.19.camel@freescale.com> References: <1440176519-30102-2-git-send-email-hs@denx.de> <1441626234-16364-1-git-send-email-andreas.devel@googlemail.com> <55EF2261.7090502@globallogic.com> <1441815745.29081.4.camel@freescale.com> <20150909163700.GH26226@bill-the-cat> <1441818637.29081.19.camel@freescale.com> Message-ID: <55F08172.8070804@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09.09.15 20:10, Scott Wood wrote: > On Wed, 2015-09-09 at 12:37 -0400, Tom Rini wrote: >> On Wed, Sep 09, 2015 at 11:22:25AM -0500, Scott Wood wrote: >>> On Tue, 2015-09-08 at 21:01 +0300, ivan.khoronzhuk wrote: >>>> Hi, Andreas >>>> >>>> On 07.09.15 14:43, Andreas Bie?mann wrote: >>>>> From: Heiko Schocher >>>>> >>>>> introduce BIT() definition, used in at91_udc gadget >>>>> driver. >>>>> >>>>> Signed-off-by: Heiko Schocher >>>>> [remove all other occurrences of BIT(x) definition] >>>>> Signed-off-by: Andreas Bie?mann >>>>> --- >>>>> Full buildman is running >>>>> >>>> >>>> .... >>>> >>>>> >>>>> +#define BIT(nr) (1UL << (nr)) >>>> >>>> Why UL? Why not simply 1 << (nr)? >>> >>> That would give the wrong result for nr == 31 if used as a 64-bit number, >>> and >>> would produce undefined behavior for nr >= 32 (though even with 1UL that >>> would be undefined on 32-bit builds). >>> >>>> What if I need set ULL bit on 32-bit system? >>>> Thanks for explanation. >>> >>> Yes, ULL would be better. >> >> That would be BIT_ULL(nr) ? I want to assume that there was some care >> given upstream here. It was about 2 years ago now the kernel added a >> specific BIT_ULL and family in addition to BIT(nr) from back in 2007. > > A quick search didn't turn up much justification for keeping them separate > (and it seems like using BIT where BIT_ULL is needed could be a source of > difficult bugs), but sure, we don't want to encourage writing driver code > that will break on Linux. Better to keep same approach. > > -Scott > -- Regards, Ivan Khoronzhuk