On Wed, Jul 26, 2023 at 2:38 PM Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On 27/07/2023 00:37, Rob Clark wrote: > > On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > >> > >> On 07/07/2023 00:10, Rob Clark wrote: > >>> From: Rob Clark <robdclark@xxxxxxxxxxxx> > >>> > >>> /* Helper for formating the chip_id in the way that userspace tools like > >>> * crashdec expect. > >>> */ > >>> #define ADRENO_CHIPID_FMT "u.%u.%u.%u" > >>> -#define ADRENO_CHIPID_ARGS(_r) (_r).core, (_r).major, (_r).minor, (_r).patchid > >>> +#define ADRENO_CHIPID_ARGS(_c) \ > >>> + (((_c) >> 24) & 0xff), \ > >>> + (((_c) >> 16) & 0xff), \ > >>> + (((_c) >> 8) & 0xff), \ > >>> + ((_c) & 0xff) > >> > >> So, we still have some meaning for chipid? > > > > Only enough to do the inverse of what userspace does when parsing > > devcoredump to construct chip-id. Basically it is just a different > > way to represent a 32b # > > What about passing it in the direct form? The macro adds assumptions. It is uabi I wouldn't call it adding assumptions as much as just a funny way to format a number. In some cases it might work out to something that vaguely resembles a marketing name (6.3.0.2), in other cases it won't (12.34.56.78).. it's just formatting a 32b # to match the way existing userspace parses it BR, -R
