linux-kernel - Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Jan 2010 18:50:41 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o
 KMS

On Sat, 9 Jan 2010 02:15:41 +0000 (GMT)
Dave Airlie <airlied@...ux.ie> wrote:

> > > From: Rafael J. Wysocki <rjw@...k.pl>
> > > 
> > > Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915:
> > > implement new pm ops for i915), among other things, removed
> > > the .suspend and .resume pointers from the struct drm_driver
> > > object in i915_drv.c, which broke resume without KMS on my MSI
> > > Wind U100.
> > > 
> > > Fix this by reverting that part of commit cbda12d77ea59.
> > 
> > Hmm. I get the feeling that perhaps the of the drm_driver callbacks
> > was very muchintentional, and that the code presumably wants to be
> > called purely through the PCI layer, and not through the "drm
> > class" logic at all?
> > 
> > Your patch seems like it would always execute the silly class
> > suspend even though we explicitly don't want to. And a much nicer
> > fix would seem to register the thing properly as a PCI driver even
> > if you don't then use KMS.
> > 
> > So it looks to me like the problem is that drm_init() will register
> > the driver as a real PCI driver only if
> > 
> > 	driver->driver_features & DRIVER_MODESET
> > 
> > and otherwise it does that very odd "stealth mode manual scanning"
> > thing which doesn't register it as a proper PCI driver.
> > 
> > So could we instead make that "disable KSM" _just_ disable the mode 
> > setting part, not disable the "I'm a real driver" part?
> > 
> 
> This was mainly due to pre-existing fb drivers binding to the device,
> and the drm drivers having to work around that, with KMS since we
> have fb in the drm driver its correct to bind, pre-kms its just a
> mess I'd rather stay away from.

Linus, can we ever drop those old paths?  Maybe after the new bits have
been around for awhile?  Users of really old userspace stacks would
lose 3D support, but they'd still have 2D, so it wouldn't be a complete
break.  The non-KMS paths sometimes break like this anyway without us
noticing (especially some of the weirder 3D paths)...

Just thinking out loud, we could really kill a lot of really bad code...

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/