Re: [Intel-gfx] [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

* Martin Sebor wrote: > > I.e. the real workaround might be to turn off the > > -Wstringop-overread-warning, > > until GCC-11 gets fixed? > > In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow. > GCC 11 breaks it out as a separate warning to make it easier to > control. Both

Re: [Intel-gfx] [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

* Arnd Bergmann wrote: > From: Arnd Bergmann > > gcc-11 warns about using string operations on pointers that are > defined at compile time as offsets from a NULL pointer. Unfortunately > that also happens on the result of fix_to_virt(), which is a > compile-time constant for a constantn

Re: [Intel-gfx] [PATCH v2 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

* Jason A. Donenfeld wrote: > Very little has changed from last time, and this whole series still > looks good to me. I think I already ack'd most packages, but in case > it helps: > > Reviewed-by: Jason A. Donenfeld Acked-by: Ingo Molnar > Since this touches a lot

Re: [Intel-gfx] [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

gt; > I did not know that these had already landed in tip tree. > > They are immature version. > (In fact CONFIG_AS_CFI and AS_ADX are false-negative > if GCC that defaults to 32-bit is used.) > > Can you simply discard the WIP.x86/asm branch, > and only reapply > 16

Re: [Intel-gfx] [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

* Masahiro Yamada wrote: > This series of cleanups was prompted by Linus: > https://lkml.org/lkml/2020/3/12/726 > > First, this series drop always-on CONFIG_AS_* options. > Some of those options were introduced in old days. > For example, the check for CONFIG_AS_CFI dates back to 2006. > >

Re: [Intel-gfx] [patch V3 00/29] stacktrace: Consolidate stack trace usage

* Thomas Gleixner wrote: > - if (unlikely(!ret)) > + if (unlikely(!ret)) { > + if (!trace->nr_entries) { > + /* > + * If save_trace fails here, the printing might > + * trigger a WARN but because of the

Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory

* Rodrigo Vivi wrote: > > Cc: Thomas Gleixner > > > > > Cc: Ingo Molnar > > > > > Cc: H. Peter Anvin > > > > > Cc: x...@kernel.org > > > > guys, could we push this through drm-intel? ack? > > nack? comments? > >

Re: [Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks

<anusha.sriva...@intel.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: Ingo Molnar &

Re: [Intel-gfx] [PATCH v8 2/9] x86/early-quirks: export the stolen region as a resource

@intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> &

Re: [Intel-gfx] [PATCH v8 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

; > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: x...@kernel.org > Cc: linux-ker...@vge

Re: [Intel-gfx] [PATCH 2/8] x86/early-quirks: replace the magical increment start values

<joonas.lahti...@linux.intel.com> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel

Re: [Intel-gfx] [PATCH 1/8] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

* Matthew Auld wrote: > From: Joonas Lahtinen > > To give upcoming SKU BIOSes more flexibility in placing the Intel > graphics stolen memory, make all variables storing the placement or size > compatible with full 64 bit range. Also by

Re: [Intel-gfx] [PATCH] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

Cc: Matthew Auld <matthew.a...@intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: x...@kernel.org > --- > arch/x86

Re: [Intel-gfx] [PATCH 1/6] drm/i915: export the stolen region as a resource

* Joonas Lahtinen <joonas.lahti...@linux.intel.com> wrote: > + Dave as a heads-up > > On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote: > > * Matthew Auld <matthew.a...@intel.com> wrote: > > > > > We duplicate the stolen discovery code in early-qu

Re: [Intel-gfx] [PATCH 1/6] drm/i915: export the stolen region as a resource

lahti...@linux.intel.com> > Suggested-by: Chris Wilson <ch...@chris-wilson.co.uk> > Signed-off-by: Matthew Auld <matthew.a...@intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Paulo Zanoni <p

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

* Daniel Vetter <dan...@ffwll.ch> wrote: > On Tue, Oct 31, 2017 at 10:50:06AM +0100, Ingo Molnar wrote: > > > > * Hans de Goede <j.w.r.dego...@gmail.com> wrote: > > > > > intel_uncore_forcewake_reset() does forcewake puts and gets as such > > &g

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

* Hans de Goede wrote: > intel_uncore_forcewake_reset() does forcewake puts and gets as such > we need to make sure that no-one tries to access the PUNIT->PMIC bus > (on systems where this bus is shared) while it runs, otherwise bad > things happen. > > Normally this

Re: [Intel-gfx] [PATCH] x86/gpu: GLK uses the same GMS values as SKL

* Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Wed, 25 Jan 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote: > > On Wed, 25 Jan 2017, Ingo Molnar <mi...@kernel.org> wrote: > >> * Paulo Zanoni <paulo.r.zan...@intel.com> wrote: > >>

Re: [Intel-gfx] [PATCH] x86/gpu: GLK uses the same GMS values as SKL

* Paulo Zanoni <paulo.r.zan...@intel.com> wrote: > So don't forget to reserve its stolen memory bits. > > Cc: Ingo Molnar <mi...@kernel.org> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com> >

Re: [Intel-gfx] [RFC 0/6] Non perf based Gen Graphics OA unit driver

* Peter Zijlstra wrote: > > - We may be making some technical compromises a.t.m for the sake of > > using perf. > > > > perf_event_open() requires events to either relate to a pid or a > > specific cpu core, while our device pmu relates to neither. Events > >

Re: [Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

* Peter Zijlstra pet...@infradead.org wrote: As it is currently the kernel doesn't need to know anything about the semantics of individual counters being selected, so it's currently convenient that we can aim to maintain all the counter meta data we have in userspace according to

Re: [Intel-gfx] [RFC PATCH v2] perf: Add PERF_EVENT_IOC_FLUSH ioctl

* Robert Bragg rob...@sixbynine.org wrote: To allow for pmus that may have internal buffering (e.g. the hardware itself writes out data to its own circular buffer which is only periodically forwarded to userspace via perf) this ioctl enables userspace to explicitly ensure it has received all

Re: [Intel-gfx] [PATCH] x86: Enable fast 32-bit put_user_64 for copy_to_user

copy_to_user() fallback. Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org CC: linux-ker...@vger.kernel.org The patch makes sense, but your Signed-off-by line is missing. Thanks, Ingo

Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

* Daniel Vetter dan...@ffwll.ch wrote: On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote: Hi x86 folks, Ping on getting the gen2 stolen memory early quirk patches into the x86 tree. From our side Daniel and Chris both seemed happy with them, so I'd like to get them

Re: [Intel-gfx] [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

* ville.syrj...@linux.intel.com ville.syrj...@linux.intel.com wrote: v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods I guess v2 is a reaction to my review feedback? I got no reply to my mail from you so I'm not sure and I'd like to know whether all feedback was addressed.

Re: [Intel-gfx] [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

* Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote: * ville.syrj...@linux.intel.com ville.syrj...@linux.intel.com wrote: v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods I guess v2 is a reaction to my

Re: [Intel-gfx] [PATCH 2/8] x86: Add Intel graphics stolen memory quirk for gen2 platforms

...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- arch/x86/kernel/early-quirks.c | 70 ++ include/drm/i915_drm.h | 12 2

Re: [Intel-gfx] [RFC PATCH] drm/nouveau: fix nested locking in mmap handler

* Maarten Lankhorst maarten.lankho...@canonical.com wrote: I think the Nouveau guys need to comment further on this, but returning -EFAULT might break existing user-space, and that's not allowed, but IIRC the return value of presumed is only a hint, and if it's incorrect will only