From patchwork Wed Apr 8 13:37:18 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Jenkins X-Patchwork-Id: 25728 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 4CC57DDFB6 for ; Wed, 8 Apr 2009 23:38:10 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765592AbZDHNh0 (ORCPT ); Wed, 8 Apr 2009 09:37:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1765464AbZDHNhZ (ORCPT ); Wed, 8 Apr 2009 09:37:25 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:39008 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765449AbZDHNhX (ORCPT ); Wed, 8 Apr 2009 09:37:23 -0400 Received: by fg-out-1718.google.com with SMTP id e12so43441fga.17 for ; Wed, 08 Apr 2009 06:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=kYRLfvT6gtCueGHuXai7oQzlu2R/Lfyi3FtRrpadWGU=; b=JTkBqALrFh9qnvSbBFJqUZDQAV45uuxghgkYeLRwiXpH+cQjTifMAxe7npgmHgC7qQ e9bicNBC95KSy9EYmvh8DWd9sBolL8Xxt1S7bn1Ge3QqCow2FiAcWFRVI6IdhoHdKpWf iQMsIY3ZD6v1h2hJZZQYoz2AEDTpuKjWiiVnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=s91KIBlBw33RK3XrNkcg+frZJI1e1JRKxTWijLgtnqpj2Xo0tdql6/z3zdeFRCQRIf xE2+kw2XxcBr+ThMV6atorFGDuMmvbUzxALNisAXkseZFFmtzxD1iRRiIYeLXvUAwJVi wOq2FkS/yHlKHuG2SDXDudYfSr9jfnLXNtlAc= Received: by 10.86.36.17 with SMTP id j17mr1093544fgj.19.1239197841055; Wed, 08 Apr 2009 06:37:21 -0700 (PDT) Received: from ?192.168.0.5? ([86.53.68.233]) by mx.google.com with ESMTPS id e20sm2445286fga.9.2009.04.08.06.37.19 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 06:37:20 -0700 (PDT) Message-ID: <49DCA88E.6060400@tuffmail.co.uk> Date: Wed, 08 Apr 2009 14:37:18 +0100 From: Alan Jenkins User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "John W. Linville" CC: Johannes Berg , Ivo van Doorn , netdev@vger.kernel.org Subject: [PATCH] rfkill: document removal of notifier chain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This unused feature was removed in 4dec9b807be757780ca3611a959ac22c28d292a7 Signed-off-by: Alan Jenkins --- p.s. Is netdev really the right list for rfkill (as listed in MAINTAINERS)? I have a feeling most development happens on linux-wireless. Documentation/rfkill.txt | 23 ++++++++--------------- 1 files changed, 8 insertions(+), 15 deletions(-) diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index 4d3ee31..357ef01 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -47,10 +47,8 @@ know when they should enable or disable a wireless network device transmitter. This is enabled by the CONFIG_RFKILL Kconfig option. The rfkill class support makes sure userspace will be notified of all state -changes on rfkill devices through uevents. It provides a notification chain -for interested parties in the kernel to also get notified of rfkill state -changes in other drivers. It creates several sysfs entries which can be used -by userspace. See section "Userspace support". +changes on rfkill devices through uevents. It creates several sysfs entries +which can be used by userspace. See section "Userspace support". The rfkill-input module provides the kernel with the ability to implement a basic response when the user presses a key or button (or toggles a switch) @@ -156,9 +154,8 @@ rfkill class: transmitter state; * Keeps track of the wireless transmitter state (with help from the driver); - * Generates userspace notifications (uevents) and a call to a - notification chain (kernel) when there is a wireless transmitter - state change; + * Generates userspace notifications (uevents) when there is a wireless + transmitter state change; * Connects a wireless communications driver with the common rfkill control system, which, for example, allows actions such as "switch all bluetooth devices offline" to be carried out by @@ -206,18 +203,15 @@ Userspace input handlers (uevents) or kernel input handlers (rfkill-input): restore the transmitters to their state before the EPO, or unblock them all. -Userspace uevent handler or kernel platform-specific drivers hooked to the -rfkill notifier chain: +Userspace uevent handler or kernel platform-specific drivers: - * Taps into the rfkill notifier chain or to KOBJ_CHANGE uevents, - in order to know when a device that is registered with the rfkill - class changes state; + * Listens to KOBJ_CHANGE uevents or the platform in order to know when + a device that is registered with the rfkill class changes state; * Issues feedback notifications to the user; * In the rare platforms where this is required, synthesizes an input event to command all *OTHER* rfkill devices to also change their statues when a specific rfkill device changes state. - =============================================================================== 3: Kernel driver guidelines @@ -269,8 +263,7 @@ SW_RFKILL_ALL, etc) when ALL of the folowing conditions are met: When in doubt, do not issue input events. For drivers that should generate input events in some platforms, but not in others (e.g. b43), the best solution is to NEVER generate input events in the first place. That work should be -deferred to a platform-specific kernel module (which will know when to generate -events through the rfkill notifier chain) or to userspace. This avoids the +deferred to a platform-specific kernel module or to userspace. This avoids the usual maintenance problems with DMI whitelisting.