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 <m...@console-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.flem...@intel.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
