On 27/07/2023 00:44, Rob Clark wrote:
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
I see. Sounds fine then.
--
With best wishes
Dmitry
