Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932405AbdCFSrv (ORCPT ); Mon, 6 Mar 2017 13:47:51 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:34699 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932362AbdCFSr2 (ORCPT ); Mon, 6 Mar 2017 13:47:28 -0500 Date: Mon, 6 Mar 2017 19:47:23 +0100 From: =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= To: Jonathan Woithe Cc: Darren Hart , Andy Shevchenko , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/4] fujitsu_init() cleanup Message-ID: <20170306184723.GA795@kmp-mobile.hq.kempniu.pl> References: <20170301081044.12141-1-kernel@kempniu.pl> <20170304014723.GA7944@marvin.atrad.com.au> <20170305234854.GG28473@marvin.atrad.com.au> <20170306044905.GA3845@kmp-mobile.hq.kempniu.pl> <20170306050104.GT28473@marvin.atrad.com.au> <20170306081030.GA30975@marvin.atrad.com.au> <20170306093350.GB1372@ozzy.nask.waw.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170306093350.GB1372@ozzy.nask.waw.pl> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2755 Lines: 61 > > Hi Michael > > > > Some quick feedback. > > > > On Mon, Mar 06, 2017 at 03:31:04PM +1030, Jonathan Woithe wrote: > > > > > I can add that immediately after loading the driver the value returned by a > > > > > read of bl_power is 0. As noted above, setting to 1 makes no difference to > > > > > the backlight, neither does returning it to 0. > > > > > > > > Have you tried setting bl_power to 4? Because that is the value of > > > > FB_BLANK_POWERDOWN, which is the value the patch is supposed to handle. > > > > > > Oh no, I didn't try 4. I should have. I will try to squeeze in a test of > > > this tonight (time is short but the test won't take a lot of time). > > > > With an unpatched 4.5 kernel, writing 4 (as opposed to 1, which I stupidly > > tried earlier) to bl_power caused the backlight to turn off. Writing 0 > > turned it back on again. > > > > With patches 1-4/4 applied, writing 4 to bl_power did *NOT* turn the > > backlight off. > > > > With patch 2 reverted, writing 4 to bl_power turned the backlight off. > > Writing 0 to bl_power turned it back on again. > > > > This means that patch 2/4 seems to prevent bl_power from operating as > > expected on the S7020 hardware. Without this patch (but with all the others > > in place) bl_power works. > > > > I am unlikely to have any more time to investigate this further tonight. > > > > In light of the above findings, what would you like to do? > > Thanks for testing, good that we caught this before the patch series was > applied. I think it is reasonable to skip applying this version of the > series as at least patch 2/4 is faulty and breaks a working feature. > > Moving on, though, as I do not have access to Fujitsu hardware on which > this feature works, I was hoping you could help me verify whether my > assumptions were reasonable in the first place. > > I attached a crude patch to this message. I would like to understand > how the underlying ACPI variables behave when the FEXT interface is > used, so please apply this patch on top of dvhart/testing (i.e. without > this series applied). After compiling, please load the module with > debugging enabled, then test backlight control once again by writing 4 > and then 0 to bl_power (this should work). Then please send me all the > messages spit out by the driver into dmesg. This should shed some light > on the matter. Actually, scratch that. I just ordered a banged up S7020 for €15 to avoid pestering you with experimental patches and hopefully make the whole driver cleanup process a bit smoother. Darren, Andy, please ignore this whole series for now. I will post v3 once I figure out how to clean things up without breaking working features. -- Best regards, Michał Kępień