All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	x86@kernel.org, stable@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU
Date: Tue, 18 Jan 2022 19:37:29 +0100	[thread overview]
Message-ID: <YecI6S9Cx5esqL+H@zn.tnic> (raw)
In-Reply-To: <20220118175853.GA881852@bhelgaas>

On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote:
> Thanks for writing this down!  I do the same for PCI.  I suspect this
> is a pretty conservative style that would be acceptable tree-wide even
> if not required everywhere.

Yeah, although that is an uphill battle. People do love their personal
pronouns in commit messages even if it reads weird. And don't get
me wrong - I used to do it too but tglx started with this passive
formulation and now I see how it is a lot less intrusive and keeps the
focus on the issue at hand.

> I don't really care much one way or the other.  I think the simplest
> approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks()
> and do nothing else, as I suggested here:
> 
>   https://lore.kernel.org/r/20220113000805.GA295089@bhelgaas
> 
> Unfortunately that didn't occur to me until I'd already suggested more
> complicated things that no longer seem worthwhile to me.
> 
> The static variable might be ugly, but it does seem to be what
> intel_graphics_quirks() wants -- a "do this at most once per system
> but we don't know exactly which device" situation.

I see.

Yeah, keeping it solely inside intel_graphics_quirks() and maybe with a
comment ontop, why it is done, is simple. I guess if more quirks need
this once-thing people might have to consider a more sensible scheme - I
was just objecting to sprinkling those static vars everywhere.

But your call. :)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: x86@kernel.org, linux-pci@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	stable@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU
Date: Tue, 18 Jan 2022 19:37:29 +0100	[thread overview]
Message-ID: <YecI6S9Cx5esqL+H@zn.tnic> (raw)
In-Reply-To: <20220118175853.GA881852@bhelgaas>

On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote:
> Thanks for writing this down!  I do the same for PCI.  I suspect this
> is a pretty conservative style that would be acceptable tree-wide even
> if not required everywhere.

Yeah, although that is an uphill battle. People do love their personal
pronouns in commit messages even if it reads weird. And don't get
me wrong - I used to do it too but tglx started with this passive
formulation and now I see how it is a lot less intrusive and keeps the
focus on the issue at hand.

> I don't really care much one way or the other.  I think the simplest
> approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks()
> and do nothing else, as I suggested here:
> 
>   https://lore.kernel.org/r/20220113000805.GA295089@bhelgaas
> 
> Unfortunately that didn't occur to me until I'd already suggested more
> complicated things that no longer seem worthwhile to me.
> 
> The static variable might be ugly, but it does seem to be what
> intel_graphics_quirks() wants -- a "do this at most once per system
> but we don't know exactly which device" situation.

I see.

Yeah, keeping it solely inside intel_graphics_quirks() and maybe with a
comment ontop, why it is done, is simple. I guess if more quirks need
this once-thing people might have to consider a more sensible scheme - I
was just objecting to sprinkling those static vars everywhere.

But your call. :)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2022-01-18 18:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14  0:28 [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU Lucas De Marchi
2022-01-14  0:28 ` [Intel-gfx] " Lucas De Marchi
2022-01-14  0:28 ` [PATCH v5 2/5] x86/quirks: Stop using QFLAG_APPLY_ONCE in via_bugs() Lucas De Marchi
2022-01-14  0:28   ` [Intel-gfx] " Lucas De Marchi
2022-01-14  0:28 ` [PATCH v5 3/5] x86/quirks: Stop using QFLAG_APPLY_ONCE in nvidia_bugs() Lucas De Marchi
2022-01-14  0:28   ` [Intel-gfx] " Lucas De Marchi
2022-01-14  0:28 ` [PATCH v5 4/5] x86/quirks: Remove unused logic for flags Lucas De Marchi
2022-01-14  0:28   ` [Intel-gfx] " Lucas De Marchi
2022-01-14  0:28 ` [PATCH v5 5/5] x86/quirks: Improve line wrap on quirk conditions Lucas De Marchi
2022-01-14  0:28   ` [Intel-gfx] " Lucas De Marchi
2022-01-14  1:25 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU Patchwork
2022-01-14  2:30 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-01-18  9:40 ` [PATCH v5 1/5] " Borislav Petkov
2022-01-18  9:40   ` [Intel-gfx] " Borislav Petkov
2022-01-18 16:36   ` Lucas De Marchi
2022-01-18 16:36     ` [Intel-gfx] " Lucas De Marchi
2022-01-18 17:26     ` Borislav Petkov
2022-01-18 17:26       ` [Intel-gfx] " Borislav Petkov
2022-01-18 17:58       ` Bjorn Helgaas
2022-01-18 17:58         ` Bjorn Helgaas
2022-01-18 18:37         ` Borislav Petkov [this message]
2022-01-18 18:37           ` Borislav Petkov
2022-01-18 20:01           ` Bjorn Helgaas
2022-01-18 20:01             ` Bjorn Helgaas
2022-01-18 20:31             ` Borislav Petkov
2022-01-18 20:31               ` Borislav Petkov
2022-01-19 20:30             ` Lucas De Marchi
2022-01-19 20:30               ` Lucas De Marchi
2022-01-19 20:58               ` Bjorn Helgaas
2022-01-19 20:58                 ` Bjorn Helgaas
2022-01-18 19:05       ` Lucas De Marchi
2022-01-18 19:05         ` [Intel-gfx] " Lucas De Marchi
2022-01-18 19:14         ` Borislav Petkov
2022-01-18 19:14           ` [Intel-gfx] " Borislav Petkov
2022-01-18 19:15 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev2) Patchwork
2022-01-18 20:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3) Patchwork
2022-01-18 20:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-18 23:01 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=YecI6S9Cx5esqL+H@zn.tnic \
    --to=bp@alien8.de \
    --cc=bhelgaas@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.