From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932334AbcELIwa (ORCPT ); Thu, 12 May 2016 04:52:30 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36840 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752891AbcELIvp (ORCPT ); Thu, 12 May 2016 04:51:45 -0400 Date: Thu, 12 May 2016 10:51:42 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Juergen Gross Cc: Guenter Roeck , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, david.vrabel@citrix.com, mingo@redhat.com, peterz@infradead.org, Douglas_Warzecha@dell.com, jdelvare@suse.com, tglx@linutronix.de, hpa@zytor.com, jeremy@goop.org, chrisw@sous-sol.org, akataria@vmware.com, rusty@rustcorp.com.au, virtualization@lists.linux-foundation.org, x86@kernel.org Subject: Re: [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k Message-ID: <20160512085142.GX29844@pali> References: <1459833007-11618-1-git-send-email-jgross@suse.com> <1459833007-11618-7-git-send-email-jgross@suse.com> <20160405145414.GB27359@roeck-us.net> <201604052131.52765@pali> <20160421105724.GK29406@pali> <5718D1D4.3040309@suse.com> <20160421132735.GR29406@pali> <5730A08D.60100@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5730A08D.60100@suse.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 09 May 2016 16:37:01 Juergen Gross wrote: > On 21/04/16 15:27, Pali Rohár wrote: > > On Thursday 21 April 2016 15:12:52 Juergen Gross wrote: > >> On 21/04/16 12:57, Pali Rohár wrote: > >>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote: > >>>> On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote: > >>>>> On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote: > >>>>>> Use the smp_call_on_cpu() function to call system management > >>>>>> mode on cpu 0. > >>>>>> Make call secure by adding get_online_cpus() to avoid e.g. suspend > >>>>>> resume cycles in between. > >>>>>> > >>>>>> Signed-off-by: Juergen Gross > >>>>>> --- > >>>>>> V4: add call to get_online_cpus() > >>>>> > >>>>> Pali, any chance to test this ? > >>>> > >>>> I can test it, but just on machine where (probably) smm calls can be > >>>> send from any cpu... Need some time for testing and I believe I can do > >>>> that at the end of the week. > >>> > >>> Sorry I had absolutely no more free time last weekend :-( And same > >>> prediction is for this weekend and also next one... > >> > >> Pali, I've got a Dell laptop (Latitude E6440) here. Would this device be > >> okay for a test? > > > > Hi! > > > > Proper regression test should check if this patch does not break any > > function or drivers dependent on dcdbas.ko. And should be done on both > > notebook devices: which needs to issue that smm call on cpu 0 and also > > on which it is not needed. > > Hmm, couldn't get one which needs smm to be called on cpu 0. > OTOH I've done various tests and added a printk() in raise_smm() > and i8k_smm_func() issuing the cpu number it was called on. Understood, those machines are old and probably rare now. > > Some notebooks which needs smm call to issued from cpu 0 can be found in > > git commit messages of i8k, dell-laptop or dcdbas kernel drivers. > > > >> What would you do for testing? In case you can give me > >> some hints how to do a sensible test I'd do it. > > > > Test e.g. dell-laptop.ko driver. It provides /sys interface for changing > > keyboard backlight or changing rfkill switches (bluetooth wifi). > > Done. > > > Also test tools from libsmbios (userspace) package. > > Done. > > > There must be no difference in output/functionality with or without your > > patches. > > Verified. > > >> I've verified by adding a printk() to smp_call_on_cpu() that at least > >> one of the modified drivers has been used during system boot. > > > > Also you can patch i8k/dcdbas smm function to print cpu number on which > > is code running (to verify that it was really called on cpu 0 as > > needed). > > Done. > > I tested suspend/resume, too, as adding get_online_cpus() might have > changed behavior. Worked like a charm. :-) Ok, I think this should be enough. You can add my Acked-by. -- Pali Rohár pali.rohar@gmail.com