Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote: > > On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley < > james.bottom...@hansenpartnership.com> wrote: > > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: [...] > > > > I do wish we coul

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote: > > Am 28.02.22 um 21:42 schrieb James Bottomley: > > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: > > > Am 28.02.22 um 20:56 schrieb Linus Torvalds: > > > > On Mon, Feb 28, 2022 at 4:19

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: > Am 28.02.22 um 20:56 schrieb Linus Torvalds: > > On Mon, Feb 28, 2022 at 4:19 AM Christian König > > wrote: > > > I don't think that using the extra variable makes the code in any > > > way > > > more reliable or easier to read. > > So I

Re: [Intel-gfx] [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected

2020-12-07 Thread James Bottomley
On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except

Re: [Intel-gfx] [PATCH v3 1/4] irq: export kstat_irqs

2020-12-06 Thread James Bottomley
On Sun, 2020-12-06 at 17:40 +0100, Thomas Gleixner wrote: > On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote: > > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote: > > > To try and detect potential interrupt storms that > > > have been occurring with tpm_tis devices it was

Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread James Bottomley
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote: > On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > > Really, no ... something which produces no improvement has no value > > at all ... we really shouldn't be wasting maintainer time with it > > because i

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote: > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley > wrote: > > Well, I used git. It says that as of today in Linus' tree we have > > 889 patches related to fall throughs and the first series went in > > in october 20

Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote: > On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote: > > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > > > On Sun,

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > wrote: > > Well, it seems to be three years of someone's time plus the > > maintainer review time and series disruption of nearly a thousand > > patches. Let's be

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread James Bottomley
On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote: > But is anyone keeping score of the regressions? If unreported bugs > count, what about unreported regressions? Well, I was curious about the former (obviously no tool will tell me about the latter), so I asked git what patches had a

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread James Bottomley
On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote: > On Sun, Nov 22, 2020 at 7:22 PM James Bottomley > wrote: > > Well, it's a problem in an error leg, sure, but it's not a really > > compelling reason for a 141 patch series, is it? All that fixing > > this error w

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread James Bottomley
On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote: > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote: > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > > > Please tell me our re

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread James Bottomley
On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote: > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote: > > Please tell me our reward for all this effort isn't a single > > missing error print. > > There were quite literally dozens of logical defects found > by t

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread James Bottomley
On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote: > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A.

Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot

2020-11-22 Thread James Bottomley
On Sun, 2020-11-22 at 08:10 -0800, Tom Rix wrote: > On 11/22/20 6:56 AM, Matthew Wilcox wrote: > > On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote: > > > On 11/21/20 7:23 PM, Matthew Wilcox wrote: > > > > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com > > > > wrote: > > > > >

Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot

2020-11-21 Thread James Bottomley
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: > A difficult part of automating commits is composing the subsystem > preamble in the commit log. For the ongoing effort of a fixer > producing > one or two fixes a release the use of 'treewide:' does not seem > appropriate. > > It would

Re: [Intel-gfx] [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-09 Thread James Bottomley
On Fri, 2020-10-09 at 14:34 -0700, Eric Biggers wrote: > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > The kmap() calls in this FS are localized to a single thread. To > > avoid the over head of global PKRS updates use the new > > kmap_thread()

Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API

2020-08-19 Thread James Bottomley
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote: > > [...] > > > > Since both threads seem to have petered out, let me suggest in > > > > kernel.h: > > > > > > > > #define cast_out(ptr, container, member) \ > > > > container_of(ptr, typeof(*container), member) > > > > > > > > It does what you

Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API

2020-08-19 Thread James Bottomley
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote: > On 8/18/20 1:00 PM, James Bottomley wrote: [...] > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_o

Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API

2020-08-18 Thread James Bottomley
On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote: > On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 12:4

Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API

2020-08-18 Thread James Bottomley
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > On 8/17/20 12:48 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > On 8/17/20 2:15 AM,

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-17 Thread James Bottomley
On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote: > Hi Jose, > > Souza, Jose schreef op di 16-07-2019 om 16:32 [+]: > > Paul and James could you test this final solution(at least for > > 5.2)? Please revert the hack patch and apply this one. > > I've just reached a day of uptime with your

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-12 Thread James Bottomley
On Thu, 2019-07-11 at 16:40 -0700, James Bottomley wrote: > On Thu, 2019-07-11 at 23:28 +, Souza, Jose wrote: > > On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote: > > > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]: > > > > On Thu, 2019-07-11 at

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-11 Thread James Bottomley
On Thu, 2019-07-11 at 23:28 +, Souza, Jose wrote: > On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote: > > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]: > > > On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote: > > > > It eventually comes back f

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-11 Thread James Bottomley
On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote: > On Thu, 2019-07-11 at 14:57 -0700, James Bottomley wrote: > > On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote: > > > I've also updated to the released 5.2 kernel and am running with > > > the > >

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-11 Thread James Bottomley
On Thu, 2019-07-11 at 20:25 +, Souza, Jose wrote: > On Thu, 2019-07-11 at 13:11 -0700, James Bottomley wrote: > > On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote: > > > Quoting James Bottomley (2019-06-29 19:56:52) > > > > The symptoms are really wei

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-11 Thread James Bottomley
On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote: > Quoting James Bottomley (2019-06-29 19:56:52) > > The symptoms are really weird: the screen image is locked in > > place. The machine is still functional and if I log in over the > > network can do anything I like, in

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-10 Thread James Bottomley
On Wed, 2019-07-10 at 23:59 +0200, Paul Bolle wrote: > James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]: > > I can get back to it this afternoon, when I'm done with the meeting > > requirements and doing other dev stuff. > > I've started bisecting using your suggest

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-10 Thread James Bottomley
On Wed, 2019-07-10 at 18:45 +0200, Paul Bolle wrote: > James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]: > > You seem to be getting it to happen much more often than I can. > > Last > > night, on the below pull request it took me a good hour to see the > >

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-10 Thread James Bottomley
On Wed, 2019-07-10 at 18:16 +0200, Paul Bolle wrote: > Hi James, > > James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]: > > I've confirmed that 5.1 doesn't have the regression and I'm now > > trying to bisect the 5.2 merge window, but since the problem takes > >

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-07-10 Thread James Bottomley
On Sat, 2019-06-29 at 11:56 -0700, James Bottomley wrote: > The symptoms are really weird: the screen image is locked in place. > The machine is still functional and if I log in over the network I > can do anything I like, including killing the X server and the > display will

screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

2019-06-29 Thread James Bottomley
The symptoms are really weird: the screen image is locked in place. The machine is still functional and if I log in over the network I can do anything I like, including killing the X server and the display will never alter. It also seems that the system is accepting keyboard input because when

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-09-19 Thread James Bottomley
On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote: > On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: > > Hi! James & Paulo: What's the current status of this? > > No, the only interaction has been the suggestion below for a revert, > which

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-09-19 Thread James Bottomley
> asking, because this issue is on the list of regressions for 4.8. I'm just about to try out -rc7, but it's not fixed so far. James > Ciao, Thorsten > > On 01.09.2016 00:25, James Bottomley wrote: > > On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote: > > &

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote: > Hi > > Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: > > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > > > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > We seem to have an xrandr regression with skylake now. What's > > happening is that I can get output on to a projector, but the > > system is losin

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > We seem to have an xrandr regression with skylake now. What's > happening is that I can get output on to a projector, but the system > is losing video when I change the xrandr sessions (like going from a > --above b to a

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-26 Thread James Bottomley
On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > We seem to have an xrandr regression with skylake now. What's > happening is that I can get output on to a projector, but the system > is losing video when I change the xrandr sessions (like going from a > --above b to a

[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-26 Thread James Bottomley
We seem to have an xrandr regression with skylake now. What's happening is that I can get output on to a projector, but the system is losing video when I change the xrandr sessions (like going from a - -above b to a --same-as b). The main screen goes blank, which is basically a reboot situation.

Re: [Intel-gfx] [PATCH] drm/i915: Ignore panel type from OpRegion on SKL

2016-07-13 Thread James Bottomley
vswing for eDP, whereas the VBT panel type (2) tells us to use normal > vswing. The problem is that low vswing results in some display > flickers. > Since no one seems to know how this stuff is supposed to be handled, > let's just ignore the OpRegion panel type on SKL for no

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-08 Thread James Bottomley
On Fri, 2016-07-08 at 13:19 +0300, Ville Syrjälä wrote: > On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote: > > On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote: > > > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote: > > > > On Tue, Ju

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-07 Thread James Bottomley
On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote: > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote: > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > > > > On

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-07-07 Thread James Bottomley
On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote: > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote: > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote: > > > > Cc: Vil

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-23 Thread James Bottomley
On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote: > On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote: > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote: > > > > Cc: Ville &

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-21 Thread James Bottomley
On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote: > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote: > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote: > > > Cc: Ville > > > > > > On Mon, 20 Jun 2016, James Bottomley < >

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-19 Thread James Bottomley
On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > On Fri, 17 Jun 2016, Daniel Vetter <dan...@ffwll.ch> wrote: > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > > On T

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-17 Thread James Bottomley
On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > On Fri, 17 Jun 2016, Daniel Vetter <dan...@ffwll.ch> wrote: > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > On Th

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-17 Thread James Bottomley
On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > On Fri, 17 Jun 2016, Daniel Vetter <dan...@ffwll.ch> wrote: > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > On Th

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-16 Thread James Bottomley
On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > I guess we'll need the bisect on this one to make progress. > > Sigh, I was afraid that might be the next step. OK, I have a curious data point. I assumed th

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-16 Thread James Bottomley
On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote: > > > On Tue, 31 May 2016, James Bot

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-06-16 Thread James Bottomley
On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote: > On Tue, 31 May 2016, James Bottomley < > james.bottom...@hansenpartnership.com> wrote: > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote: > > > On Mon, 30 May 2016, James Bottomley < > > > james

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-05-31 Thread James Bottomley
On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote: > On Mon, 30 May 2016, James Bottomley < > james.bottom...@hansenpartnership.com> wrote: > > I've tested a pristine 4.6.0 system, so it's definitely something > > that > > went in during the merge window. The flic

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

2016-05-30 Thread James Bottomley
I've tested a pristine 4.6.0 system, so it's definitely something that went in during the merge window. The flicker isn't continuous, it's periodic, with an interval of something like 2-5 seconds. It looks like an old analogue TV going out of sync and then resyncing. I've attached the dmesg and

[Intel-gfx] i915 Sky Lake graphics problem: screen blank after grub boot

2015-12-18 Thread James Bottomley
With kernel 4.3.x (tested x=2,3) the screen goes blank as soon as the system boots (both for VGA console and graphics). The only way to get it to turn on is to suspend and resume the system. The system is a Dell XPS 13 (latest rev) running OpenSuse Leap 42.1 and this is the lspci output: