Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754730AbbKQUfG (ORCPT ); Tue, 17 Nov 2015 15:35:06 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:36534 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752182AbbKQUfE (ORCPT ); Tue, 17 Nov 2015 15:35:04 -0500 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56c9:0:22cf:30ff:fe4c:37d6] In-Reply-To: References: <564AEC67.8020201@linux.intel.com> <87wpthdky8.fsf@intel.com> Date: Tue, 17 Nov 2015 21:35:03 +0100 Message-ID: Subject: Re: Regression on Chromebook Pixel 2015 due to i915 fastboot always-on From: Daniel Vetter To: Linus Torvalds Cc: Olof Johansson , Jani Nikula , Maarten Lankhorst , Dave Airlie , Duncan Laurie , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2164 Lines: 49 On Tue, Nov 17, 2015 at 7:18 PM, Linus Torvalds wrote: > On Tue, Nov 17, 2015 at 9:53 AM, Olof Johansson wrote: >> >> The problem as I see it is that it's unknown how many machines depends >> on previous behavior. If it's only Pixel 2015 then I think a whitelist >> would be just fine. > > Considering how many problems we historically have had with backlight > handling, I would strongly urge people to *not* start going down the > whitelist approach. > > If the backlight doesn't get set up correctly, the machine might as > well be considered dead. Very few people are going to give good > reports of it. So the backlight code needs to bend oevr backwards in > being robust even more so than most other code, and "whitelist > known-working setups" is absolutely the reverse of robust. It's a > hack, and it's guaranteed to not be maintainable. > > Yes, yes, we have whitelists for other things. I hate them in other > places too. But things like "this device has very odd audio > configuration" is very different from "this machine appears dead on > boot", for example. > > So reverting quickly is definitely the right thing to do. Or applying > the patch that apparently fixes it for Olof, and hopefully fixes it in > general - without any kind of random "on _this_ machine we do _that_" > crap. > > If drm people don't want the revert, send me a pull request with the fix. Imo revert. With all the QA awol fail we've suffered the past few months we've become a bit too lax imo with reverting fast, and the point of the split-out commit was to allow exactly that. On top I don't really like the casting Maarten's current hack does, we probably need a per-encoder ->sanitize hook for this stuff. Better to retry for 4.5. Can you pls push the revert? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/