linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@chromium.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: "Stéphane Marchesin" <stephane.marchesin@gmail.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Grant Grundler" <grundler@chromium.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Michael Davidson" <md@google.com>,
	"Matthias Kaehlcke" <mka@chromium.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Stéphane Marchesin" <marcheu@chromium.org>
Subject: Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
Date: Fri, 14 Jul 2017 10:32:30 -0700	[thread overview]
Message-ID: <CANEJEGtxzaZKAjs8_LEsd3=2s_oyBrgm_zqzYmC1gSpvif6yig@mail.gmail.com> (raw)
In-Reply-To: <87eftjl6xg.fsf@nikula.org>

On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Thu, 13 Jul 2017, Stéphane Marchesin <stephane.marchesin@gmail.com> wrote:
>> So, if you think this is wrong, can you fix this warning in a way that
>> you'd like?
>
> As I replied previously [1], with more background, fixing the warnings
> properly, in a way that actually improves the code instead of making it
> worse, would mean a bunch of churn that's not just purely mechanical
> conversion.

That's fair.

> Unless you can point out a bug which is actually caused by mixing the
> types (which is mostly intentional, see the background) I have a hard
> time telling people this should be a priority.

This feels like "can't see the forest because of the trees".

The original patch was submitted in order to compile cleanly using
clang and the above suggests using clang is not important.  Using
clang is important to Matthias and the Chrome OS organization for many
good reasons - including better warnings.

The original patch message was clear that clang was generating the
warning. This isn't the only patch mka has sent to kernel devs. What
one can infer is Chrome OS is trying to move to clang (like other
Google products _already_ have.)  My impression is all these products
are a priority to Intel - but it would be good to know otherwise.

> Definitely something we'd
> like to do in the long run and pedantically correct (and I tend to
> prefer code that way) but we certainly have more important things to do.

The long run is now. Everyone agrees the code should change and you
don't have to do it. Matthias submitted an unacceptable patch and
giving him some concrete guidance on what would be acceptable would
enable him to implement/test it (or anyone else could for that
matter).  Can you do that?

Just give an example of what the "right" API looks like and see where it goes.

cheers,
grant

>
> BR,
> Jani.
>
> [1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com
>
>
> --
> Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2017-07-14 17:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 21:56 [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches Matthias Kaehlcke
2017-05-05 17:26 ` Matthias Kaehlcke
2017-05-05 17:40   ` [Intel-gfx] " Ville Syrjälä
2017-05-05 19:12     ` Grant Grundler
2017-05-05 20:08       ` Ville Syrjälä
2017-05-05 20:29         ` Grant Grundler
2017-05-05 21:37           ` Matthias Kaehlcke
2017-05-08  7:21     ` Daniel Vetter
2017-05-08  8:17       ` Jani Nikula
2017-07-13  2:28     ` Stéphane Marchesin
2017-07-13 10:13       ` Ville Syrjälä
2017-07-13 12:24         ` Daniel Vetter
2017-07-13 16:23         ` Stéphane Marchesin
2017-07-13 17:42           ` Ville Syrjälä
2017-07-13 19:58             ` Stéphane Marchesin
2017-07-14  9:11               ` Jani Nikula
2017-07-14 17:32                 ` Grant Grundler [this message]
2017-07-14 21:35                   ` Daniel Vetter
2017-07-14 22:43                     ` Grant Grundler
2017-07-14 23:38                       ` Matthias Kaehlcke

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='CANEJEGtxzaZKAjs8_LEsd3=2s_oyBrgm_zqzYmC1gSpvif6yig@mail.gmail.com' \
    --to=grundler@chromium.org \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=md@google.com \
    --cc=mka@chromium.org \
    --cc=stephane.marchesin@gmail.com \
    --cc=ville.syrjala@linux.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;
as well as URLs for NNTP newsgroup(s).