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

Commit eaa5699e authored by Arnd Bergmann's avatar Arnd Bergmann
Browse files

Merge branch 'depends/driver-core' into next/soc2 

* depends/driver-core: (55 commits)
  Documentation: add information for new sysfs soc bus functionality
  drivers/base: add bus for System-on-Chip devices
  DWC3: use module_pci_driver
  PCI: Add helper macro for pci_register_driver boilerplate
  w1: Use linux/gpio.h rather than asm/gpio.h
  drivers: hv: Increase the number of VCPUs supported in the guest
  drivers: hv: kvp: Cleanup the kernel/user protocol
  tools: hv: Use hyperv.h to get the KVP definitions
  drivers: hv: Cleanup the kvp related state in hyperv.h
  ACPI: remove duplicated lines of merging problems with acpi_processor_start
  cpufreq/gx: Fix the compile error
  drivers: hv: kvp: Move the contents of hv_kvp.h to hyperv.h
  drivers: hv: kvp: Add/cleanup connector defines
  sysfs: Update the name hash when renaming sysfs entries
  PCI/XEN: Fix bug introduced by a recent change
  USB/PCI/PCMCIA: Clean up new_id and remove_id sysfs attribute routines
  CPU: Introduce ARCH_HAS_CPU_AUTOPROBE and X86 parts
  x86: autoload microcode driver on Intel and AMD systems v2
  cpufreq: Add support for x86 cpuinfo auto loading v4
  X86: Introduce HW-Pstate scattered cpuid feature
  ...
parents d65b4e98 da5a70f3

Documentation/ABI/testing/sysfs-devices-soc

0 → 100644
+58 −0
Original line number Diff line number Diff line 
What:		/sys/devices/socX

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		The /sys/devices/ directory contains a sub-directory for each

		System-on-Chip (SoC) device on a running platform. Information

		regarding each SoC can be obtained by reading sysfs files. This

		functionality is only available if implemented by the platform.



		The directory created for each SoC will also house information

		about devices which are commonly contained in /sys/devices/platform.

		It has been agreed that if an SoC device exists, its supported

		devices would be better suited to appear as children of that SoC.



What:		/sys/devices/socX/machine

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		Read-only attribute common to all SoCs. Contains the SoC machine

		name (e.g. Ux500).



What:		/sys/devices/socX/family

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		Read-only attribute common to all SoCs. Contains SoC family name

		(e.g. DB8500).



What:		/sys/devices/socX/soc_id

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		Read-only attribute supported by most SoCs. In the case of

		ST-Ericsson's chips this contains the SoC serial number.



What:		/sys/devices/socX/revision

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		Read-only attribute supported by most SoCs. Contains the SoC's

		manufacturing revision number.



What:		/sys/devices/socX/process

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		Read-only attribute supported ST-Ericsson's silicon. Contains the

		the process by which the silicon chip was manufactured.



What:		/sys/bus/soc

Date:		January 2012

contact:	Lee Jones <lee.jones@linaro.org>

Description:

		The /sys/bus/soc/ directory contains the usual sub-folders

		expected under most buses. /sys/bus/soc/devices is of particular

		interest, as it contains a symlink for each SoC device found on

		the system. Each symlink points back into the aforementioned

		/sys/devices/socX devices.

Documentation/dynamic-debug-howto.txt

+12 −18
Original line number Diff line number Diff line
@@ -12,7 +12,7 @@ dynamically enabled per-callsite. 
Dynamic debug has even more useful features:



 * Simple query language allows turning on and off debugging statements by

   matching any combination of:

   matching any combination of 0 or 1 of:



   - source filename

   - function name
@@ -79,31 +79,24 @@ Command Language Reference 
==========================



At the lexical level, a command comprises a sequence of words separated

by whitespace characters.  Note that newlines are treated as word

separators and do *not* end a command or allow multiple commands to

be done together.  So these are all equivalent:

by spaces or tabs.  So these are all equivalent:



nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >

				<debugfs>/dynamic_debug/control

nullarbor:~ # echo -c '  file   svcsock.c     line  1603 +p  ' >

				<debugfs>/dynamic_debug/control

nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >

				<debugfs>/dynamic_debug/control

nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >

				<debugfs>/dynamic_debug/control



Commands are bounded by a write() system call.  If you want to do

multiple commands you need to do a separate "echo" for each, like:

Command submissions are bounded by a write() system call.

Multiple commands can be written together, separated by ';' or '\n'.



nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\

> echo 'file svcsock.c line 1563 +p' > /proc/dprintk

  ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \

     > <debugfs>/dynamic_debug/control



or even like:

If your query set is big, you can batch them too:



nullarbor:~ # (

> echo 'file svcsock.c line 1603 +p' ;\

> echo 'file svcsock.c line 1563 +p' ;\

> ) > /proc/dprintk

  ~# cat query-batch-file > <debugfs>/dynamic_debug/control



At the syntactical level, a command comprises a sequence of match

specifications, followed by a flags change specification.
@@ -144,11 +137,12 @@ func 
    func svc_tcp_accept



file

    The given string is compared against either the full

    pathname or the basename of the source file of each

    callsite.  Examples:

    The given string is compared against either the full pathname, the

    src-root relative pathname, or the basename of the source file of

    each callsite.  Examples:



    file svcsock.c

    file kernel/freezer.c

    file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c



module

Documentation/filesystems/debugfs.txt

+4 −1
Original line number Diff line number Diff line
@@ -15,6 +15,9 @@ Debugfs is typically mounted with a command like: 
    mount -t debugfs none /sys/kernel/debug



(Or an equivalent /etc/fstab line).

The debugfs root directory is accessible by anyone by default. To

restrict access to the tree the "uid", "gid" and "mode" mount

options can be used.



Note that the debugfs API is exported GPL-only to modules.

arch/x86/Kconfig

+3 −0
Original line number Diff line number Diff line
@@ -179,6 +179,9 @@ config ARCH_HAS_DEFAULT_IDLE 
config ARCH_HAS_CACHE_LINE_SIZE

	def_bool y



config ARCH_HAS_CPU_AUTOPROBE

	def_bool y



config HAVE_SETUP_PER_CPU_AREA

	def_bool y

arch/x86/crypto/aesni-intel_glue.c

+9 −3
Original line number Diff line number Diff line
@@ -28,6 +28,7 @@ 
#include <crypto/aes.h>

#include <crypto/cryptd.h>

#include <crypto/ctr.h>

#include <asm/cpu_device_id.h>

#include <asm/i387.h>

#include <asm/aes.h>

#include <crypto/scatterwalk.h>
@@ -1253,14 +1254,19 @@ static struct crypto_alg __rfc4106_alg = { 
};

#endif





static const struct x86_cpu_id aesni_cpu_id[] = {

	X86_FEATURE_MATCH(X86_FEATURE_AES),

	{}

};

MODULE_DEVICE_TABLE(x86cpu, aesni_cpu_id);



static int __init aesni_init(void)

{

	int err;



	if (!cpu_has_aes) {

		printk(KERN_INFO "Intel AES-NI instructions are not detected.\n");

	if (!x86_match_cpu(aesni_cpu_id))

		return -ENODEV;

	}



	if ((err = crypto_fpu_init()))

		goto fpu_err;