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]
Message-ID: <21d7e9971001091341j313e6274vd883c0d5301b2586@mail.gmail.com>
Date:	Sun, 10 Jan 2010 07:41:00 +1000
From:	Dave Airlie <airlied@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Eric Anholt <eric@...olt.net>,
	Zhenyu Wang <zhenyuw@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH] i915: Always register as a PCI driver (was: Re: [PATCH] 
	DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS)

On Sat, Jan 9, 2010 at 11:35 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Saturday 09 January 2010, Jesse Barnes wrote:
>> On Fri, 8 Jan 2010 16:50:57 -0800 (PST)
>> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>>
>> >
>> >
>> > On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
>> > >
>> > > Which is functionally equivalent to my patch, because
>> > > i915_suspend/resume() won't be called by drm_class_suspend/resume()
>> > > in the KMS case anyway.
>> >
>> > Ahh, right you are - that class suspend function does a check for
>> > DRIVER_MODESET, and only does the suspend/resume if it's not a
>> > MODESET driver.
>> >
>> > Ok, so I withdraw my objections to your original patch - it's
>> > confusing, but that's just because DRM is such a horrible mess with
>> > subtle things.
>>
>> Yeah the non-KMS paths just suck.
>>
>> Acked-by: Jesse Barnes <jbarnes@...tuousgeek.org>
>>
>> Though hopefully you can get the PCI driver registration working w/o
>> too much trouble; that would be even better.
>
> Actually, I have a working patch, with one tiny detail I'm not sure of.
>
> Namely, I need to call pci_set_drvdata(pdev, dev) unconditionally in drm_stub.c
> for the things to work, but I _think_ it won't hurt even if we're not going to
> use the pdev's private data.
>
> The benefit of this is having just one code path for suspend/resume instead of
> two different code paths depending on whether the driver is using the KMS or
> not, which is well worth it IMO.
>
> The patch is appended.

NAK

for the reasons I explained in the previous email. This conflicts with systems
where intelfb and intel drm are used together, this is something that ppl do use
prior to KMS happening.

We just need to document in the headers why the hooks are needed,
and maybe a bit of patch review to make sure nobody removes them again.

Dave.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ