On 1/19/24 09:54, Jiri Slaby wrote:
> Hi,
>
> On 19. 01. 24, 10:43, Tudor Ambarus wrote:
>>>> If using unsigned int the bitfied is combined with the previous u8
>>>> fields, whereas if using u8 the bitfield will be independently defined.
>>>> So no benefit in terms of memory footprint, it's just a cosmetic change
>>>> to align the bitfield with the previous u8 fields. Allowing u32 for
>>>> just
>>>> a bit can be misleading as one would ask itself where are the other
>>>> bits. Between a u32 bitfield and a bool a u8 bitfield seems like a good
>>>> compromise.
>>>
>>> Why? What's wrong with bool? bitfields have terrible semantics wrt
>>> atomic writes for example.
>>>
>>
>> Bool occupies a byte and if more port features will ever be added we'll
>> occupy more bytes. Here's how the structure will look like with a bool:
>>
>> struct s3c24xx_uart_info {
>> const char * name; /* 0 8 */
>> enum s3c24xx_port_type type; /* 8 4 */
>> unsigned int port_type; /* 12 4 */
>> unsigned int fifosize; /* 16 4 */
>> u32 rx_fifomask; /* 20 4 */
>> u32 rx_fifoshift; /* 24 4 */
>> u32 rx_fifofull; /* 28 4 */
>> u32 tx_fifomask; /* 32 4 */
>> u32 tx_fifoshift; /* 36 4 */
>> u32 tx_fifofull; /* 40 4 */
>> u32 clksel_mask; /* 44 4 */
>> u32 clksel_shift; /* 48 4 */
>> u32 ucon_mask; /* 52 4 */
>> u8 def_clk_sel; /* 56 1 */
>> u8 num_clks; /* 57 1 */
>> u8 iotype; /* 58 1 */
>> bool has_divslot; /* 59 1 */
>>
>> /* size: 64, cachelines: 1, members: 17 */
>> /* padding: 4 */
>> };
>>
>> What's your preference?
>
> bool :).
>
I'm fine with a bool too as since the introduction of this driver we
have just this flag, it's unlikey to have 4 more soon to bypass the
first cacheline. Will change to bool.
Cheers,
ta
