Loading 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 Loading @@ -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 Loading Loading @@ -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. Loading Loading @@ -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 Loading Documentation/filesystems/debugfs.txt +4 −1 Original line number Diff line number Diff line Loading @@ -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. Loading arch/x86/Kconfig +3 −0 Original line number Diff line number Diff line Loading @@ -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 Loading arch/x86/crypto/aesni-intel_glue.c +9 −3 Original line number Diff line number Diff line Loading @@ -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> Loading Loading @@ -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; Loading Loading
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 Loading @@ -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 Loading Loading @@ -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. Loading Loading @@ -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 Loading
Documentation/filesystems/debugfs.txt +4 −1 Original line number Diff line number Diff line Loading @@ -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. Loading
arch/x86/Kconfig +3 −0 Original line number Diff line number Diff line Loading @@ -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 Loading
arch/x86/crypto/aesni-intel_glue.c +9 −3 Original line number Diff line number Diff line Loading @@ -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> Loading Loading @@ -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; Loading
