linux-kernel - Re: [RFC] Initial OLPC Viafb merge

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: <4BBFCE24.2070207@gmx.de>
Date:	Sat, 10 Apr 2010 03:02:28 +0200
From:	Florian Tobias Schandinat <FlorianSchandinat@....de>
To:	Jonathan Corbet <corbet@....net>
CC:	linux-kernel@...r.kernel.org, Harald Welte <laforge@...monks.org>,
	JosephChan@....com.tw, ScottFang@...tech.com.cn,
	Deepak Saxena <dsaxena@...top.org>,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: [RFC] Initial OLPC Viafb merge

Jonathan Corbet schrieb:
> On Sat, 10 Apr 2010 01:32:36 +0200
> Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:
> 
>> Please correct me if I am wrong but the remaining 6 patches concerning 
>> suspend&resume look like a real big FIXME. So at the end it is expected 
>> to work only on VX855 and needs something called OFW?
> 
> OFW = OpenFirmware.  You could say BIOS instead.  It's pretty normal to
> expect the BIOS to put things into a semi-rational state at resume time.

So its more or less the same I always do for testing the module.

> Well, if we want to keep s/r out of tree, we can do that.  It will
> complicate the merge of the other stuff, since it's got hooks into the
> GPIO and camera code too.  But, like everything else I've posted so
> far, it's not the work that I personally set out to do.  I can push
> that work on others :)
> 
> That said, the suspend/resume support in this patch set makes suspend
> work on one chipset, and probably comes pretty close on the others
> without breaking anything there.  I don't see the harm in merging it;
> it makes the code better than it is now.  I would rather not have to
> separate it out from the rest.  But I'll not fight over this one; if
> there's real opposition then we can force OLPC to continue to carry it
> out of tree.

At least I'd like some more time (multiple weeks) to have a look at this 
issue & patches and try to come up with improvements that make it likely 
work on other IGPs and eventually not needing any BIOS/OFW. I agree its 
already an improvement but certainly one of the kind I like less as VIA 
could come up with such "improvements" too. IMHO it's a bad thing to 
push one chipset first if the target is to support all equally well (as 
long as the hardware permits).
So I'd be glad if you could go on with the patches that are less painful 
and get them ready for the merge window (as I really don't have a clue 
how long it will take me to get the suspend/resume stuff to a state I 
consider acceptable). Perhaps we should make suspend and resume a 
configure option and mark it as experimental?

Thanks,

Florian Tobias Schandinat
--
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/