From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/xe: Prefer BIT/GENMASK macros over shifts
Date: Tue, 30 Jan 2024 19:58:00 +0200 [thread overview]
Message-ID: <87ttmuitzr.fsf@intel.com> (raw)
In-Reply-To: <ZbkuXLIG1qpEd1Wg@DUT025-TGLU.fm.intel.com>
On Tue, 30 Jan 2024, Matthew Brost <matthew.brost@intel.com> wrote:
> On Wed, Jan 24, 2024 at 11:45:24AM +0200, Jani Nikula wrote:
>> On Tue, 23 Jan 2024, Matthew Brost <matthew.brost@intel.com> wrote:
>> > Using BIT/GENMASK macros is a better convention than using manual shift
>> > and will also fix build errors [1].
>>
>> One of the reasons i915 does not really use BIT and GENMASK directly is
>> that their type is unsigned long, and thus their size is different on 32
>> and 64 bit builds, while almost invariably you need one or the other to
>> describe hardware or firmware interfaces. Not something that depends on
>> the build.
>>
>> Using %lu or %lx as format specifier should work, but people find it
>> weird to have to use that for essentially 32-bit things, and forget. And
>> there's confusion when you still have stuff like:
>>
>> #define GUC_CTB_STATUS_NO_ERROR 0
>>
>> instead of 0UL i.e. some of the macros end up being unsigned long with
>> variable size, and some, like this, not.
>>
>> I'm sure the REG_BIT and REG_GENMASK macros feel off-putting for things
>> that aren't exactly registers (like the firmware interface), but let's
>> hope we get Lucas' fixed-size BIT and GENMASK macros merged [1], and can
>> use them.
>>
>
> I'm fine with using these new macros but I believe we need to get a fix
> into 6.8 and unsure if Lucas's series is going to land before then. Are
> you ok with landing this series as is for now and updating all of the
> defines in Xe in a follow up? Or do you have other ideas of how to
> proceed for 6.8?
I'll defer to the xe maintainers on this one. Just giving some
background what the issues with BIT/GENMASK were.
BR,
Jani.
--
Jani Nikula, Intel
prev parent reply other threads:[~2024-01-30 17:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 21:23 [PATCH v2] drm/xe: Prefer BIT/GENMASK macros over shifts Matthew Brost
2024-01-23 21:33 ` ✓ CI.Patch_applied: success for drm/xe: Prefer BIT/GENMASK macros over shifts (rev2) Patchwork
2024-01-23 21:33 ` ✗ CI.checkpatch: warning " Patchwork
2024-01-23 21:34 ` ✓ CI.KUnit: success " Patchwork
2024-01-23 21:41 ` ✓ CI.Build: " Patchwork
2024-01-23 21:42 ` ✓ CI.Hooks: " Patchwork
2024-01-23 21:43 ` ✓ CI.checksparse: " Patchwork
2024-01-23 22:06 ` ✓ CI.BAT: " Patchwork
2024-01-24 9:45 ` [PATCH v2] drm/xe: Prefer BIT/GENMASK macros over shifts Jani Nikula
2024-01-30 17:14 ` Matthew Brost
2024-01-30 17:58 ` Jani Nikula [this message]
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=87ttmuitzr.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.