Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 (f8965467) · Commits · e / devices / android_kernel_xiaomi_markw

Documentation/ABI/obsolete/sysfs-class-rfkill

0 → 100644

+29 −0

Original line number	Diff line number	Diff line
		rfkill - radio frequency (RF) connector kill switch support

		For details to this subsystem look at Documentation/rfkill.txt.

		What: /sys/class/rfkill/rfkill[0-9]+/state
		Date: 09-Jul-2007
		KernelVersion v2.6.22
		Contact: linux-wireless@vger.kernel.org
		Description: Current state of the transmitter.
		This file is deprecated and sheduled to be removed in 2014,
		because its not possible to express the 'soft and hard block'
		state of the rfkill driver.
		Values: A numeric value.
		0: RFKILL_STATE_SOFT_BLOCKED
		transmitter is turned off by software
		1: RFKILL_STATE_UNBLOCKED
		transmitter is (potentially) active
		2: RFKILL_STATE_HARD_BLOCKED
		transmitter is forced off by something outside of
		the driver's control.

		What: /sys/class/rfkill/rfkill[0-9]+/claim
		Date: 09-Jul-2007
		KernelVersion v2.6.22
		Contact: linux-wireless@vger.kernel.org
		Description: This file is deprecated because there no longer is a way to
		claim just control over a single rfkill instance.
		This file is scheduled to be removed in 2012.
		Values: 0: Kernel handles events

Documentation/ABI/stable/sysfs-class-rfkill

0 → 100644

+67 −0

Original line number	Diff line number	Diff line
		rfkill - radio frequency (RF) connector kill switch support

		For details to this subsystem look at Documentation/rfkill.txt.

		For the deprecated /sys/class/rfkill/*/state and
		/sys/class/rfkill/*/claim knobs of this interface look in
		Documentation/ABI/obsolete/sysfs-class-rfkill.

		What: /sys/class/rfkill
		Date: 09-Jul-2007
		KernelVersion: v2.6.22
		Contact: linux-wireless@vger.kernel.org,
		Description: The rfkill class subsystem folder.
		Each registered rfkill driver is represented by an rfkillX
		subfolder (X being an integer > 0).


		What: /sys/class/rfkill/rfkill[0-9]+/name
		Date: 09-Jul-2007
		KernelVersion v2.6.22
		Contact: linux-wireless@vger.kernel.org
		Description: Name assigned by driver to this key (interface or driver name).
		Values: arbitrary string.


		What: /sys/class/rfkill/rfkill[0-9]+/type
		Date: 09-Jul-2007
		KernelVersion v2.6.22
		Contact: linux-wireless@vger.kernel.org
		Description: Driver type string ("wlan", "bluetooth", etc).
		Values: See include/linux/rfkill.h.


		What: /sys/class/rfkill/rfkill[0-9]+/persistent
		Date: 09-Jul-2007
		KernelVersion v2.6.22
		Contact: linux-wireless@vger.kernel.org
		Description: Whether the soft blocked state is initialised from non-volatile
		storage at startup.
		Values: A numeric value.
		0: false
		1: true


		What: /sys/class/rfkill/rfkill[0-9]+/hard
		Date: 12-March-2010
		KernelVersion v2.6.34
		Contact: linux-wireless@vger.kernel.org
		Description: Current hardblock state. This file is read only.
		Values: A numeric value.
		0: inactive
		The transmitter is (potentially) active.
		1: active
		The transmitter is forced off by something outside of
		the driver's control.


		What: /sys/class/rfkill/rfkill[0-9]+/soft
		Date: 12-March-2010
		KernelVersion v2.6.34
		Contact: linux-wireless@vger.kernel.org
		Description: Current softblock state. This file is read and write.
		Values: A numeric value.
		0: inactive
		The transmitter is (potentially) active.
		1: active
		The transmitter is turned off by software.

Documentation/Changes

+1 −1

Original line number	Diff line number	Diff line
		@@ -49,7 +49,7 @@ o oprofile 0.9 # oprofiled --version
		o udev 081 # udevinfo -V
		o grub 0.93 # grub --version
		o mcelog 0.6
		o iptables 1.4.1 # iptables -V
		o iptables 1.4.2 # iptables -V


		Kernel compilation

Documentation/feature-removal-schedule.txt

+47 −10

Original line number	Diff line number	Diff line
		@@ -241,16 +241,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>

		---------------------------

		What (Why):
		- xt_recent: the old ipt_recent proc dir
		(superseded by /proc/net/xt_recent)

		When: January 2009 or Linux 2.7.0, whichever comes first
		Why: Superseded by newer revisions or modules
		Who: Jan Engelhardt <jengelh@computergmbh.de>

		---------------------------

		What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib
		When: February 2010
		Why: All callers should use explicit gpio_request()/gpio_free().
		@@ -520,6 +510,24 @@ Who: Hans de Goede <hdegoede@redhat.com>

		----------------------------

		What: sysfs-class-rfkill state file
		When: Feb 2014
		Files: net/rfkill/core.c
		Why: Documented as obsolete since Feb 2010. This file is limited to 3
		states while the rfkill drivers can have 4 states.
		Who: anybody or Florian Mickler <florian@mickler.org>

		----------------------------

		What: sysfs-class-rfkill claim file
		When: Feb 2012
		Files: net/rfkill/core.c
		Why: It is not possible to claim an rfkill driver since 2007. This is
		Documented as obsolete since Feb 2010.
		Who: anybody or Florian Mickler <florian@mickler.org>

		----------------------------

		What: capifs
		When: February 2011
		Files: drivers/isdn/capi/capifs.*
		@@ -579,6 +587,35 @@ Who: Len Brown <len.brown@intel.com>

		----------------------------

		What: iwlwifi 50XX module parameters
		When: 2.6.40
		Why: The "..50" modules parameters were used to configure 5000 series and
		up devices; different set of module parameters also available for 4965
		with same functionalities. Consolidate both set into single place
		in drivers/net/wireless/iwlwifi/iwl-agn.c

		Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>

		----------------------------

		What: iwl4965 alias support
		When: 2.6.40
		Why: Internal alias support has been present in module-init-tools for some
		time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed
		with no impact.

		Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>

		---------------------------

		What: xt_NOTRACK
		Files: net/netfilter/xt_NOTRACK.c
		When: April 2011
		Why: Superseded by xt_CT
		Who: Netfilter developer team <netfilter-devel@vger.kernel.org>

		---------------------------

		What: video4linux /dev/vtx teletext API support
		When: 2.6.35
		Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c

Documentation/networking/caif/Linux-CAIF.txt

0 → 100644

+212 −0

Original line number	Diff line number	Diff line
		Linux CAIF
		===========
		copyright (C) ST-Ericsson AB 2010
		Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
		License terms: GNU General Public License (GPL) version 2


		Introduction
		------------
		CAIF is a MUX protocol used by ST-Ericsson cellular modems for
		communication between Modem and host. The host processes can open virtual AT
		channels, initiate GPRS Data connections, Video channels and Utility Channels.
		The Utility Channels are general purpose pipes between modem and host.

		ST-Ericsson modems support a number of transports between modem
		and host. Currently, UART and Loopback are available for Linux.


		Architecture:
		------------
		The implementation of CAIF is divided into:
		* CAIF Socket Layer, Kernel API, and Net Device.
		* CAIF Core Protocol Implementation
		* CAIF Link Layer, implemented as NET devices.


		RTNL
		!
		! +------+ +------+ +------+
		! +------+! +------+! +------+!
		! ! Sock !! !Kernel!! ! Net !!
		! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs
		! +------+ +------! +------+
		! ! ! !
		! +----------!----------+
		! +------+ <- CAIF Protocol Implementation
		+-------> ! CAIF !
		! Core !
		+------+
		+--------!--------+
		! !
		+------+ +-----+
		! ! ! TTY ! <- Link Layer (Net Devices)
		+------+ +-----+


		Using the Kernel API
		----------------------
		The Kernel API is used for accessing CAIF channels from the
		kernel.
		The user of the API has to implement two callbacks for receive
		and control.
		The receive callback gives a CAIF packet as a SKB. The control
		callback will
		notify of channel initialization complete, and flow-on/flow-
		off.


		struct caif_device caif_dev = {
		.caif_config = {
		.name = "MYDEV"
		.type = CAIF_CHTY_AT
		}
		.receive_cb = my_receive,
		.control_cb = my_control,
		};
		caif_add_device(&caif_dev);
		caif_transmit(&caif_dev, skb);

		See the caif_kernel.h for details about the CAIF kernel API.


		I M P L E M E N T A T I O N
		===========================
		===========================

		CAIF Core Protocol Layer
		=========================================

		CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson.
		It implements the CAIF protocol stack in a layered approach, where
		each layer described in the specification is implemented as a separate layer.
		The architecture is inspired by the design patterns "Protocol Layer" and
		"Protocol Packet".

		== CAIF structure ==
		The Core CAIF implementation contains:
		- Simple implementation of CAIF.
		- Layered architecture (a la Streams), each layer in the CAIF
		specification is implemented in a separate c-file.
		- Clients must implement PHY layer to access physical HW
		with receive and transmit functions.
		- Clients must call configuration function to add PHY layer.
		- Clients must implement CAIF layer to consume/produce
		CAIF payload with receive and transmit functions.
		- Clients must call configuration function to add and connect the
		Client layer.
		- When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
		to the called function (except for framing layers' receive functions
		or if a transmit function returns an error, in which case the caller
		must free the packet).

		Layered Architecture
		--------------------
		The CAIF protocol can be divided into two parts: Support functions and Protocol
		Implementation. The support functions include:

		- CFPKT CAIF Packet. Implementation of CAIF Protocol Packet. The
		CAIF Packet has functions for creating, destroying and adding content
		and for adding/extracting header and trailers to protocol packets.

		- CFLST CAIF list implementation.

		- CFGLUE CAIF Glue. Contains OS Specifics, such as memory
		allocation, endianness, etc.

		The CAIF Protocol implementation contains:

		- CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
		Stack and provides a Client interface for adding Link-Layer and
		Driver interfaces on top of the CAIF Stack.

		- CFCTRL CAIF Control layer. Encodes and Decodes control messages
		such as enumeration and channel setup. Also matches request and
		response messages.

		- CFSERVL General CAIF Service Layer functionality; handles flow
		control and remote shutdown requests.

		- CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
		External Interface). This layer encodes/decodes VEI frames.

		- CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
		traffic), encodes/decodes Datagram frames.

		- CFMUX CAIF Mux layer. Handles multiplexing between multiple
		physical bearers and multiple channels such as VEI, Datagram, etc.
		The MUX keeps track of the existing CAIF Channels and
		Physical Instances and selects the apropriate instance based
		on Channel-Id and Physical-ID.

		- CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
		and frame checksum.

		- CFSERL CAIF Serial layer. Handles concatenation/split of frames
		into CAIF Frames with correct length.



		+---------+
		\| Config \|
		\| CFCNFG \|
		+---------+
		!
		+---------+ +---------+ +---------+
		\| AT \| \| Control \| \| Datagram\|
		\| CFVEIL \| \| CFCTRL \| \| CFDGML \|
		+---------+ +---------+ +---------+
		\_____________!______________/
		!
		+---------+
		\| MUX \|
		\| \|
		+---------+
		_____!_____
		/ \
		+---------+ +---------+
		\| CFFRML \| \| CFFRML \|
		\| Framing \| \| Framing \|
		+---------+ +---------+
		! !
		+---------+ +---------+
		\| \| \| Serial \|
		\| \| \| CFSERL \|
		+---------+ +---------+


		In this layered approach the following "rules" apply.
		- All layers embed the same structure "struct cflayer"
		- A layer does not depend on any other layer's private data.
		- Layers are stacked by setting the pointers
		layer->up , layer->dn
		- In order to send data upwards, each layer should do
		layer->up->receive(layer->up, packet);
		- In order to send data downwards, each layer should do
		layer->dn->transmit(layer->dn, packet);


		Linux Driver Implementation
		===========================

		Linux GPRS Net Device and CAIF socket are implemented on top of the
		CAIF Core protocol. The Net device and CAIF socket have an instance of
		'struct cflayer', just like the CAIF Core protocol stack.
		Net device and Socket implement the 'receive()' function defined by
		'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
		receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
		function is called in order to transmit data.

		The layer on top of the CAIF Core implementation is
		sometimes referred to as the "Client layer".


		Configuration of Link Layer
		---------------------------
		The Link Layer is implemented as Linux net devices (struct net_device).
		Payload handling and registration is done using standard Linux mechanisms.

		The CAIF Protocol relies on a loss-less link layer without implementing
		retransmission. This implies that packet drops must not happen.
		Therefore a flow-control mechanism is implemented where the physical
		interface can initiate flow stop for all CAIF Channels.