Re: [PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 04, 2014 at 03:12:27PM -0700, Todd Previte wrote:
> >Does it really need to be uint8_t? I see on patch 7 that you don't
> >really write this value to a place that only accepts uint8_t-sized
> >arguments, so I fear that if we get 256 NACKs or DEFERs we may end up
> >doing the wrong thing.
> 
> There are no compliance tests that are concerned with the number of native
> DEFERs or NACKs received, hence why they are not addressed here.
> There's no requirement for the size of this value and I selected uint8_t as
> the smallest reasonable size for it. It's only used to count the number of
> NACKs and DEFERs during compliance testing and it gets reset to 0 at the
> beginning of the test block where it's used in a later patch. It's unlikely
> that a case would occur during this compliance test where exactly 256 NACKs
> or DEFERs occur, but your point is well-taken. I'll make them uint32s and be
> done with it. I don't think 6 extra bytes is going to run the kernel out of
> memory. :)

Du to struct alignement rules a lone uint8_t will actually occupy as much
as a plain unsigned. Also uint8_t in drivers has a bit the air of a
carefully picked size, usually in relation to some hw limit (e.g. register
size).

Imo just go with unsigned, it's clearer in intent and actually doesn't use
more space.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux