From: Andi Shyti <andi.shyti@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
lucas.demarchi@intel.com,
Aravind Iddamsetty <aravind.iddamsetty@intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
Date: Wed, 21 Sep 2022 00:33:34 +0200 [thread overview]
Message-ID: <Yyo/vqFb2bH116i/@ashyti-mobl2.lan> (raw)
In-Reply-To: <YyolVATWuGbXE/HT@mdroper-desk1.amr.corp.intel.com>
Hi Matt, Lucas,
thanks for your feedback,
> > > + switch (gms) {
> > > + case 0x0 ... 0x10:
> > > + return gms * 32;
> > > + case 0x20:
> > > + return 1024;
> > > + case 0x30:
> > > + return 1536;
> > > + case 0x40:
> > > + return 2048;
> > > + case 0xf0 ... 0xfe:
> >
> > just a bit puzzled by the fact that case ranges are not standard
> > and are supported only by GCC, unless, of course, I miss
> > something. Do we still want to use them as they are widely used
> > around the kernel?
>
> i915 already has 17 other uses of this notation and the DRM subsystem in
> general has about 50 today. So it's not super common, but I think it
> should be okay to use. I believe clang supports this language extension
> as well and the coding style doc doesn't say anything one way or the
> other.
I thought clang supports it for C++ rather than C, but I'm not a
clang expert, so that I might be wrong.
The fact that it is widely used is never a convincing argument
and if gcc supports it, then it does it against the standard,
both C11 and C17 (this is what puzzles me everytime I see these C
tricks offered by gcc).
Anyway, I'm not against it (nor in favour) as the ellipsis is
becoming very commonly used. My comment, by the way, did not mean
to block the patch, I just wanted to check what other people
think about.
Thanks,
Andi
prev parent reply other threads:[~2022-09-20 22:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 7:19 [PATCH 1/1] drm/i915/mtl: enable local stolen memory Aravind Iddamsetty
2022-09-20 7:35 ` Jani Nikula
2022-09-21 6:32 ` Iddamsetty, Aravind
2022-09-20 8:31 ` [Intel-gfx] " Lucas De Marchi
2022-09-20 20:05 ` Lucas De Marchi
2022-09-21 6:30 ` Iddamsetty, Aravind
2022-09-22 13:56 ` Lucas De Marchi
2022-09-22 15:56 ` Iddamsetty, Aravind
2022-09-20 16:57 ` Andi Shyti
2022-09-20 20:01 ` Lucas De Marchi
2022-09-20 20:40 ` Matt Roper
2022-09-20 22:33 ` Andi Shyti [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=Yyo/vqFb2bH116i/@ashyti-mobl2.lan \
--to=andi.shyti@linux.intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox