Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754679AbdFXAdJ convert rfc822-to-8bit (ORCPT ); Fri, 23 Jun 2017 20:33:09 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:62903 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754075AbdFXAdI (ORCPT ); Fri, 23 Jun 2017 20:33:08 -0400 From: "Rafael J. Wysocki" To: Darren Hart Cc: =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= , Jonathan Woithe , Andy Shevchenko , platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes Date: Sat, 24 Jun 2017 02:25:46 +0200 Message-ID: <40512901.HXkrFCdsVg@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.12.0-rc1+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170621181543.GB25900@fury> References: <20170616044058.30443-1-kernel@kempniu.pl> <20170616044058.30443-2-kernel@kempniu.pl> <20170621181543.GB25900@fury> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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: 1076 Lines: 23 On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote: > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote: > > All ACPI device notify callbacks are invoked using acpi_os_execute(), > > which causes the supplied callback to be queued to a static workqueue > > which always executes on CPU 0. This means that there is no possibility > > for any ACPI device notify callback to be concurrently executed on > > multiple CPUs, which in the case of fujitsu-laptop means that using a > > locked kfifo for handling hotkeys is redundant: as hotkey scancodes are > > only pushed and popped from within acpi_fujitsu_laptop_notify(), no risk > > of concurrent pushing and popping exists. > > Was the kfifo causing a problem currently or for the migration to separate > modules? Is this purely a simplification? > > Rafael, the above rationale appears sound to me. Do you have any concerns? I actually do. While this is the case today, making the driver code depend on it in a hard way sort of makes it difficult to change in the future if need be. Thanks, Rafael