All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	x86@kernel.org, linux-pci@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Intel-gfx] [PATCH v4] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals
Date: Thu, 13 Jan 2022 15:28:05 -0500	[thread overview]
Message-ID: <YeCLVeAjskTCiflA@intel.com> (raw)
In-Reply-To: <20220113012829.pquif5ujboyohzld@ldmartin-desk2>

On Wed, Jan 12, 2022 at 05:28:29PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 07:06:45PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > > > On Wed, Jan 12, 2022 at 03:30:43PM -0800, Lucas De Marchi wrote:
> > > > > The flags are only used to mark a quirk to be called once and nothing
> > > > > else. Also, that logic may not be appropriate if the quirk wants to
> > > > > do additional filtering and set quirk as applied by itself.
> > > > >
> > > > > So replace the uses of QFLAG_APPLY_ONCE with static local variables in
> > > > > the few quirks that use this logic and remove all the flags logic.
> > > > >
> > > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
> > > >
> > > > Only occurred to me now, but another, less intrusive approach would be
> > > > to just remove QFLAG_APPLY_ONCE from intel_graphics_quirks() and do
> > > > its bookkeeping internally, e.g.,
> > > 
> > > that is actually what I suggested after your comment in v2: this would
> > > be the first patch with "minimal fix". But then to keep it consistent
> > > with the other calls to follow up with additional patches on top
> > > converting them as well.  Maybe what I wrote wasn't clear in the
> > > direction? Copying it here:
> > > 
> > > 	1) add the static local only to intel graphics quirk  and remove the
> > > 	flag from this item
> > > 	2 and 3) add the static local to other functions and remove the flag
> > > 	from those items
> > > 	4) remove the flag from the table, the defines and its usage.
> > > 	5) fix the coding style (to be clear, it's already wrong, not
> > > 	something wrong introduced here... maybe could be squashed in (4)?)
> > 
> > Oh, sorry, I guess I just skimmed over that without really
> > comprehending it.
> > 
> > Although the patch below is basically just 1 from above and doesn't
> > require any changes to the other functions or the flags themselves
> > (2-4 above).
> 
> Yes, but I would do the rest of the conversion anyway. It would be odd
> to be inconsistent with just a few functions. So in the end I think we
> would achieve the same goal.
> 
> I would really prefer this approach, having the bug fix first, if I was
> concerned about having to backport this to linux-stable beyond 5.10.y
> (we have a trivial conflict on 5.10).
> 
> However given this situation is new (Intel GPU + Intel Discrete GPU)
> rare (it also needs a PCI topology in a certain way to reproduce it),
> I'm not too concerned. Not even sure if it's worth submitting to
> linux-stable.

+1 on the minimal fix approach first and send that to stable 5.10+.
We will hit this case for sure.

also +1 on the discussed ideas as a follow up.

> 
> I'll wait others to chime in on one way vs the other.
> 
> thanks
> Lucas De Marchi

WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	linux-pci@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Intel-gfx] [PATCH v4] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals
Date: Thu, 13 Jan 2022 15:28:05 -0500	[thread overview]
Message-ID: <YeCLVeAjskTCiflA@intel.com> (raw)
In-Reply-To: <20220113012829.pquif5ujboyohzld@ldmartin-desk2>

On Wed, Jan 12, 2022 at 05:28:29PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 07:06:45PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > > > On Wed, Jan 12, 2022 at 03:30:43PM -0800, Lucas De Marchi wrote:
> > > > > The flags are only used to mark a quirk to be called once and nothing
> > > > > else. Also, that logic may not be appropriate if the quirk wants to
> > > > > do additional filtering and set quirk as applied by itself.
> > > > >
> > > > > So replace the uses of QFLAG_APPLY_ONCE with static local variables in
> > > > > the few quirks that use this logic and remove all the flags logic.
> > > > >
> > > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > > Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
> > > >
> > > > Only occurred to me now, but another, less intrusive approach would be
> > > > to just remove QFLAG_APPLY_ONCE from intel_graphics_quirks() and do
> > > > its bookkeeping internally, e.g.,
> > > 
> > > that is actually what I suggested after your comment in v2: this would
> > > be the first patch with "minimal fix". But then to keep it consistent
> > > with the other calls to follow up with additional patches on top
> > > converting them as well.  Maybe what I wrote wasn't clear in the
> > > direction? Copying it here:
> > > 
> > > 	1) add the static local only to intel graphics quirk  and remove the
> > > 	flag from this item
> > > 	2 and 3) add the static local to other functions and remove the flag
> > > 	from those items
> > > 	4) remove the flag from the table, the defines and its usage.
> > > 	5) fix the coding style (to be clear, it's already wrong, not
> > > 	something wrong introduced here... maybe could be squashed in (4)?)
> > 
> > Oh, sorry, I guess I just skimmed over that without really
> > comprehending it.
> > 
> > Although the patch below is basically just 1 from above and doesn't
> > require any changes to the other functions or the flags themselves
> > (2-4 above).
> 
> Yes, but I would do the rest of the conversion anyway. It would be odd
> to be inconsistent with just a few functions. So in the end I think we
> would achieve the same goal.
> 
> I would really prefer this approach, having the bug fix first, if I was
> concerned about having to backport this to linux-stable beyond 5.10.y
> (we have a trivial conflict on 5.10).
> 
> However given this situation is new (Intel GPU + Intel Discrete GPU)
> rare (it also needs a PCI topology in a certain way to reproduce it),
> I'm not too concerned. Not even sure if it's worth submitting to
> linux-stable.

+1 on the minimal fix approach first and send that to stable 5.10+.
We will hit this case for sure.

also +1 on the discussed ideas as a follow up.

> 
> I'll wait others to chime in on one way vs the other.
> 
> thanks
> Lucas De Marchi

  reply	other threads:[~2022-01-13 20:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 21:05 [PATCH v3 1/3] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals Lucas De Marchi
2022-01-07 21:05 ` [Intel-gfx] " Lucas De Marchi
2022-01-07 21:05 ` [PATCH v3 2/3] x86/quirks: Improve line wrap on quirk conditions Lucas De Marchi
2022-01-07 21:05   ` [Intel-gfx] " Lucas De Marchi
2022-01-10 17:11   ` Rodrigo Vivi
2022-01-10 17:11     ` Rodrigo Vivi
2022-01-07 21:05 ` [PATCH v3 3/3] x86/quirks: Fix stolen detection with integrated + discrete GPU Lucas De Marchi
2022-01-07 21:05   ` [Intel-gfx] " Lucas De Marchi
2022-01-08  2:57   ` Bjorn Helgaas
2022-01-08  2:57     ` [Intel-gfx] " Bjorn Helgaas
2022-01-10 17:11     ` Rodrigo Vivi
2022-01-10 17:11       ` Rodrigo Vivi
2022-01-10 17:32       ` Bjorn Helgaas
2022-01-10 17:32         ` Bjorn Helgaas
2022-01-10 17:37         ` Rodrigo Vivi
2022-01-10 17:37           ` Rodrigo Vivi
2022-01-07 21:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals Patchwork
2022-01-07 23:00 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-01-08  2:53 ` [PATCH v3 1/3] " Bjorn Helgaas
2022-01-08  2:53   ` [Intel-gfx] " Bjorn Helgaas
2022-01-12 23:30   ` [PATCH v4] " Lucas De Marchi
2022-01-12 23:30     ` [Intel-gfx] " Lucas De Marchi
2022-01-13  0:08     ` Bjorn Helgaas
2022-01-13  0:08       ` Bjorn Helgaas
2022-01-13  0:21       ` Lucas De Marchi
2022-01-13  0:21         ` Lucas De Marchi
2022-01-13  1:06         ` Bjorn Helgaas
2022-01-13  1:06           ` Bjorn Helgaas
2022-01-13  1:28           ` Lucas De Marchi
2022-01-13  1:28             ` Lucas De Marchi
2022-01-13 20:28             ` Rodrigo Vivi [this message]
2022-01-13 20:28               ` Rodrigo Vivi
2022-01-13  0:23 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v4] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals (rev3) Patchwork
2022-01-13  0:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4] x86/quirks: Replace QFLAG_APPLY_ONCE with static locals (rev2) 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=YeCLVeAjskTCiflA@intel.com \
    --to=rodrigo.vivi@intel.com \
    --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=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.