Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5d4e2d08 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core 



Pull driver core updates from Greg Kroah-Hartman:
 "Here's the driver core, and other driver subsystems, pull request for
  the 3.5-rc1 merge window.

  Outside of a few minor driver core changes, we ended up with the
  following different subsystem and core changes as well, due to
  interdependancies on the driver core:
   - hyperv driver updates
   - drivers/memory being created and some drivers moved into it
   - extcon driver subsystem created out of the old Android staging
     switch driver code
   - dynamic debug updates
   - printk rework, and /dev/kmsg changes

  All of this has been tested in the linux-next releases for a few weeks
  with no reported problems.

  Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org&gt;">

Fix up conflicts in drivers/extcon/extcon-max8997.c where git noticed
that a patch to the deleted drivers/misc/max8997-muic.c driver needs to
be applied to this one.

* tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (90 commits)
  uio_pdrv_genirq: get irq through platform resource if not set otherwise
  memory: tegra{20,30}-mc: Remove empty *_remove()
  printk() - isolate KERN_CONT users from ordinary complete lines
  sysfs: get rid of some lockdep false positives
  Drivers: hv: util: Properly handle version negotiations.
  Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp()
  memory: tegra{20,30}-mc: Use dev_err_ratelimited()
  driver core: Add dev_*_ratelimited() family
  Driver Core: don't oops with unregistered driver in driver_find_device()
  printk() - restore prefix/timestamp printing for multi-newline strings
  printk: add stub for prepend_timestamp()
  ARM: tegra30: Make MC optional in Kconfig
  ARM: tegra20: Make MC optional in Kconfig
  ARM: tegra30: MC: Remove unnecessary BUG*()
  ARM: tegra20: MC: Remove unnecessary BUG*()
  printk: correctly align __log_buf
  ARM: tegra30: Add Tegra Memory Controller(MC) driver
  ARM: tegra20: Add Tegra Memory Controller(MC) driver
  printk() - restore timestamp printing at console output
  printk() - do not merge continuation lines of different threads
  ...
parents fb2123fa 94ca629e

Documentation/ABI/testing/dev-kmsg

0 → 100644
+90 −0
Original line number Diff line number Diff line 
What:		/dev/kmsg

Date:		Mai 2012

KernelVersion:	3.5

Contact:	Kay Sievers <kay@vrfy.org>

Description:	The /dev/kmsg character device node provides userspace access

		to the kernel's printk buffer.



		Injecting messages:

		Every write() to the opened device node places a log entry in

		the kernel's printk buffer.



		The logged line can be prefixed with a <N> syslog prefix, which

		carries the syslog priority and facility. The single decimal

		prefix number is composed of the 3 lowest bits being the syslog

		priority and the higher bits the syslog facility number.



		If no prefix is given, the priority number is the default kernel

		log priority and the facility number is set to LOG_USER (1). It

		is not possible to inject messages from userspace with the

		facility number LOG_KERN (0), to make sure that the origin of

		the messages can always be reliably determined.



		Accessing the buffer:

		Every read() from the opened device node receives one record

		of the kernel's printk buffer.



		The first read() directly following an open() always returns

		first message in the buffer; there is no kernel-internal

		persistent state; many readers can concurrently open the device

		and read from it, without affecting other readers.



		Every read() will receive the next available record. If no more

		records are available read() will block, or if O_NONBLOCK is

		used -EAGAIN returned.



		Messages in the record ring buffer get overwritten as whole,

		there are never partial messages received by read().



		In case messages get overwritten in the circular buffer while

		the device is kept open, the next read() will return -EPIPE,

		and the seek position be updated to the next available record.

		Subsequent reads() will return available records again.



		Unlike the classic syslog() interface, the 64 bit record

		sequence numbers allow to calculate the amount of lost

		messages, in case the buffer gets overwritten. And they allow

		to reconnect to the buffer and reconstruct the read position

		if needed, without limiting the interface to a single reader.



		The device supports seek with the following parameters:

		SEEK_SET, 0

		  seek to the first entry in the buffer

		SEEK_END, 0

		  seek after the last entry in the buffer

		SEEK_DATA, 0

		  seek after the last record available at the time

		  the last SYSLOG_ACTION_CLEAR was issued.



		The output format consists of a prefix carrying the syslog

		prefix including priority and facility, the 64 bit message

		sequence number and the monotonic timestamp in microseconds.

		The values are separated by a ','. Future extensions might

		add more comma separated values before the terminating ';'.

		Unknown values should be gracefully ignored.



		The human readable text string starts directly after the ';'

		and is terminated by a '\n'. Untrusted values derived from

		hardware or other facilities are printed, therefore

		all non-printable characters in the log message are escaped

		by "\x00" C-style hex encoding.



		A line starting with ' ', is a continuation line, adding

		key/value pairs to the log message, which provide the machine

		readable context of the message, for reliable processing in

		userspace.



		Example:

		7,160,424069;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)

		 SUBSYSTEM=acpi

		 DEVICE=+acpi:PNP0A03:00

		6,339,5140900;NET: Registered protocol family 10

		30,340,5690716;udevd[80]: starting version 181



		The DEVICE= key uniquely identifies devices the following way:

		  b12:8        - block dev_t

		  c127:3       - char dev_t

		  n8           - netdev ifindex

		  +sound:card0 - subsystem:devname



Users:		dmesg(1), userspace kernel log consumers

Documentation/ABI/testing/sysfs-class-extcon

0 → 100644
+97 −0
Original line number Diff line number Diff line 
What:		/sys/class/extcon/.../

Date:		February 2012

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		Provide a place in sysfs for the extcon objects.

		This allows accessing extcon specific variables.

		The name of extcon object denoted as ... is the name given

		with extcon_dev_register.



		One extcon device denotes a single external connector

		port. An external connector may have multiple cables

		attached simultaneously. Many of docks, cradles, and

		accessory cables have such capability. For example,

		the 30-pin port of Nuri board (/arch/arm/mach-exynos)

		may have both HDMI and Charger attached, or analog audio,

		video, and USB cables attached simulteneously.



		If there are cables mutually exclusive with each other,

		such binary relations may be expressed with extcon_dev's

		mutually_exclusive array.



What:		/sys/class/extcon/.../name

Date:		February 2012

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		The /sys/class/extcon/.../name shows the name of the extcon

		object. If the extcon object has an optional callback

		"show_name" defined, the callback will provide the name with

		this sysfs node.



What:		/sys/class/extcon/.../state

Date:		February 2012

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		The /sys/class/extcon/.../state shows and stores the cable

		attach/detach information of the corresponding extcon object.

		If the extcon object has an optional callback "show_state"

		defined, the showing function is overriden with the optional

		callback.



		If the default callback for showing function is used, the

		format is like this:

		# cat state

		USB_OTG=1

		HDMI=0

		TA=1

		EAR_JACK=0

		#

		In this example, the extcon device have USB_OTG and TA

		cables attached and HDMI and EAR_JACK cables detached.



		In order to update the state of an extcon device, enter a hex

		state number starting with 0x.

		 echo 0xHEX > state



		This updates the whole state of the extcon dev.

		Inputs of all the methods are required to meet the

		mutually_exclusive contidions if they exist.



		It is recommended to use this "global" state interface if

		you need to enter the value atomically. The later state

		interface associated with each cable cannot update

		multiple cable states of an extcon device simultaneously.



What:		/sys/class/extcon/.../cable.x/name

Date:		February 2012

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		The /sys/class/extcon/.../cable.x/name shows the name of cable

		"x" (integer between 0 and 31) of an extcon device.



What:		/sys/class/extcon/.../cable.x/state

Date:		February 2012

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		The /sys/class/extcon/.../cable.x/name shows and stores the

		state of cable "x" (integer between 0 and 31) of an extcon

		device. The state value is either 0 (detached) or 1

		(attached).



What:		/sys/class/extcon/.../mutually_exclusive/...

Date:		December 2011

Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>

Description:

		Shows the relations of mutually exclusiveness. For example,

		if the mutually_exclusive array of extcon_dev is

		{0x3, 0x5, 0xC, 0x0}, the, the output is:

		# ls mutually_exclusive/

		0x3

		0x5

		0xc

		#



		Note that mutually_exclusive is a sub-directory of the extcon

		device and the file names under the mutually_exclusive

		directory show the mutually-exclusive sets, not the contents

		of the files.

Documentation/HOWTO

+16 −16
Original line number Diff line number Diff line
@@ -218,16 +218,16 @@ The development process 
Linux kernel development process currently consists of a few different

main kernel "branches" and lots of different subsystem-specific kernel

branches.  These different branches are:

  - main 2.6.x kernel tree

  - 2.6.x.y -stable kernel tree

  - 2.6.x -git kernel patches

  - main 3.x kernel tree

  - 3.x.y -stable kernel tree

  - 3.x -git kernel patches

  - subsystem specific kernel trees and patches

  - the 2.6.x -next kernel tree for integration tests

  - the 3.x -next kernel tree for integration tests



2.6.x kernel tree

3.x kernel tree

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

2.6.x kernels are maintained by Linus Torvalds, and can be found on

kernel.org in the pub/linux/kernel/v2.6/ directory.  Its development

3.x kernels are maintained by Linus Torvalds, and can be found on

kernel.org in the pub/linux/kernel/v3.x/ directory.  Its development

process is as follows:

  - As soon as a new kernel is released a two weeks window is open,

    during this period of time maintainers can submit big diffs to
@@ -262,20 +262,20 @@ mailing list about kernel releases: 
	released according to perceived bug status, not according to a

	preconceived timeline."



2.6.x.y -stable kernel tree

3.x.y -stable kernel tree

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

Kernels with 4-part versions are -stable kernels. They contain

Kernels with 3-part versions are -stable kernels. They contain

relatively small and critical fixes for security problems or significant

regressions discovered in a given 2.6.x kernel.

regressions discovered in a given 3.x kernel.



This is the recommended branch for users who want the most recent stable

kernel and are not interested in helping test development/experimental

versions.



If no 2.6.x.y kernel is available, then the highest numbered 2.6.x

If no 3.x.y kernel is available, then the highest numbered 3.x

kernel is the current stable kernel.



2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and

3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and

are released as needs dictate.  The normal release period is approximately

two weeks, but it can be longer if there are no pressing problems.  A

security-related problem, instead, can cause a release to happen almost
@@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree 
documents what kinds of changes are acceptable for the -stable tree, and

how the release process works.



2.6.x -git patches

3.x -git patches

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

These are daily snapshots of Linus' kernel tree which are managed in a

git repository (hence the name.) These patches are usually released
@@ -317,13 +317,13 @@ revisions to it, and maintainers can mark patches as under review, 
accepted, or rejected.  Most of these patchwork sites are listed at

http://patchwork.kernel.org/.



2.6.x -next kernel tree for integration tests

3.x -next kernel tree for integration tests

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

Before updates from subsystem trees are merged into the mainline 2.6.x

Before updates from subsystem trees are merged into the mainline 3.x

tree, they need to be integration-tested.  For this purpose, a special

testing repository exists into which virtually all subsystem trees are

pulled on an almost daily basis:

	http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git

	http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

	http://linux.f-seidel.de/linux-next/pmwiki/



This way, the -next kernel gives a summary outlook onto what will be

Documentation/devices.txt

+2 −1
Original line number Diff line number Diff line
@@ -98,7 +98,8 @@ Your cooperation is appreciated. 
		  8 = /dev/random	Nondeterministic random number gen.

		  9 = /dev/urandom	Faster, less secure random number gen.

		 10 = /dev/aio		Asynchronous I/O notification interface

		 11 = /dev/kmsg		Writes to this come out as printk's

		 11 = /dev/kmsg		Writes to this come out as printk's, reads

					export the buffered printk records.

		 12 = /dev/oldmem	Used by crashdump kernels to access

					the memory of the kernel that crashed.

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt

0 → 100644
+16 −0
Original line number Diff line number Diff line 
NVIDIA Tegra20 MC(Memory Controller)



Required properties:

- compatible : "nvidia,tegra20-mc"

- reg : Should contain 2 register ranges(address and length); see the

  example below. Note that the MC registers are interleaved with the

  GART registers, and hence must be represented as multiple ranges.

- interrupts : Should contain MC General interrupt.



Example:

	mc {

		compatible = "nvidia,tegra20-mc";

		reg = <0x7000f000 0x024

		       0x7000f03c 0x3c4>;

		interrupts = <0 77 0x04>;

	};