Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422695AbbD2Jzm (ORCPT ); Wed, 29 Apr 2015 05:55:42 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:36158 "EHLO mail-wg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031647AbbD2Jzj (ORCPT ); Wed, 29 Apr 2015 05:55:39 -0400 Date: Wed, 29 Apr 2015 11:55:36 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Darren Hart Cc: Matthew Garrett , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Gabriele Mazzotta , Alex Hung Subject: Re: [PATCH 2/3] platform: x86: dell-rbtn: Export notifier for other kernel modules Message-ID: <20150429095536.GE24346@pali> References: <1416755361-17357-1-git-send-email-pali.rohar@gmail.com> <1416755361-17357-3-git-send-email-pali.rohar@gmail.com> <20141125223936.GD116670@vmdeb7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141125223936.GD116670@vmdeb7> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1489 Lines: 36 On Tuesday 25 November 2014 14:39:37 Darren Hart wrote: > On Sun, Nov 23, 2014 at 04:09:20PM +0100, Pali Rohár wrote: > > This patch exports notifier functions so other modules can receive HW switch > > events. By default when some module register notifier, dell-rbtn driver > > The commit message needs to describe the problem being addressed as well. Why is > this necessary? > Needed for next patch (3/3). All 3 patches are one series, so I do no think that everything is needed to describe... > > automatically remove rfkill interfaces from system (it is expected that other > > module will use events for other rfkill interface). This behaviour can be > > changed with new module parameter "auto_remove_rfkill". > > We try to avoid using such parameters to define behavior when possible. > > Why is it justified to use auto_remove_rfkill here? When is it needed? As > opposed to doing something that works based on the detected hardware? (It could > be this is the right thing, but we have to justify it). > Just for future if something goes wrong and new Dell BIOS stopped working. So users would be able to "hotfix" unexpected problems. As Alex wrote, some machine has already BIOS bug... -- Pali Rohár pali.rohar@gmail.com -- 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/