linux-kernel - Re: Regression on Chromebook Pixel 2015 due to i915 fastboot always-on

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-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6T+fGK9J3X7cQ@mail.gmail.com>
Date:	Tue, 17 Nov 2015 21:35:03 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Olof Johansson <olof@...om.net>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Dave Airlie <airlied@...hat.com>,
	Duncan Laurie <dlaurie@...omium.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Regression on Chromebook Pixel 2015 due to i915 fastboot always-on

On Tue, Nov 17, 2015 at 7:18 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Nov 17, 2015 at 9:53 AM, Olof Johansson <olof@...om.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/