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
| ||
|
Date: Fri, 9 Apr 2010 18:27:22 -0600 From: Jonathan Corbet <corbet@....net> To: Florian Tobias Schandinat <FlorianSchandinat@....de> 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 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. > It doesn't seem to make much sense to review each of them because the > following patches might or might not correct some of the issues of the > other. It is really a pain to have 6 patches trying to add a single > feature. Is there any way to fix this mess. (I assume you didn't merge > them due to authorship issues?) It's true that one needs to look at the end product. I only looked at the S/R code recently, and tried to fix some of the biggest issues that would keep it out of the mainline. > I think it might be better to drop those for now and wait for viafb to > be in a better shape before adding this feature. The mode setting should > be in a pretty good shape just 1 or 2 kernel versions ahead so that the > dependency on OFW can be dropped I think. > > Sorry but I really think this is not in a shape where merging it is an > option. I think it would be better to skip those suspend/resume patches > for the next merge window. 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. jon -- 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