Re: [PATCH] rc-core: add separate defines for protocol bitmaps and numbers

["David Härdeman" <david@hardeman.nu>]

On Mon, Dec 17, 2012 at 03:15:27PM +0000, James Hogan wrote:
>On 12 October 2012 00:11, David Härdeman <david@hardeman.nu> wrote:
>> The RC_TYPE_* defines are currently used both where a single protocol is
>> expected and where a bitmap of protocols is expected. This patch tries
>> to separate the two in preparation for the following patches.
>>
>> The intended use is also clearer to anyone reading the code. Where a
>> single protocol is expected, enum rc_type is used, where one or more
>> protocol(s) are expected, something like u64 is used.
>>
>> The patch has been rewritten so that the format of the sysfs "protocols"
>> file is no longer altered (at the loss of some detail). The file itself
>> should probably be deprecated in the future though.
>>
>> I missed some drivers when creating the last version of the patch because
>> some weren't enabled in my .config. This patch passes an allmodyes build.
>>
>> Signed-off-by: David Härdeman <david@hardeman.nu>
>> ---
>
>> @@ -38,7 +70,7 @@ struct rc_map {
>>         unsigned int            size;   /* Max number of entries */
>>         unsigned int            len;    /* Used number of entries */
>>         unsigned int            alloc;  /* Size of *scan in bytes */
>> -       u64                     rc_type;
>> +       enum rc_type            rc_type;
>>         const char              *name;
>>         spinlock_t              lock;
>>  };
>
>But store_protocols() sets dev->rc_map.rc_type to a bitmap. Am I
>missing something?

That was fixed in later patches (by introducing a u64 enabled_protocols
member to struct rc_dev which is used by store_protocols() and
show_protocols()).

I'll split that part out to a separate patch and submit.

-- 
David Härdeman