From: Alyssa Rosenzweig <alyssa@collabora.com>
To: Adri??n Larumbe <adrian.larumbe@collabora.com>
Cc: dri-devel@lists.freedesktop.org, alyssa.rosenzweig@collabora.com,
tomeu.vizoso@collabora.com, steven.price@arm.com
Subject: Re: [PATCH v3 1/1] drm/panfrost: Add support for devcoredump
Date: Wed, 22 Jun 2022 10:16:32 -0400 [thread overview]
Message-ID: <YrMkQMLIwoNJxlK/@maud> (raw)
In-Reply-To: <20220622140058.3oykas4zfxprmv56@sobremesa>
> Sorry about this blunder.
>
> >> + slot = panfrost_job_get_slot(job);
> >> + slot = slot ? slot : 0;
> >
> >`slot = slot ? slot : 0` is a no-op. Delete the line.
>
> I think what I meant here was 'slot = (slot >= 0) ? slot : 0;' but for some
> reason I blundered again. The point of this was ensuring the slot value wouldn't
> end up wrapping about the maximum unsigned integer value when using it as an
> array offset, in the off-chance that panfrost_job_get_slot() ever returned a
> negative value.
>
> In v4 I've instead rewritten this as a sanity check:
>
> WARN_ON(slot < 0);
No, this doesn't make sense. There at most 3 job slots -- 0, 1, and 2.
> Although perhaps in the future panfrost_job_get_slot should return an unsigned
> integer instead?
Sure. Kernel style doesn't seem big on unsigned, if this were
mesa it would return unsigned. Returning u8 or u32 seems reasonable at
any rate.
> >As a general note, I'd appreciate breaking out the panfrost_regs.h
> >changes into a separate patch, as they are a logically separate clean
> >up to make room for this patch. Thanks.
>
> Done in v4.
Thanks!
Alyssa
next prev parent reply other threads:[~2022-06-22 14:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 1:54 [PATCH v3 0/1] devcoredump support for Panfrost GPU driver Adrián Larumbe
2022-06-22 1:54 ` [PATCH v3 1/1] drm/panfrost: Add support for devcoredump Adrián Larumbe
2022-06-22 12:17 ` Alyssa Rosenzweig
2022-06-22 14:00 ` Adri??n Larumbe
2022-06-22 14:16 ` Alyssa Rosenzweig [this message]
2022-06-22 12:29 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YrMkQMLIwoNJxlK/@maud \
--to=alyssa@collabora.com \
--cc=adrian.larumbe@collabora.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=steven.price@arm.com \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox