[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0adaa194-413d-497e-aecf-3ac7c16c9134@email.android.com>
Date: Fri, 04 Jan 2013 08:17:51 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Matt Fleming <matt@...sole-pimps.org>,
Tim Gardner <rtg.canonical@...il.com>
CC: Steve Langasek <steve.langasek@...onical.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
Olof Johansson <olof@...om.net>,
Tony Luck <tony.luck@...el.com>,
David Airlie <airlied@...ux.ie>,
Corentin Chary <corentincj@...aif.net>,
Dave Jiang <dave.jiang@...el.com>,
Peter Jones <pjones@...hat.com>,
Konrad Rzeszutek Wilk <konrad@...nel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, tim.gardner@...onical.com
Subject: Re: [RFC PATCH 1/2] efi: Make 'efi_enabled' a function to query EFI facilities
Well, *I* am confused as heck. They look like bitmasks, we normally use decimal numbers for bit numbers as a matter of style.
Matt Fleming <matt@...sole-pimps.org> wrote:
>On Fri, 2013-01-04 at 08:08 -0700, Tim Gardner wrote:
>> On 01/03/2013 06:18 AM, Matt Fleming wrote:
>> > From: Matt Fleming <matt.fleming@...el.com>
>> >
>>
>> snip
>>
>> > /*
>> > - * We play games with efi_enabled so that the compiler will, if
>possible, remove
>> > - * EFI-related code altogether.
>> > + * We play games with efi_enabled so that the compiler will, if
>> > + * possible, remove EFI-related code altogether.
>> > */
>> > +#define EFI_BOOT 0x00000001 /* Were we booted from EFI? */
>> > +#define EFI_SYSTEM_TABLES 0x00000002 /* Can we use EFI system
>tables? */
>> > +#define EFI_CONFIG_TABLES 0x00000004 /* Can we use EFI config
>tables? */
>> > +#define EFI_RUNTIME_SERVICES 0x00000004 /* Can we use runtime
>services? */
>> > +#define EFI_MEMMAP 0x00000008 /* Can we use EFI memory map? */
>> > +#define EFI_64BIT 0x00000010 /* Is the firmware 64-bit? */
>> > +
>>
>> Your use of test_bit() and set_bit() imply that these macros should
>be
>> bit numbers, not bit masks. It'll work until you define a mask with
>an
>> integer value greater then 31.
>
>They're not intended to be bitmasks in the sense that no two bits are
>set in each constant (and I am aware of the upper limit).
>
>I have no problem changing the above values to bit numbers if that
>would
>be less confusing.
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists