[PATCH] arm64:swiotlb:Enable only when Input size through command line
From: Rohit Thapliyal swiotlb default size of 64M is too big as default value therefore it is made configurable through command line through swiotlb_size parameter. swiotlb allocation shall be done only when the swiotlb size is given through command line. Otherwise no swiotlb is allocated. Signed-off-by: Rohit Thapliyal Signed-off-by: Manjeet Pawar Reviewed-by: Akhilesh Kumar Reviewed-by: Ajeet Kumar Yadav --- Documentation/kernel-parameters.txt |3 +++ arch/arm64/mm/init.c|3 ++- include/linux/swiotlb.h |1 + lib/swiotlb.c | 33 + 4 files changed, 35 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c9..12b680f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3875,6 +3875,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. force -- force using of bounce buffers even if they wouldn't be automatically used by the kernel + swiotlb_sz= [KNL] enter swiotlb size. + Sets the swiotlb size for eg. swiotlb_sz=64M + switches= [HW,M68k] sysfs.deprecated=0|1 [KNL] diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index d45f862..89c6b39 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -403,7 +403,8 @@ static void __init free_unused_memmap(void) */ void __init mem_init(void) { - swiotlb_init(1); + if (swiotlb_enabled) + swiotlb_init(1); set_max_mapnr(pfn_to_page(max_pfn) - mem_map); diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h index 017fced..c7eb146 100644 --- a/include/linux/swiotlb.h +++ b/include/linux/swiotlb.h @@ -11,6 +11,7 @@ struct page; struct scatterlist; extern int swiotlb_force; +extern int swiotlb_enabled; /* * Maximum allowable number of contiguous slabs to map, diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 76f29ec..e89296a 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -54,6 +54,7 @@ #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT) int swiotlb_force; +int swiotlb_enabled; /* * Used to do a quick range check in swiotlb_tbl_unmap_single and @@ -96,6 +97,9 @@ static DEFINE_SPINLOCK(io_tlb_lock); static int late_alloc; +unsigned long swiotlb_sz; +unsigned int swiotlb_sz_shift; + static int __init setup_io_tlb_npages(char *str) { @@ -112,6 +116,24 @@ setup_io_tlb_npages(char *str) return 0; } early_param("swiotlb", setup_io_tlb_npages); + +static int __init +setup_io_tlb_size(char *str) +{ + int len = strlen(str); + + if (str[len-1] == 'M') + swiotlb_sz_shift = 20; + else if (str[len-1] == 'K') + swiotlb_sz_shift = 10; + str[len-1] = '\0'; + if (isdigit(*str)) + swiotlb_sz = kstrtoul(str, &str, 0); + + swiotlb_enabled = 1; + return 0; +} +early_param("swiotlb_sz", setup_io_tlb_size); /* make io_tlb_overflow tunable too? */ unsigned long swiotlb_nr_tbl(void) @@ -120,8 +142,9 @@ unsigned long swiotlb_nr_tbl(void) } EXPORT_SYMBOL_GPL(swiotlb_nr_tbl); -/* default to 64MB */ -#define IO_TLB_DEFAULT_SIZE (64UL<<20) +/* Pass from command line as swiotlb_sz=64M (for eg.)*/ +#define IO_TLB_DEFAULT_SIZE (swiotlb_sz<> 20, vstart, vend - 1); + bytes >> swiotlb_sz_shift, + swiotlb_sz_shift == 20 ? 'M' : 'K', + vstart, vend - 1); } int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 00/11] Documentation/sphinx follow-up, again
The first 9 patches are just a resend of [1], there's two patches on top here. Pull details below. BR, Jani. [1] http://mid.gmane.org/cover.1465567017.git.jani.nik...@intel.com The following changes since commit 8569de68e79e94cce6709831edd94accb6942ade: docs: kernel-doc: Add "example" and "note" to the magic section types (2016-06-09 13:35:05 -0600) are available in the git repository at: git://people.freedesktop.org/~jani/drm sphinx-for-docs-next for you to fetch changes up to ebc88ef05c825024a5d95285459b8c842c095c0f: Documentation: add top level 'make help' output for Sphinx (2016-06-23 15:11:51 +0300) Jani Nikula (11): kernel-doc: remove old debug cruft from dump_section() kernel-doc: do not warn about duplicate default section names kernel-doc: add missing semi-colons in option parsing kernel-doc: abstract filename mapping kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs kernel-doc: unify all EXPORT_SYMBOL scanning to one place Documentation/sphinx: remove unnecessary temporary variable Documentation/sphinx: use a more sensible string split in kernel-doc extension Documentation/sphinx: add support for specifying extra export files Documentation/sphinx: drop modindex, we don't have python modules Documentation: add top level 'make help' output for Sphinx Documentation/DocBook/Makefile | 4 +- Documentation/Makefile.sphinx | 8 Documentation/index.rst| 2 - Documentation/sphinx/kernel-doc.py | 18 +--- Makefile | 2 + scripts/kernel-doc | 88 +++--- 6 files changed, 87 insertions(+), 35 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 09/11] Documentation/sphinx: add support for specifying extra export files
Let the user specify file patterns where to look for the EXPORT_SYMBOLs in addition to the file with kernel-doc comments. This is directly based on the -export-file FILE option added to kernel-doc in "kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs", but we extend that with globbing patterns in the Sphinx extension. The file patterns are added as options to the :export: and :internal: arguments of the kernel-doc directive. For example, to extract the documentation of exported functions from include/net/mac80211.h: .. kernel-doc:: include/net/mac80211.h :export: net/mac80211/*.c Without the file pattern, no exported functions would be found, as the EXPORT_SYMBOLs are placed in the various source files under net/mac80211. The matched files are also added as dependencies on the document in Sphinx, as they may affect the output. This is one of the reasons to do the globbing in the Sphinx extension instead of in scripts/kernel-doc. The file pattern remains optional, and is not needed if the kernel-doc comments and EXPORT_SYMBOLs are placed in the source file passed in as the main argument to the kernel-doc directive. This is the most common case across the kernel source tree. Signed-off-by: Jani Nikula --- Documentation/sphinx/kernel-doc.py | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/sphinx/kernel-doc.py b/Documentation/sphinx/kernel-doc.py index d6a76f9a0ba5..dedb24e3bb7a 100644 --- a/Documentation/sphinx/kernel-doc.py +++ b/Documentation/sphinx/kernel-doc.py @@ -31,6 +31,7 @@ import os import subprocess import sys import re +import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList @@ -44,8 +45,8 @@ class KernelDocDirective(Directive): option_spec = { 'doc': directives.unchanged_required, 'functions': directives.unchanged_required, -'export': directives.flag, -'internal': directives.flag, +'export': directives.unchanged, +'internal': directives.unchanged, } has_content = False @@ -54,6 +55,7 @@ class KernelDocDirective(Directive): cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno'] filename = env.config.kerneldoc_srctree + '/' + self.arguments[0] +export_file_patterns = [] # Tell sphinx of the dependency env.note_dependency(os.path.abspath(filename)) @@ -63,14 +65,21 @@ class KernelDocDirective(Directive): # FIXME: make this nicer and more robust against errors if 'export' in self.options: cmd += ['-export'] +export_file_patterns = str(self.options.get('export')).split() elif 'internal' in self.options: cmd += ['-internal'] +export_file_patterns = str(self.options.get('internal')).split() elif 'doc' in self.options: cmd += ['-function', str(self.options.get('doc'))] elif 'functions' in self.options: for f in str(self.options.get('functions')).split(): cmd += ['-function', f] +for pattern in export_file_patterns: +for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern): +env.note_dependency(os.path.abspath(f)) +cmd += ['-export-file', f] + cmd += [filename] try: -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 07/11] Documentation/sphinx: remove unnecessary temporary variable
Leftover cruft. No functional changes. Signed-off-by: Jani Nikula --- Documentation/sphinx/kernel-doc.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/sphinx/kernel-doc.py b/Documentation/sphinx/kernel-doc.py index 4adfb0e91ecc..2856376cc62c 100644 --- a/Documentation/sphinx/kernel-doc.py +++ b/Documentation/sphinx/kernel-doc.py @@ -59,7 +59,6 @@ class KernelDocDirective(Directive): env.note_dependency(os.path.abspath(filename)) tab_width = self.options.get('tab-width', self.state.document.settings.tab_width) -source = filename # FIXME: make this nicer and more robust against errors if 'export' in self.options: @@ -105,7 +104,7 @@ class KernelDocDirective(Directive): lineoffset = int(match.group(1)) - 1 # we must eat our comments since the upset the markup else: -result.append(line, source, lineoffset) +result.append(line, filename, lineoffset) lineoffset += 1 node = nodes.section() -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 08/11] Documentation/sphinx: use a more sensible string split in kernel-doc extension
Using the default str.split doesn't return empty strings like the current version does. Signed-off-by: Jani Nikula --- Documentation/sphinx/kernel-doc.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sphinx/kernel-doc.py b/Documentation/sphinx/kernel-doc.py index 2856376cc62c..d6a76f9a0ba5 100644 --- a/Documentation/sphinx/kernel-doc.py +++ b/Documentation/sphinx/kernel-doc.py @@ -68,7 +68,7 @@ class KernelDocDirective(Directive): elif 'doc' in self.options: cmd += ['-function', str(self.options.get('doc'))] elif 'functions' in self.options: -for f in str(self.options.get('functions')).split(' '): +for f in str(self.options.get('functions')).split(): cmd += ['-function', f] cmd += [filename] -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 10/11] Documentation/sphinx: drop modindex, we don't have python modules
The modindex is for python modules. Signed-off-by: Jani Nikula --- Documentation/index.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/index.rst b/Documentation/index.rst index 71a276f34c7f..1139a7ea39ec 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -18,6 +18,4 @@ Indices and tables == * :ref:`genindex` -* :ref:`modindex` * :ref:`search` - -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 11/11] Documentation: add top level 'make help' output for Sphinx
While there's slight overlap with the DocBook help now, this can stay intact when the DocBook help goes away. Signed-off-by: Jani Nikula --- Documentation/DocBook/Makefile | 4 ++-- Documentation/Makefile.sphinx | 8 Makefile | 2 ++ 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index e0c7e1e0590b..496d4295ec38 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -218,7 +218,7 @@ silent_gen_xml = : ### # Help targets as used by the top-level makefile dochelp: - @echo ' Linux kernel internal documentation in different formats:' + @echo ' Linux kernel internal documentation in different formats (DocBook):' @echo ' htmldocs- HTML' @echo ' pdfdocs - PDF' @echo ' psdocs - Postscript' @@ -227,7 +227,7 @@ dochelp: @echo ' installmandocs - install man pages generated by mandocs' @echo ' cleandocs - clean all generated DocBook files' @echo - @echo 'make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml' + @echo ' make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml' @echo ' valid values for DOCBOOKS are: $(DOCBOOKS)' diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index addf32309bc3..810c11f0d37f 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -60,4 +60,12 @@ installmandocs: cleandocs: $(Q)rm -rf $(BUILDDIR) +dochelp: + @echo ' Linux kernel internal documentation in different formats (Sphinx):' + @echo ' htmldocs- HTML' + @echo ' pdfdocs - PDF' + @echo ' epubdocs- EPUB' + @echo ' xmldocs - XML' + @echo ' cleandocs - clean all generated files' + endif # HAVE_SPHINX diff --git a/Makefile b/Makefile index 8908a51b895a..f7f393c40886 100644 --- a/Makefile +++ b/Makefile @@ -1364,6 +1364,8 @@ help: @$(MAKE) $(build)=$(package-dir) help @echo '' @echo 'Documentation targets:' + @$(MAKE) -f $(srctree)/Documentation/Makefile.sphinx dochelp + @echo '' @$(MAKE) -f $(srctree)/Documentation/DocBook/Makefile dochelp @echo '' @echo 'Architecture specific targets ($(SRCARCH)):' -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 05/11] kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs
If the kernel-doc comments for functions are not in the same file as the EXPORT_SYMBOL statements, the -export and -internal output selections do not work as expected. This is typically the case when the kernel-doc comments are in header files next to the function declarations and the EXPORT_SYMBOL statements are next to the function definitions in the source files. Let the user specify additional source files in which to look for the EXPORT_SYMBOLs using the new -export-file FILE option, which may be given multiple times. The pathological example for this is include/net/mac80211.h, which has all the kernel-doc documentation for the exported functions defined in a plethora of source files net/mac80211/*.c. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 516d95fcefb7..9708a87c7069 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -61,10 +61,10 @@ Output format selection (mutually exclusive): Output selection (mutually exclusive): -export Only output documentation for symbols that have been exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() - in the same FILE. +in the same FILE or any -export-file FILE. -internalOnly output documentation for symbols that have NOT been exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() - in the same FILE. +in the same FILE or any -export-file FILE. -function NAME Only output documentation for the given function(s) or DOC: section title(s). All other functions and DOC: sections are ignored. May be specified multiple times. @@ -76,6 +76,9 @@ Output selection modifiers: -no-doc-sections Do not output DOC: sections. -enable-linenoEnable output of #define LINENO lines. Only works with reStructuredText format. + -export-file FILE Specify an additional FILE in which to look for +EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). To be used with +-export or -internal. May be specified multiple times. Other parameters: -v Verbose output, more warnings and other information. @@ -336,6 +339,8 @@ use constant { my $output_selection = OUTPUT_ALL; my $show_not_found = 0; +my @export_file_list; + my @build_time; if (defined($ENV{'KBUILD_BUILD_TIMESTAMP'}) && (my $seconds = `date -d"${ENV{'KBUILD_BUILD_TIMESTAMP'}}" +%s`) ne '') { @@ -488,6 +493,9 @@ while ($ARGV[0] =~ m/^-(.*)/) { } elsif ($cmd eq "-internal") { # only non-exported symbols $output_selection = OUTPUT_INTERNAL; %function_table = (); +} elsif ($cmd eq "-export-file") { + my $file = shift @ARGV; + push(@export_file_list, $file); } elsif ($cmd eq "-v") { $verbose = 1; } elsif (($cmd eq "-h") || ($cmd eq "--help")) { @@ -2747,6 +2755,25 @@ sub map_filename($) { return $file; } +sub process_export_file($) { +my ($orig_file) = @_; +my $file = map_filename($orig_file); + +if (!open(IN,"<$file")) { + print STDERR "Error: Cannot open file $file\n"; + ++$errors; + return; +} + +while () { + if (/$export_symbol/) { + $function_table{$2} = 1; + } +} + +close(IN); +} + sub process_file($) { my $file; my $identifier; @@ -3081,6 +3108,14 @@ if (open(SOURCE_MAP, "<.tmp_filelist.txt")) { close(SOURCE_MAP); } +if ($output_selection == OUTPUT_EXPORTED || +$output_selection == OUTPUT_INTERNAL) { +foreach (@export_file_list) { + chomp; + process_export_file($_); +} +} + foreach (@ARGV) { chomp; process_file($_); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 06/11] kernel-doc: unify all EXPORT_SYMBOL scanning to one place
Scan all input files for EXPORT_SYMBOLs along with the explicitly specified export files before actually parsing anything. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 9708a87c7069..932b3f34ff06 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -61,10 +61,10 @@ Output format selection (mutually exclusive): Output selection (mutually exclusive): -export Only output documentation for symbols that have been exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() -in the same FILE or any -export-file FILE. +in any input FILE or -export-file FILE. -internalOnly output documentation for symbols that have NOT been exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() -in the same FILE or any -export-file FILE. +in any input FILE or -export-file FILE. -function NAME Only output documentation for the given function(s) or DOC: section title(s). All other functions and DOC: sections are ignored. May be specified multiple times. @@ -2792,17 +2792,6 @@ sub process_file($) { return; } -# two passes for -export and -internal -if ($output_selection == OUTPUT_EXPORTED || - $output_selection == OUTPUT_INTERNAL) { - while () { - if (/$export_symbol/o) { - $function_table{$2} = 1; - } - } - seek(IN, 0, 0); -} - $. = 1; $section_counter = 0; @@ -3110,6 +3099,9 @@ if (open(SOURCE_MAP, "<.tmp_filelist.txt")) { if ($output_selection == OUTPUT_EXPORTED || $output_selection == OUTPUT_INTERNAL) { + +push(@export_file_list, @ARGV); + foreach (@export_file_list) { chomp; process_export_file($_); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line
On 23/06/16 13:13, Manjeet Pawar wrote: From: Rohit Thapliyal swiotlb default size of 64M is too big as default value therefore it is made configurable through command line through swiotlb_size parameter. swiotlb allocation shall be done only when the swiotlb size is given through command line. Otherwise no swiotlb is allocated. So all platforms with most memory physically above 4GB (which is quite a lot of them) are suddenly broken unless they go and muck about with their bootloader? If anyone's got to muck about with their bootloader, why can't it be the memory-constrained platforms just passing "swiotlb=1" instead? Robin. Signed-off-by: Rohit Thapliyal Signed-off-by: Manjeet Pawar Reviewed-by: Akhilesh Kumar Reviewed-by: Ajeet Kumar Yadav --- Documentation/kernel-parameters.txt |3 +++ arch/arm64/mm/init.c|3 ++- include/linux/swiotlb.h |1 + lib/swiotlb.c | 33 + 4 files changed, 35 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c9..12b680f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3875,6 +3875,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. force -- force using of bounce buffers even if they wouldn't be automatically used by the kernel + swiotlb_sz= [KNL] enter swiotlb size. + Sets the swiotlb size for eg. swiotlb_sz=64M + switches= [HW,M68k] sysfs.deprecated=0|1 [KNL] diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index d45f862..89c6b39 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -403,7 +403,8 @@ static void __init free_unused_memmap(void) */ void __init mem_init(void) { - swiotlb_init(1); + if (swiotlb_enabled) + swiotlb_init(1); set_max_mapnr(pfn_to_page(max_pfn) - mem_map); diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h index 017fced..c7eb146 100644 --- a/include/linux/swiotlb.h +++ b/include/linux/swiotlb.h @@ -11,6 +11,7 @@ struct page; struct scatterlist; extern int swiotlb_force; +extern int swiotlb_enabled; /* * Maximum allowable number of contiguous slabs to map, diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 76f29ec..e89296a 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -54,6 +54,7 @@ #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT) int swiotlb_force; +int swiotlb_enabled; /* * Used to do a quick range check in swiotlb_tbl_unmap_single and @@ -96,6 +97,9 @@ static DEFINE_SPINLOCK(io_tlb_lock); static int late_alloc; +unsigned long swiotlb_sz; +unsigned int swiotlb_sz_shift; + static int __init setup_io_tlb_npages(char *str) { @@ -112,6 +116,24 @@ setup_io_tlb_npages(char *str) return 0; } early_param("swiotlb", setup_io_tlb_npages); + +static int __init +setup_io_tlb_size(char *str) +{ + int len = strlen(str); + + if (str[len-1] == 'M') + swiotlb_sz_shift = 20; + else if (str[len-1] == 'K') + swiotlb_sz_shift = 10; + str[len-1] = '\0'; + if (isdigit(*str)) + swiotlb_sz = kstrtoul(str, &str, 0); + + swiotlb_enabled = 1; + return 0; +} +early_param("swiotlb_sz", setup_io_tlb_size); /* make io_tlb_overflow tunable too? */ unsigned long swiotlb_nr_tbl(void) @@ -120,8 +142,9 @@ unsigned long swiotlb_nr_tbl(void) } EXPORT_SYMBOL_GPL(swiotlb_nr_tbl); -/* default to 64MB */ -#define IO_TLB_DEFAULT_SIZE (64UL<<20) +/* Pass from command line as swiotlb_sz=64M (for eg.)*/ +#define IO_TLB_DEFAULT_SIZE (swiotlb_sz<> 20, vstart, vend - 1); + bytes >> swiotlb_sz_shift, + swiotlb_sz_shift == 20 ? 'M' : 'K', + vstart, vend - 1); } int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 02/11] kernel-doc: do not warn about duplicate default section names
Since commit 32217761ee9db0215350dfe1ca4e66f312fb8c54 Author: Jani Nikula Date: Sun May 29 09:40:44 2016 +0300 kernel-doc: concatenate contents of colliding sections we started getting (more) errors on duplicate section names, especially on the default section name "Description": include/net/mac80211.h:3174: warning: duplicate section name 'Description' This is usually caused by a slightly unorthodox placement of parameter descriptions, like in the above case, and kernel-doc resetting back to the default section more than once within a kernel-doc comment. Ignore warnings on the duplicate section name automatically assigned by kernel-doc, and only consider explicitly user assigned duplicate section names an issue. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index ac18eb5ed776..710615f3a4ff 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -542,8 +542,11 @@ sub dump_section { $new_start_line = 0; } else { if (defined($sections{$name}) && ($sections{$name} ne "")) { - print STDERR "${file}:$.: warning: duplicate section name '$name'\n"; - ++$warnings; + # Only warn on user specified duplicate section names. + if ($name ne $section_default) { + print STDERR "${file}:$.: warning: duplicate section name '$name'\n"; + ++$warnings; + } $sections{$name} .= $contents; } else { $sections{$name} = $contents; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 01/11] kernel-doc: remove old debug cruft from dump_section()
No functional changes. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 3 --- 1 file changed, 3 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 27757c21551a..ac18eb5ed776 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -529,21 +529,18 @@ sub dump_section { my $contents = join "\n", @_; if ($name =~ m/$type_param/) { -# print STDERR "parameter def '$1' = '$contents'\n"; $name = $1; $parameterdescs{$name} = $contents; $sectcheck = $sectcheck . $name . " "; $parameterdesc_start_lines{$name} = $new_start_line; $new_start_line = 0; } elsif ($name eq "@\.\.\.") { -# print STDERR "parameter def '...' = '$contents'\n"; $name = "..."; $parameterdescs{$name} = $contents; $sectcheck = $sectcheck . $name . " "; $parameterdesc_start_lines{$name} = $new_start_line; $new_start_line = 0; } else { -# print STDERR "other section '$name' = '$contents'\n"; if (defined($sections{$name}) && ($sections{$name} ne "")) { print STDERR "${file}:$.: warning: duplicate section name '$name'\n"; ++$warnings; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 03/11] kernel-doc: add missing semi-colons in option parsing
Signed-off-by: Jani Nikula --- scripts/kernel-doc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 710615f3a4ff..a6f82c812c15 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -484,10 +484,10 @@ while ($ARGV[0] =~ m/^-(.*)/) { $function_table{$function} = 1; } elsif ($cmd eq "-export") { # only exported symbols $output_selection = OUTPUT_EXPORTED; - %function_table = () + %function_table = (); } elsif ($cmd eq "-internal") { # only non-exported symbols $output_selection = OUTPUT_INTERNAL; - %function_table = () + %function_table = (); } elsif ($cmd eq "-v") { $verbose = 1; } elsif (($cmd eq "-h") || ($cmd eq "--help")) { -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[docs-next PATCH v2 04/11] kernel-doc: abstract filename mapping
Reduce duplication in follow-up work. No functional changes. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index a6f82c812c15..516d95fcefb7 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -2730,26 +2730,35 @@ sub local_unescape($) { return $text; } -sub process_file($) { +sub map_filename($) { my $file; -my $identifier; -my $func; -my $descr; -my $in_purpose = 0; -my $initial_section_counter = $section_counter; my ($orig_file) = @_; -my $leading_space; if (defined($ENV{'SRCTREE'})) { $file = "$ENV{'SRCTREE'}" . "/" . $orig_file; -} -else { +} else { $file = $orig_file; } + if (defined($source_map{$file})) { $file = $source_map{$file}; } +return $file; +} + +sub process_file($) { +my $file; +my $identifier; +my $func; +my $descr; +my $in_purpose = 0; +my $initial_section_counter = $section_counter; +my ($orig_file) = @_; +my $leading_space; + +$file = map_filename($orig_file); + if (!open(IN,"<$file")) { print STDERR "Error: Cannot open file $file\n"; ++$errors; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [docs-next PATCH v2 00/11] Documentation/sphinx follow-up, again
On Thu, 23 Jun 2016 15:28:00 +0300 Jani Nikula wrote: > The first 9 patches are just a resend of [1], there's two patches on top > here. OK, these all look good to me. Applied to the docs tree, sorry for the delay. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: fix wrong value in md.txt
On Fri, 17 Jun 2016 09:40:02 +0800 (CST) "Tiezhu Yang" wrote: > I read drivers/md/raid5.c and find the following related code: > 1) in function 'raid5_set_cache_size': > if (size <= 16 || size > 32768) > return -EINVAL; > 2) #define NR_STRIPES 256 > > So the lower limit value of stripe_cache_size should be 17 and > the default value should be 256. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: tiny typo fix in usb/gadget_multi.txt
On Sat, 11 Jun 2016 02:56:37 +0200 Michal Nazarewicz wrote: > -For the gadget two work under Windows two conditions have to be met: > +For the gadget to work under Windows two conditions have to be met: Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line
On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote: > From: Rohit Thapliyal > > swiotlb default size of 64M is too big as > default value therefore it is made configurable > through command line through swiotlb_size parameter. > swiotlb allocation shall be done only when the > swiotlb size is given through command line. > Otherwise no swiotlb is allocated. I already queued this patch: http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com If you have any objections to it, please reply there. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line
Hi, [auto build test WARNING on v4.7-rc4] [cannot apply to arm64/for-next/core next-20160623] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Manjeet-Pawar/arm64-swiotlb-Enable-only-when-Input-size-through-command-line/20160623-205508 config: x86_64-randconfig-i0-201625 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): lib/swiotlb.c: In function 'setup_io_tlb_size': >> lib/swiotlb.c:131:30: warning: passing argument 2 of 'kstrtoul' makes >> integer from pointer without a cast [-Wint-conversion] swiotlb_sz = kstrtoul(str, &str, 0); ^ In file included from include/linux/list.h:8:0, from include/linux/kobject.h:20, from include/linux/device.h:17, from include/linux/dma-mapping.h:6, from lib/swiotlb.c:21: include/linux/kernel.h:298:32: note: expected 'unsigned int' but argument is of type 'char **' static inline int __must_check kstrtoul(const char *s, unsigned int base, unsigned long *res) ^~~~ vim +/kstrtoul +131 lib/swiotlb.c 115 116 return 0; 117 } 118 early_param("swiotlb", setup_io_tlb_npages); 119 120 static int __init 121 setup_io_tlb_size(char *str) 122 { 123 int len = strlen(str); 124 125 if (str[len-1] == 'M') 126 swiotlb_sz_shift = 20; 127 else if (str[len-1] == 'K') 128 swiotlb_sz_shift = 10; 129 str[len-1] = '\0'; 130 if (isdigit(*str)) > 131 swiotlb_sz = kstrtoul(str, &str, 0); 132 133 swiotlb_enabled = 1; 134 return 0; 135 } 136 early_param("swiotlb_sz", setup_io_tlb_size); 137 /* make io_tlb_overflow tunable too? */ 138 139 unsigned long swiotlb_nr_tbl(void) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PATCH] capabilities: add capability cgroup controller
There are many basic ways to control processes, including capabilities, cgroups and resource limits. However, there are far fewer ways to find out useful values for the limits, except blind trial and error. Currently, there is no way to know which capabilities are actually used. Even the source code is only implicit, in-depth knowledge of each capability must be used when analyzing a program to judge which capabilities the program will exercise. Add a new cgroup controller for monitoring of capabilities in the cgroup. Test case demonstrating basic capability monitoring and how the capabilities are combined at next level (boot to rdshell): (initramfs) cd /sys/fs (initramfs) mount -t cgroup2 cgroup cgroup (initramfs) cd cgroup (initramfs) echo +capability > cgroup.subtree_control (initramfs) mkdir test; cd test (initramfs) echo +capability > cgroup.subtree_control (initramfs) ls capability.used cgroup.events cgroup.subtree_control cgroup.controllers cgroup.procs (initramfs) mkdir first second (initramfs) sh BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) cd first (initramfs) echo $$ >cgroup.procs (initramfs) cat capability.used # nothing so far (initramfs) mknod /dev/z_$$ c 1 2 (initramfs) cat capability.used 0800 # CAP_MKNOD (initramfs) cat ../capability.used 0800 # also seen at next higher level (initramfs) exit (initramfs) sh BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) cd second (initramfs) echo $$ >cgroup.procs (initramfs) cat capability.used # nothing so far (initramfs) chown 1234 /dev/z_* (initramfs) cat capability.used 0001 # CAP_CHROOT (initramfs) cat ../capability.used 0801 # combined at next higher level (initramfs) exit Signed-off-by: Topi Miettinen --- Documentation/cgroup-v2.txt | 17 +++ include/linux/capability_cgroup.h | 7 +++ include/linux/cgroup_subsys.h | 4 ++ init/Kconfig | 6 +++ kernel/capability.c | 2 + security/Makefile | 1 + security/capability_cgroup.c | 99 +++ 7 files changed, 136 insertions(+) create mode 100644 include/linux/capability_cgroup.h create mode 100644 security/capability_cgroup.c diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index 4cc07ce..2b3d277 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -1118,6 +1118,23 @@ writeback as follows. total available memory and applied the same way as vm.dirty[_background]_ratio. +5-4. Capabilities + +The "capability" controller is used to monitor capability use in the +cgroup. This can be used to discover a starting point for capability +bounding sets, even when running a shell script under ambient +capabilities, with only short-lived helper processes exercising the +capabilities. + + +5-4-1. Capability Interface Files + + capability.used + + A read-only file which exists on all cgroups. + + This reports the combined value of capability use in the + current cgroup and all its children. 6. Namespace diff --git a/include/linux/capability_cgroup.h b/include/linux/capability_cgroup.h new file mode 100644 index 000..c03b58d --- /dev/null +++ b/include/linux/capability_cgroup.h @@ -0,0 +1,7 @@ +#ifdef CONFIG_CGROUP_CAPABILITY +void capability_cgroup_update_used(int cap); +#else +static inline void capability_cgroup_update_used(int cap) +{ +} +#endif diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h index 0df0336a..a5161d0 100644 --- a/include/linux/cgroup_subsys.h +++ b/include/linux/cgroup_subsys.h @@ -56,6 +56,10 @@ SUBSYS(hugetlb) SUBSYS(pids) #endif +#if IS_ENABLED(CONFIG_CGROUP_CAPABILITY) +SUBSYS(capability) +#endif + /* * The following subsystems are not supported on the default hierarchy. */ diff --git a/init/Kconfig b/init/Kconfig index f755a60..25d17ef 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1141,6 +1141,12 @@ config CGROUP_PERF Say N if unsure. +config CGROUP_CAPABILITY + bool "Capability controller" + help + Provides a simple controller for monitoring of capabilities in the + cgroup. + config CGROUP_DEBUG bool "Example controller" default n diff --git a/kernel/capability.c b/kernel/capability.c index 45432b5..b57d7f9 100644 --- a/kernel/capability.c +++ b/kernel/capability.c @@ -17,6 +17,7 @@ #include #include #include +#include #include /* @@ -380,6 +381,7 @@ bool ns_capable(struct user_namespace *ns, int cap) } if (security_capable(current_cred(), ns, cap) == 0) { + capability_cgroup_update_used(cap); current->flags |= PF_SUPERPRIV; return true; } diff --git a/security/Makef
[PATCH v3] Add kernel parameter to blacklist modules
Blacklisting a module in linux has long been a problem. The current procedure is to use rd.blacklist=module_name, however, that doesn't cover the case after the initramfs and before a boot prompt (where one is supposed to use /etc/modprobe.d/blacklist.conf to blacklist runtime loading). Using rd.shell to get an early prompt is hit-or-miss, and doesn't cover all situations AFAICT. This patch adds this functionality of permanently blacklisting a module by its name via the kernel parameter module_blacklist=module_name. [v2]: Rusty, use core_param() instead of __setup() which simplifies things. [v3]: Rusty, undo wreckage from strsep() Signed-off-by: Prarit Bhargava Cc: Jonathan Corbet Cc: Rusty Russell Cc: linux-doc@vger.kernel.org --- Documentation/kernel-parameters.txt |3 +++ kernel/module.c | 29 + 2 files changed, 32 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c958d1c..c720b96f2efc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2295,6 +2295,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Note that if CONFIG_MODULE_SIG_FORCE is set, that is always true, so this option does nothing. + module_blacklist= [KNL] Do not load a comma-separated list of + modules. Useful for debugging problem modules. + mousedev.tap_time= [MOUSE] Maximum time between finger touching and leaving touchpad surface for touch to be considered diff --git a/kernel/module.c b/kernel/module.c index 5f71aa63ed2a..5240da88af79 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3155,6 +3155,32 @@ int __weak module_frob_arch_sections(Elf_Ehdr *hdr, return 0; } +/* module_blacklist is a comma-separated list of module names */ +static char *module_blacklist; +static bool blacklisted(char *module_name) +{ + char *str, *entry; + + if (!module_blacklist) + return false; + + str = module_blacklist; + do { + if (str != module_blacklist) + module_blacklist[strlen(str) - 1] = ','; + entry = strsep(&str, ","); + if (!strcmp(module_name, entry)) { + pr_info("module %s is blacklisted\n", module_name); + if (str != module_blacklist) + module_blacklist[strlen(str) - 1] = ','; + return true; + } + } while (str); + + return false; +} +core_param(module_blacklist, module_blacklist, charp, 0400); + static struct module *layout_and_allocate(struct load_info *info, int flags) { /* Module within temporary copy. */ @@ -3165,6 +3191,9 @@ static struct module *layout_and_allocate(struct load_info *info, int flags) if (IS_ERR(mod)) return mod; + if (blacklisted(mod->name)) + return ERR_PTR(-EPERM); + err = check_modinfo(mod, info, flags); if (err) return ERR_PTR(err); -- 1.7.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line
On June 23, 2016 10:30:34 AM EDT, Catalin Marinas wrote: >On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote: >> From: Rohit Thapliyal >> >> swiotlb default size of 64M is too big as >> default value therefore it is made configurable >> through command line through swiotlb_size parameter. >> swiotlb allocation shall be done only when the >> swiotlb size is given through command line. >> Otherwise no swiotlb is allocated. > >I already queued this patch: > >http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com > >If you have any objections to it, please reply there. I do (sorry about duplicate email, the other got rejected by mailing lists). Why not expand the swiotlb= parameter instead of introducing a new one? Also, why not use the swiotlb by itself? That does the job as well? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Documentation: dtb: xgene: Add hwmon dts binding documentation
On Tue, Jun 7, 2016 at 11:05 AM, Hoan Tran wrote: > Hi Jassi, > > Thanks for your reply ! > > On Tue, Jun 7, 2016 at 10:20 AM, Jassi Brar wrote: >> On Tue, May 24, 2016 at 6:31 AM, Hoan Tran wrote: >>> Hi Rob, >>> >>> Thanks for your review ! >>> >>> On Mon, May 23, 2016 at 1:30 PM, Rob Herring wrote: On Mon, May 16, 2016 at 09:17:25AM -0700, Hoan Tran wrote: > This patch adds the APM X-Gene hwmon device tree node documentation. > > Signed-off-by: Hoan Tran > --- > .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt | 14 > ++ > 1 file changed, 14 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt > > diff --git a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt > b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt > new file mode 100644 > index 000..49a482e > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt > @@ -0,0 +1,14 @@ > +APM X-Gene hwmon driver > + > +Hwmon driver accesses sensors over the "SLIMpro" mailbox. DT bindings describe h/w, not driver data. >>> How about this description: "APM X-Gene SOC sensors are accessed over >>> the "SLIMpro" mailbox" ? I'm not sure this belongs in DT and perhaps the devices for the mailbox should be created by the mailbox driver. >>> I don't think the current mailbox supports it. > + > +Required properties : > + - compatible : should be "apm,xgene-slimpro-hwmon" > + - mboxes : use the label reference for the mailbox as the first > parameter. > + The second parameter is the channel number. When do you expect this to be different mailbox numbers? >>> No, this number is not changed. This "mboxes" property is used and >>> required by mailbox.c when hwmon driver requests a mailbox channel >>> >> I think that's inaccurate. >> >> The h/w and the firmware combined is the "platform" from Linux POV. >> Channels are physical resources provided by a mailbox controller. >> Currently the firmware listens on Channel-7 but some future revision >> might switch to, say, Channel-9. Or say the same firmware on next >> revision of h/w may have to switch to Channel-3 because it has only 4 >> channels. So I see the mailbox channel number as a hardware property >> just like an IRQ (which very often change with SoC iterations). > > Agree about that. I suppose this number is not changed. But as you > said, the mailbox channel number can be changed based on SoC or > Firmware. It would be better if this channel number is specified > inside a DT node. > > Hi Rob, do you have any comments ? > > Thanks > Hoan > >> >> Cheers. Hi Rob, Do you have any comments on Jassi's reply ? If not, I'll send another version which included the binding document and DT node. Thanks Hoan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] leds: documentation: 'ide-disk' to 'disk-activity'
Cc: Joseph Jezak Cc: Jörg Sommer Cc: Mark Rutland Signed-off-by: Stephan Linz Acked-by: Rob Herring Signed-off-by: Jacek Anaszewski --- Changes in v5: - Keep documentation for the old 'ide-disk' device tree binding, but mark as deprecated and refer to the new trigger 'disk-activity'. Changes in v4: - Keep the 'ide-disk' trigger and add a second one for 'disk-activity'. Changes in v3: - Port to kernel 4.x - Split into platform independent and dependent parts. v2: https://patchwork.ozlabs.org/patch/117485/ v1: http://dev.gentoo.org/~josejx/ata.patch --- Documentation/devicetree/bindings/leds/common.txt| 5 - Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++-- Documentation/laptops/asus-laptop.txt| 2 +- Documentation/leds/leds-class.txt| 2 +- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index af10678..1c32e31 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -25,8 +25,11 @@ Optional properties for child nodes: system "default-on" - LED will turn on (but for leds-gpio see "default-state" property in Documentation/devicetree/bindings/gpio/led.txt) + "disk-activity" - LED indicates disk activity, the old name "ide-disk" is + still valid for backward compatibility "heartbeat" - LED "double" flashes at a load average based rate - "ide-disk" - LED indicates disk activity + "ide-disk" - LED indicates IDE disk activity (deprecated), do not use for + new implementation, use the new "disk-activity" name instead "timer" - LED flashes at a fixed, configurable rate - led-max-microamp : Maximum LED supply current in microamperes. This property diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index cbbeb18..5b1b43a 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -33,9 +33,9 @@ Examples: leds { compatible = "gpio-leds"; hdd { - label = "IDE Activity"; + label = "Disk Activity"; gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; - linux,default-trigger = "ide-disk"; + linux,default-trigger = "disk-activity"; }; fault { diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index 79a1bc6..5f28587 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt @@ -72,7 +72,7 @@ LEDs echo 1 > /sys/class/leds/asus::mail/brightness will switch the mail LED on. You can also know if they are on/off by reading their content and use - kernel triggers like ide-disk or heartbeat. + kernel triggers like disk-activity or heartbeat. Backlight - diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 44f5e6b..f1f7ec9 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero brightness settings. The class also introduces the optional concept of an LED trigger. A trigger is a kernel based source of led events. Triggers can either be simple or complex. A simple trigger isn't configurable and is designed to slot into -existing subsystems with minimal additional code. Examples are the ide-disk, +existing subsystems with minimal additional code. Examples are the disk-activity, nand-disk and sharpsl-charge triggers. With led triggers disabled, the code optimises away. -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
Jason Cooper wrote: > Modern systems that receive a seed from the bootloader via the > random-seed property (typically from the hw-rng) can mix both sources > for increased resilience. > > Unfortunately, I'm not very familiar with the internals of x86 > bootstrapping. Could GRUB be scripted to do a similar task? How would > the address and size of the seed be passed to the kernel? command line? One suggestion is at: http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
Hey Kees, Thomas, On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: > On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier wrote: > > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: > >> Hey Kees, > >> > >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: > >>> Notable problems that needed solving: > >> ... > >>> - Reasonable entropy is needed early at boot before get_random_bytes() > >>>is available. > >> > >> This series is targetting x86, which typically has RDRAND/RDSEED > >> instructions. Are you referring to other arches? Older x86? Also, > >> isn't this the same requirement for base address KASLR? > >> > >> Don't get me wrong, I want more diverse entropy sources available > >> earlier in the boot process as well. :-) I'm just wondering what's > >> different about this series vs base address KASLR wrt early entropy > >> sources. > >> > > > > I think Kees was referring to the refactor I did to get the similar > > entropy generation than KASLR module randomization. Our approach was > > to provide best entropy possible even if you have an older processor > > or under virtualization without support for these instructions. > > Unfortunately common on companies with a large number of older > > machines. > > Right, the memory offset KASLR uses the same routines as the kernel > base KASLR. The issue is with older x86 systems, which continue to be > very common. We have the same issue in embedded. :-( Compounded by the fact that there is no rand instruction (at least not on ARM). So, even if there's a HW-RNG, you can't access it until the driver is loaded. This is compounded by the fact that most systems deployed today have bootloaders a) without hw-rng drivers, b) without dtb editing, and c) without dtb support at all. My current thinking is to add a devicetree property "userspace,random-seed" . This way, existing, deployed boards can append a dtb to a modern kernel with the property set. The factory bootloader then only needs to amend its boot scripts to read random-seed from the fs to the given address. Modern systems that receive a seed from the bootloader via the random-seed property (typically from the hw-rng) can mix both sources for increased resilience. Unfortunately, I'm not very familiar with the internals of x86 bootstrapping. Could GRUB be scripted to do a similar task? How would the address and size of the seed be passed to the kernel? command line? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: > Hey Kees, Thomas, > > On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: >> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier wrote: >> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: >> >> Hey Kees, >> >> >> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: >> >>> Notable problems that needed solving: >> >> ... >> >>> - Reasonable entropy is needed early at boot before get_random_bytes() >> >>>is available. >> >> >> >> This series is targetting x86, which typically has RDRAND/RDSEED >> >> instructions. Are you referring to other arches? Older x86? Also, >> >> isn't this the same requirement for base address KASLR? >> >> >> >> Don't get me wrong, I want more diverse entropy sources available >> >> earlier in the boot process as well. :-) I'm just wondering what's >> >> different about this series vs base address KASLR wrt early entropy >> >> sources. >> >> >> > >> > I think Kees was referring to the refactor I did to get the similar >> > entropy generation than KASLR module randomization. Our approach was >> > to provide best entropy possible even if you have an older processor >> > or under virtualization without support for these instructions. >> > Unfortunately common on companies with a large number of older >> > machines. >> >> Right, the memory offset KASLR uses the same routines as the kernel >> base KASLR. The issue is with older x86 systems, which continue to be >> very common. > > We have the same issue in embedded. :-( Compounded by the fact that > there is no rand instruction (at least not on ARM). So, even if there's > a HW-RNG, you can't access it until the driver is loaded. > > This is compounded by the fact that most systems deployed today have > bootloaders a) without hw-rng drivers, b) without dtb editing, and c) > without dtb support at all. > > My current thinking is to add a devicetree property > "userspace,random-seed" . This way, existing, deployed > boards can append a dtb to a modern kernel with the property set. > The factory bootloader then only needs to amend its boot scripts to read > random-seed from the fs to the given address. The arm64 KASLR implementation has defined a way for boot loaders to pass in an seed similar to this. It might be nice to have a fall-back to a DT entry, though, then the bootloaders don't need to changed. Ard might have some thoughts on why DT wasn't used for KASLR (I assume the early parsing overhead, but I don't remember the discussion any more). > Modern systems that receive a seed from the bootloader via the > random-seed property (typically from the hw-rng) can mix both sources > for increased resilience. Yeah, that could work. > Unfortunately, I'm not very familiar with the internals of x86 > bootstrapping. Could GRUB be scripted to do a similar task? How would > the address and size of the seed be passed to the kernel? command line? Command line could work (though it would need scrubbing to avoid it leaking into /proc/cmdine), but there's also the "zero-page" used by bootloaders to pass details to the kernel (see Documentation/x86/boot.txt). Right now, x86 has sufficient entropy (though rdrand is best). -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris wrote: > Jason Cooper wrote: > >> Modern systems that receive a seed from the bootloader via the >> random-seed property (typically from the hw-rng) can mix both sources >> for increased resilience. >> >> Unfortunately, I'm not very familiar with the internals of x86 >> bootstrapping. Could GRUB be scripted to do a similar task? How would >> the address and size of the seed be passed to the kernel? command line? > > One suggestion is at: > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image Interesting! This might pose a problem for signed images, though. (Actually, for signed arm kernels is the DT signed too? If so, it would be a similar problem.) -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
On 23 June 2016 at 21:58, Kees Cook wrote: > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: >> Hey Kees, Thomas, >> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier wrote: >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper >>> > wrote: >>> >> Hey Kees, >>> >> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: >>> >>> Notable problems that needed solving: >>> >> ... >>> >>> - Reasonable entropy is needed early at boot before get_random_bytes() >>> >>>is available. >>> >> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED >>> >> instructions. Are you referring to other arches? Older x86? Also, >>> >> isn't this the same requirement for base address KASLR? >>> >> >>> >> Don't get me wrong, I want more diverse entropy sources available >>> >> earlier in the boot process as well. :-) I'm just wondering what's >>> >> different about this series vs base address KASLR wrt early entropy >>> >> sources. >>> >> >>> > >>> > I think Kees was referring to the refactor I did to get the similar >>> > entropy generation than KASLR module randomization. Our approach was >>> > to provide best entropy possible even if you have an older processor >>> > or under virtualization without support for these instructions. >>> > Unfortunately common on companies with a large number of older >>> > machines. >>> >>> Right, the memory offset KASLR uses the same routines as the kernel >>> base KASLR. The issue is with older x86 systems, which continue to be >>> very common. >> >> We have the same issue in embedded. :-( Compounded by the fact that >> there is no rand instruction (at least not on ARM). So, even if there's >> a HW-RNG, you can't access it until the driver is loaded. >> >> This is compounded by the fact that most systems deployed today have >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c) >> without dtb support at all. >> >> My current thinking is to add a devicetree property >> "userspace,random-seed" . This way, existing, deployed >> boards can append a dtb to a modern kernel with the property set. >> The factory bootloader then only needs to amend its boot scripts to read >> random-seed from the fs to the given address. > > The arm64 KASLR implementation has defined a way for boot loaders to > pass in an seed similar to this. It might be nice to have a fall-back > to a DT entry, though, then the bootloaders don't need to changed. > > Ard might have some thoughts on why DT wasn't used for KASLR (I assume > the early parsing overhead, but I don't remember the discussion any > more). > On arm64, only DT is used for KASLR (even when booting via ACPI). My first draft used register x1, but this turned out to be too much of a hassle, since parsing the DT is also necessary to discover whether there is a 'nokaslr' argument on the kernel command line. So the current implementation only supports a single method, which is the /chosen/kaslr-seed uint64 property. >> Modern systems that receive a seed from the bootloader via the >> random-seed property (typically from the hw-rng) can mix both sources >> for increased resilience. > > Yeah, that could work. > >> Unfortunately, I'm not very familiar with the internals of x86 >> bootstrapping. Could GRUB be scripted to do a similar task? How would >> the address and size of the seed be passed to the kernel? command line? > > Command line could work (though it would need scrubbing to avoid it > leaking into /proc/cmdine), but there's also the "zero-page" used by > bootloaders to pass details to the kernel (see > Documentation/x86/boot.txt). Right now, x86 has sufficient entropy > (though rdrand is best). > > -Kees > > -- > Kees Cook > Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
On Thu, Jun 23, 2016 at 12:59:07PM -0700, Kees Cook wrote: > On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris wrote: > > Jason Cooper wrote: > > > >> Modern systems that receive a seed from the bootloader via the > >> random-seed property (typically from the hw-rng) can mix both sources > >> for increased resilience. > >> > >> Unfortunately, I'm not very familiar with the internals of x86 > >> bootstrapping. Could GRUB be scripted to do a similar task? How would > >> the address and size of the seed be passed to the kernel? command line? > > > > One suggestion is at: > > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image > > Interesting! This might pose a problem for signed images, though. > (Actually, for signed arm kernels is the DT signed too? If so, it > would be a similar problem.) That's the reason for userspace,random-seed = . Once set, the dtb never has to change. The bootloader loads the file to the same address at each boot. Userspace is responsible, as it is already, for updating the random-seed file while up. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
Hey Sandy, On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote: > Jason Cooper wrote: > > > Modern systems that receive a seed from the bootloader via the > > random-seed property (typically from the hw-rng) can mix both sources > > for increased resilience. > > > > Unfortunately, I'm not very familiar with the internals of x86 > > bootstrapping. Could GRUB be scripted to do a similar task? How would > > the address and size of the seed be passed to the kernel? command line? > > One suggestion is at: > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image Yes, this is very similar to the latent_entropy series that I think Kees just merged. Well, at a high level, it is. 'store a seed in the kernel, use it at reboot'. These approaches are good in that they provide yet another source of entropy to the kernel. However, both suffer from the kernel binary being very static in time and across distro installs. Particularly with embedded systems. It almost becomes a long term secret. Which, the longer it lives, the less chance there is of it being secret. I'm not really comfortable with what John suggests, here: """ Next step: It should be straightforward to write a tool that efficiently updates the stored seed within the boot image. Updating MUST occur during provisioning, before the device gets booted for the first time ... and also from time to time thereafter. Updating the boot image isn’t be quite as simple as dd of=/var/lib/urandom/random-seed but neither is it rocket surgery. The cost is utterly negligible compared to the cost of a security breach, which is the relevant comparison. """ Editing the installed kernel binary to add the seed is exposing the system to unnecessary risk of bricking the system (e.g. powerfail halfway through) [0]. Yes, this can be mitigated by following a similar process to kernel updates, but why? The bootloader already knows how to read a file into RAM. We just need to put it in the right place and tell it to do so. And userspace already writes a new random-seed during system init and clean shutdown. We just need to connect the dots so deployed systems can use the seed earlier without having to hack the kernel or update the bootloader. Which, while possible, a lot of folks are skittish to do. thx, Jason. [0] I imagine it also borks code-signing... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify
On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote: > > > - removed the .resume hook as upstream changed suspend/resume hooks and > > > there > > > is no need in the end to re-enable host notify on resume (tested on > > > Lenovo > > > t440 and t450). > > > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell) > > but not on the T450 (Broadwell) laptop I have now here. > > > > Wolfram, I can resend the whole series or a follow-up patch to re-enable > > after resume Host Notify. How do you prefer I deal with that? > > That depends a little how we want to handle patch 4. I am going to apply > patches 1+2 today to my tree. Then you can just resend patch 3 which I > hope will get some review soon, but I will pick it up for 4.8 later > nonetheless. If it is not causing too much dependency hassle, I'd prefer > that patch 4 goes via Dmitry's input tree. Any chance I could get a stable branch with these 2 patches based on 4.6 so that I can pull it and merge the #4? This way we do not need to wait for 2 releases to merge everything... Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On Thu, Jun 23, 2016 at 8:07 AM, Topi Miettinen wrote: > There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find > out useful values for the limits, except blind trial and error. > > Currently, there is no way to know which capabilities are actually used. > Even the source code is only implicit, in-depth knowledge of each > capability must be used when analyzing a program to judge which > capabilities the program will exercise. > > Add a new cgroup controller for monitoring of capabilities > in the cgroup. > > Test case demonstrating basic capability monitoring and how the > capabilities are combined at next level (boot to rdshell): > > (initramfs) cd /sys/fs > (initramfs) mount -t cgroup2 cgroup cgroup > (initramfs) cd cgroup > (initramfs) echo +capability > cgroup.subtree_control > (initramfs) mkdir test; cd test > (initramfs) echo +capability > cgroup.subtree_control > (initramfs) ls > capability.used cgroup.events cgroup.subtree_control > cgroup.controllers cgroup.procs > (initramfs) mkdir first second > (initramfs) sh > > BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > (initramfs) cd first > (initramfs) echo $$ >cgroup.procs > (initramfs) cat capability.used > # nothing so far > (initramfs) mknod /dev/z_$$ c 1 2 > (initramfs) cat capability.used > 0800 # CAP_MKNOD > (initramfs) cat ../capability.used > 0800 # also seen at next higher level > (initramfs) exit > (initramfs) sh > > BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > (initramfs) cd second > (initramfs) echo $$ >cgroup.procs > (initramfs) cat capability.used > # nothing so far > (initramfs) chown 1234 /dev/z_* > (initramfs) cat capability.used > 0001 # CAP_CHROOT nitpick: this is CAP_CHOWN, not CAP_CHROOT -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
Hello, On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote: > There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find > out useful values for the limits, except blind trial and error. > > Currently, there is no way to know which capabilities are actually used. > Even the source code is only implicit, in-depth knowledge of each > capability must be used when analyzing a program to judge which > capabilities the program will exercise. > > Add a new cgroup controller for monitoring of capabilities > in the cgroup. > > Test case demonstrating basic capability monitoring and how the > capabilities are combined at next level (boot to rdshell): This doesn't have anything to do with resource control and I don't think it's a good idea to add arbitrary monitoring mechanisms to cgroup just because it's easy to add interface there. Given that capabilities are inherited and modified through the process hierarchy, shouldn't this be part of that? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify
On Thu, Jun 23, 2016 at 01:55:52PM -0700, Dmitry Torokhov wrote: > On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote: > > > > - removed the .resume hook as upstream changed suspend/resume hooks and > > > > there > > > > is no need in the end to re-enable host notify on resume (tested on > > > > Lenovo > > > > t440 and t450). > > > > > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell) > > > but not on the T450 (Broadwell) laptop I have now here. > > > > > > Wolfram, I can resend the whole series or a follow-up patch to re-enable > > > after resume Host Notify. How do you prefer I deal with that? > > > > That depends a little how we want to handle patch 4. I am going to apply > > patches 1+2 today to my tree. Then you can just resend patch 3 which I > > hope will get some review soon, but I will pick it up for 4.8 later > > nonetheless. If it is not causing too much dependency hassle, I'd prefer > > that patch 4 goes via Dmitry's input tree. > > Any chance I could get a stable branch with these 2 patches based on 4.6 > so that I can pull it and merge the #4? This way we do not need to wait > for 2 releases to merge everything... Sure. git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/host-notify Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify
On Thu, Jun 23, 2016 at 11:46:55PM +0200, Wolfram Sang wrote: > On Thu, Jun 23, 2016 at 01:55:52PM -0700, Dmitry Torokhov wrote: > > On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote: > > > > > - removed the .resume hook as upstream changed suspend/resume hooks > > > > > and there > > > > > is no need in the end to re-enable host notify on resume (tested on > > > > > Lenovo > > > > > t440 and t450). > > > > > > > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell) > > > > but not on the T450 (Broadwell) laptop I have now here. > > > > > > > > Wolfram, I can resend the whole series or a follow-up patch to re-enable > > > > after resume Host Notify. How do you prefer I deal with that? > > > > > > That depends a little how we want to handle patch 4. I am going to apply > > > patches 1+2 today to my tree. Then you can just resend patch 3 which I > > > hope will get some review soon, but I will pick it up for 4.8 later > > > nonetheless. If it is not causing too much dependency hassle, I'd prefer > > > that patch 4 goes via Dmitry's input tree. > > > > Any chance I could get a stable branch with these 2 patches based on 4.6 > > so that I can pull it and merge the #4? This way we do not need to wait > > for 2 releases to merge everything... > > Sure. > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/host-notify Thanks! -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support
Hi Benjamin, On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote: > + > +struct mapping_table_entry { > + u16 rmiaddr; Should be __le16 rmiaddr, otherwise: CHECK drivers/input/rmi4/rmi_smbus.c drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment (different base types) drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] [usertype] rmiaddr drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] > + > +static struct i2c_driver rmi_smb_driver; > + I do not think this forward declaration is needed. > + > +#ifdef CONFIG_PM_SLEEP > +static int rmi_smb_suspend(struct device *dev) __maybe_unused instead of #ifdef. > +{ > + struct i2c_client *client = to_i2c_client(dev); > + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client); > + int ret; > + > + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev); > + if (ret) > + dev_warn(dev, "Failed to suspend device: %d\n", ret); > + > + return ret; > +} > +#endif > + > +#ifdef CONFIG_PM > +static int rmi_smb_runtime_suspend(struct device *dev) Same here? > +{ > + struct i2c_client *client = to_i2c_client(dev); > + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client); > + int ret; > + > + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev); > + if (ret) > + dev_warn(dev, "Failed to suspend device: %d\n", ret); > + > + return 0; > +} > + > +static int rmi_smb_runtime_resume(struct device *dev) > +{ > + struct i2c_client *client = to_i2c_client(dev); > + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client); > + int ret; > + > + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev); > + if (ret) > + dev_warn(dev, "Failed to resume device: %d\n", ret); > + > + return 0; > +} > +#endif > + > +static const struct dev_pm_ops rmi_smb_pm = { > + SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL) > + SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume, > +NULL) > +}; > + > +static int rmi_smb_resume(struct device *dev) > +{ > + struct i2c_client *client = container_of(dev, struct i2c_client, dev); > + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client); > + struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev; > + int ret; > + > + rmi_smb_reset(&rmi_smb->xport, 0); > + > + rmi_reset(rmi_dev); > + > + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev); > + if (ret) > + dev_warn(dev, "Failed to resume device: %d\n", ret); > + > + return 0; > +} > + > +static const struct i2c_device_id rmi_id[] = { > + { "rmi4_smbus", 0 }, > + { } > +}; > +MODULE_DEVICE_TABLE(i2c, rmi_id); > + > +static struct i2c_driver rmi_smb_driver = { > + .driver = { > + .owner = THIS_MODULE, > + .name = "rmi4_smbus", > + .pm = &rmi_smb_pm, > + .resume = rmi_smb_resume, Why rmi_smb_resume is not part of rmi_smb_pm? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: > There are many basic ways to control processes, including capabilities, > cgroups and resource limits. However, there are far fewer ways to find > out useful values for the limits, except blind trial and error. > > Currently, there is no way to know which capabilities are actually used. > Even the source code is only implicit, in-depth knowledge of each > capability must be used when analyzing a program to judge which > capabilities the program will exercise. > > Add a new cgroup controller for monitoring of capabilities > in the cgroup. I'm having trouble understanding how valuable this feature is to our users, and that's a rather important thing! Perhaps it would help if you were to explain your motivation: particular use cases which benefited from this, for example. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On 06/23/16 21:38, Tejun Heo wrote: > Hello, > > On Thu, Jun 23, 2016 at 06:07:10PM +0300, Topi Miettinen wrote: >> There are many basic ways to control processes, including capabilities, >> cgroups and resource limits. However, there are far fewer ways to find >> out useful values for the limits, except blind trial and error. >> >> Currently, there is no way to know which capabilities are actually used. >> Even the source code is only implicit, in-depth knowledge of each >> capability must be used when analyzing a program to judge which >> capabilities the program will exercise. >> >> Add a new cgroup controller for monitoring of capabilities >> in the cgroup. >> >> Test case demonstrating basic capability monitoring and how the >> capabilities are combined at next level (boot to rdshell): > > This doesn't have anything to do with resource control and I don't > think it's a good idea to add arbitrary monitoring mechanisms to > cgroup just because it's easy to add interface there. Given that > capabilities are inherited and modified through the process hierarchy, > shouldn't this be part of that? With per process tracking, it's easy to miss if a short-lived process exercised capabilities. Especially with ambient capabilities, the parent process could be a shell script which might not use capabilities at all, but its children do the heavy lifting. Per process tracking (like in the version I sent earlier) could still be added on top of this to complement cgroup level tracking, but I think cgroup approach is more flexible as it can cover anything from a single task to a collection of processes. -Topi > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR
Hi Ard, On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote: > On 23 June 2016 at 21:58, Kees Cook wrote: > > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: > >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: > >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier > >>> wrote: > >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper > >>> > wrote: > >>> >> Hey Kees, > >>> >> > >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: > >>> >>> Notable problems that needed solving: > >>> >> ... > >>> >>> - Reasonable entropy is needed early at boot before > >>> >>> get_random_bytes() > >>> >>>is available. > >>> >> > >>> >> This series is targetting x86, which typically has RDRAND/RDSEED > >>> >> instructions. Are you referring to other arches? Older x86? Also, > >>> >> isn't this the same requirement for base address KASLR? > >>> >> > >>> >> Don't get me wrong, I want more diverse entropy sources available > >>> >> earlier in the boot process as well. :-) I'm just wondering what's > >>> >> different about this series vs base address KASLR wrt early entropy > >>> >> sources. > >>> >> > >>> > > >>> > I think Kees was referring to the refactor I did to get the similar > >>> > entropy generation than KASLR module randomization. Our approach was > >>> > to provide best entropy possible even if you have an older processor > >>> > or under virtualization without support for these instructions. > >>> > Unfortunately common on companies with a large number of older > >>> > machines. > >>> > >>> Right, the memory offset KASLR uses the same routines as the kernel > >>> base KASLR. The issue is with older x86 systems, which continue to be > >>> very common. > >> > >> We have the same issue in embedded. :-( Compounded by the fact that > >> there is no rand instruction (at least not on ARM). So, even if there's > >> a HW-RNG, you can't access it until the driver is loaded. > >> > >> This is compounded by the fact that most systems deployed today have > >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c) > >> without dtb support at all. > >> > >> My current thinking is to add a devicetree property > >> "userspace,random-seed" . This way, existing, deployed > >> boards can append a dtb to a modern kernel with the property set. > >> The factory bootloader then only needs to amend its boot scripts to read > >> random-seed from the fs to the given address. > > > > The arm64 KASLR implementation has defined a way for boot loaders to > > pass in an seed similar to this. It might be nice to have a fall-back > > to a DT entry, though, then the bootloaders don't need to changed. > > > > Ard might have some thoughts on why DT wasn't used for KASLR (I assume > > the early parsing overhead, but I don't remember the discussion any > > more). > > > > On arm64, only DT is used for KASLR (even when booting via ACPI). My > first draft used register x1, but this turned out to be too much of a > hassle, since parsing the DT is also necessary to discover whether > there is a 'nokaslr' argument on the kernel command line. So the > current implementation only supports a single method, which is the > /chosen/kaslr-seed uint64 property. Ok, just to clarify (after a short offline chat), my goal is to set a userspace,random-seed property in the device tree once. The bootloader scripts would also only need to be altered once. Then, at each boot, the bootloader reads the entirety of /var/lib/misc/random-seed (512 bytes) into the configured address. random-seed could be in /boot, or on a flash partition. The decompressor would consume a small portion of that seed for kaslr and such. After that, the rest would be consumed by random.c to initialize the entropy pools. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On 06/23/16 23:46, Andrew Morton wrote: > On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: > >> There are many basic ways to control processes, including capabilities, >> cgroups and resource limits. However, there are far fewer ways to find >> out useful values for the limits, except blind trial and error. >> >> Currently, there is no way to know which capabilities are actually used. >> Even the source code is only implicit, in-depth knowledge of each >> capability must be used when analyzing a program to judge which >> capabilities the program will exercise. >> >> Add a new cgroup controller for monitoring of capabilities >> in the cgroup. > > I'm having trouble understanding how valuable this feature is to our > users, and that's a rather important thing! > > Perhaps it would help if you were to explain your motivation: > particular use cases which benefited from this, for example. > It's easy to control with for example systemd or many other tools, which capabilities a service should have at the start. But how should a system administrator, application developer or distro maintaner ever determine a suitable value for this? Currently the only way seems to be to become an expert on capabilities, make an educated guess how the set of programs in question happen to work in this context and especially how they could exercise the capabilites in all possible use cases. Even then, the outcome is to just try something to see if that happens to work. Reading the source code (if available) does not help very much, because the use of capabilities is anything but explicit there. This is way too difficult, there must be some easier way. The information which capabilities actually were used in a trial run gives a much better starting point. The users can just use the list of used capabilities with configuring the service or when developing or maintaining the application. Of course, even that could still fail eventually, but then you simply copy the new value of used capabilities to the configuration, whereas currently you have to reconsider your understanding of the capabilities and the programs in light of the failure, which by itself might give no new useful information. One way to solve this for good would be to make the use of capabilities explicit in the ABI. For example, there could be a system call dac_override() which would be the only possible way ever to use the capability CAP_DAC_OVERRIDE and so forth. Then reading source code, tracing and many other approaches would be useful. But the OS with that kind of ABI (not Linux) would not be Unix-like at all for any (potentially) capability using programs, like find(1) or cat(1). -Topi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] docs: cgroup/pids: update documentation to include pids.events
So that users know what the interface and meaning of the keyed values are. In addition, mention that the only time that since=0 is when the limit was changed. Signed-off-by: Aleksa Sarai --- Documentation/cgroup-v1/pids.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/cgroup-v1/pids.txt b/Documentation/cgroup-v1/pids.txt index 1a078b5d281a..a9bb7b964c6f 100644 --- a/Documentation/cgroup-v1/pids.txt +++ b/Documentation/cgroup-v1/pids.txt @@ -33,6 +33,11 @@ limit in the hierarchy is followed). pids.current tracks all child cgroup hierarchies, so parent/pids.current is a superset of parent/child/pids.current. +pids.events shows information about the number of failed forks in a particular +cgroup, both overall (since the cgroup was created) and recently (since the +last limit reset). Userspace is notified of each time a process failed to fork +in a cgroup. + Example --- @@ -83,3 +88,16 @@ sh: fork: Resource temporary unavailable # /bin/echo "We can't even spawn a single process now." sh: fork: Resource temporary unavailable # + +We can also see how many times a particular cgroup has failed to fork. For an +example cgroup: + +# cat /sys/fs/cgroup/pids/some_cgroup/pids.events +since 1 +total 12 +# + +This cgroup has had 12 associated process fail to fork throughout its lifetime, +and has had 1 process fail to fork since the limit was last set. On setting the +limit, the since counter becomes 0 and userspace is notified (this is the only +case where since will be 0 and userspace will get a notification). -- 2.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] cgroup: pids: show number of failed forks since limit reset
This allows users to dynamically adjust their limits based on how many failed forks happened since they last reset their limits, otherwise they would have to track (in a racy way) how many limit failures there were since the last limit change manually. In addition, we log the first failure since the limit was reset (which was the original semantics of the patchset). In addition, I clarified the licensing for this file. Signed-off-by: Aleksa Sarai --- kernel/cgroup_pids.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c index 2bd673783f1a..54ec3e4f3b71 100644 --- a/kernel/cgroup_pids.c +++ b/kernel/cgroup_pids.c @@ -26,9 +26,10 @@ * * Copyright (C) 2015 Aleksa Sarai * - * This file is subject to the terms and conditions of version 2 of the GNU - * General Public License. See the file COPYING in the main directory of the - * Linux distribution for more details. + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. */ #include @@ -53,8 +54,11 @@ struct pids_cgroup { /* Handle for "pids.events" */ struct cgroup_file events_file; - /* Number of times fork failed because limit was hit. */ - atomic64_t events_limit; + /* Total number of times fork failed because limit was hit. */ + atomic64_t hits_total; + + /* Number of times fork failed since limit was last set. */ + atomic64_t hits_since; }; static struct pids_cgroup *css_pids(struct cgroup_subsys_state *css) @@ -78,7 +82,8 @@ pids_css_alloc(struct cgroup_subsys_state *parent) pids->limit = PIDS_MAX; atomic64_set(&pids->counter, 0); - atomic64_set(&pids->events_limit, 0); + atomic64_set(&pids->hits_total, 0); + atomic64_set(&pids->hits_since, 0); return &pids->css; } @@ -226,8 +231,12 @@ static int pids_can_fork(struct task_struct *task) pids = css_pids(css); err = pids_try_charge(pids, 1); if (err) { - /* Only log the first time events_limit is incremented. */ - if (atomic64_inc_return(&pids->events_limit) == 1) { + /* +* We only log the first time a fork fails after a limit has +* been set. Resetting the limit will cause us to log again. +*/ + atomic64_inc(&pids->hits_total); + if (atomic64_inc_return(&pids->hits_since) == 1) { pr_info("cgroup: fork rejected by pids controller in "); pr_cont_cgroup_path(task_cgroup(current, pids_cgrp_id)); pr_cont("\n"); @@ -281,6 +290,9 @@ set_limit: * critical that any racing fork()s follow the new limit. */ pids->limit = limit; + /* Reset the since counter and notify userspace. */ + atomic64_set(&pids->hits_since, 0); + cgroup_file_notify(&pids->events_file); return nbytes; } @@ -310,7 +322,8 @@ static int pids_events_show(struct seq_file *sf, void *v) { struct pids_cgroup *pids = css_pids(seq_css(sf)); - seq_printf(sf, "max %lld\n", (s64)atomic64_read(&pids->events_limit)); + seq_printf(sf, "since\t%lld\n", (s64)atomic64_read(&pids->hits_since)); + seq_printf(sf, "total\t%lld\n", (s64)atomic64_read(&pids->hits_total)); return 0; } -- 2.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] cgroup: pids: extend pids.events
While reading the patchset by Kenny Yu, I realised that not having a field for the "recent" number of failed forks means that userspace would have trouble accurately deciding whether or not it should increase the limits. In addition, by having hits_since, we get to maintain the on-reset-we-log-failures-again semantics that Tejun said he liked. Aleksa Sarai (2): cgroup: pids: show number of failed forks since limit reset docs: cgroup/pids: update documentation to include pids.events Documentation/cgroup-v1/pids.txt | 18 ++ kernel/cgroup_pids.c | 31 ++- 2 files changed, 40 insertions(+), 9 deletions(-) -- 2.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line
Dear Konrad, On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote: > On June 23, 2016 10:30:34 AM EDT, Catalin Marinas > wrote: > >On Thu, Jun 23, 2016 at 05:43:40PM +0530, Manjeet Pawar wrote: > >> From: Rohit Thapliyal > >> > >> swiotlb default size of 64M is too big as > >> default value therefore it is made configurable > >> through command line through swiotlb_size parameter. > >> swiotlb allocation shall be done only when the > >> swiotlb size is given through command line. > >> Otherwise no swiotlb is allocated. > > > >I already queued this patch: > > > >http://lkml.kernel.org/g/1465372426-4077-1-git-send-email-jszh...@marvell.com > > > >If you have any objections to it, please reply there. > > > I do (sorry about duplicate email, the other got rejected by mailing lists). > > Why not expand the swiotlb= parameter instead of introducing a new one? Do you mean pass "swiotlb=" for those platforms(most probably, arm64 with less than 4GB DDR) which don't need swiotlb? I'm afraid this is not convenient, and users even don't notice swiotlb parameter. From another side, pass "swiotlb=0" will make the swiotlb reserve 64MB instead, so how can we achieve zero reserved memory for swiotlb through "swiotlb=" parameter? PS: my patch didn't introduce new boot parameter. I'm not sure I got your meaning, so could you please comment my patch directly? Thanks, Jisheng > > Also, why not use the swiotlb by itself? That does the job as well? > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote: > On 06/23/16 23:46, Andrew Morton wrote: >> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: >> >>> There are many basic ways to control processes, including capabilities, >>> cgroups and resource limits. However, there are far fewer ways to find >>> out useful values for the limits, except blind trial and error. >>> >>> Currently, there is no way to know which capabilities are actually used. >>> Even the source code is only implicit, in-depth knowledge of each >>> capability must be used when analyzing a program to judge which >>> capabilities the program will exercise. >>> >>> Add a new cgroup controller for monitoring of capabilities >>> in the cgroup. >> >> I'm having trouble understanding how valuable this feature is to our >> users, and that's a rather important thing! >> >> Perhaps it would help if you were to explain your motivation: >> particular use cases which benefited from this, for example. >> > > It's easy to control with for example systemd or many other tools, which > capabilities a service should have at the start. But how should a system > administrator, application developer or distro maintaner ever determine > a suitable value for this? Currently the only way seems to be to become > an expert on capabilities, make an educated guess how the set of > programs in question happen to work in this context and especially how > they could exercise the capabilites in all possible use cases. Even > then, the outcome is to just try something to see if that happens to > work. Reading the source code (if available) does not help very much, > because the use of capabilities is anything but explicit there. > > This is way too difficult, there must be some easier way. The > information which capabilities actually were used in a trial run gives a > much better starting point. The users can just use the list of used > capabilities with configuring the service or when developing or > maintaining the application. Of course, even that could still fail > eventually, but then you simply copy the new value of used capabilities > to the configuration, whereas currently you have to reconsider your > understanding of the capabilities and the programs in light of the > failure, which by itself might give no new useful information. > > One way to solve this for good would be to make the use of capabilities > explicit in the ABI. For example, there could be a system call > dac_override() which would be the only possible way ever to use the > capability CAP_DAC_OVERRIDE and so forth. Then reading source code, > tracing and many other approaches would be useful. But the OS with that > kind of ABI (not Linux) would not be Unix-like at all for any > (potentially) capability using programs, like find(1) or cat(1). The problem is that most of the capabilities are so powerful on their own that limiting services to just a few may be all but useless. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] leds: documentation: 'ide-disk' to 'disk-activity'
Hi Stephan, On 06/23/2016 09:38 PM, Stephan Linz wrote: Cc: Joseph Jezak Cc: Jörg Sommer Cc: Mark Rutland Signed-off-by: Stephan Linz Acked-by: Rob Herring Signed-off-by: Jacek Anaszewski --- Changes in v5: - Keep documentation for the old 'ide-disk' device tree binding, but mark as deprecated and refer to the new trigger 'disk-activity'. Changes in v4: - Keep the 'ide-disk' trigger and add a second one for 'disk-activity'. Changes in v3: - Port to kernel 4.x - Split into platform independent and dependent parts. v2: https://patchwork.ozlabs.org/patch/117485/ v1: http://dev.gentoo.org/~josejx/ata.patch --- Documentation/devicetree/bindings/leds/common.txt| 5 - Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++-- Documentation/laptops/asus-laptop.txt| 2 +- Documentation/leds/leds-class.txt| 2 +- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index af10678..1c32e31 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -25,8 +25,11 @@ Optional properties for child nodes: system "default-on" - LED will turn on (but for leds-gpio see "default-state" property in Documentation/devicetree/bindings/gpio/led.txt) + "disk-activity" - LED indicates disk activity, the old name "ide-disk" is + still valid for backward compatibility "heartbeat" - LED "double" flashes at a load average based rate - "ide-disk" - LED indicates disk activity + "ide-disk" - LED indicates IDE disk activity (deprecated), do not use for + new implementation, use the new "disk-activity" name instead I'd like to reorganize this change. I think that the two affected properties should be placed next to each other. I'd also remove the remark about ide-disk at disk-activity, since we're leaving ide-disk, with added reference to disk-activity. How about following: + "disk-activity" - LED indicates disk activity - "ide-disk" - LED indicates disk activity + "ide-disk" - LED indicates IDE disk activity (deprecated), in new implementations use "disk-activity" "timer" - LED flashes at a fixed, configurable rate - led-max-microamp : Maximum LED supply current in microamperes. This property diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index cbbeb18..5b1b43a 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -33,9 +33,9 @@ Examples: leds { compatible = "gpio-leds"; hdd { - label = "IDE Activity"; + label = "Disk Activity"; gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>; - linux,default-trigger = "ide-disk"; + linux,default-trigger = "disk-activity"; }; fault { diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index 79a1bc6..5f28587 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt @@ -72,7 +72,7 @@ LEDs echo 1 > /sys/class/leds/asus::mail/brightness will switch the mail LED on. You can also know if they are on/off by reading their content and use - kernel triggers like ide-disk or heartbeat. + kernel triggers like disk-activity or heartbeat. Backlight - diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 44f5e6b..f1f7ec9 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero brightness settings. The class also introduces the optional concept of an LED trigger. A trigger is a kernel based source of led events. Triggers can either be simple or complex. A simple trigger isn't configurable and is designed to slot into -existing subsystems with minimal additional code. Examples are the ide-disk, +existing subsystems with minimal additional code. Examples are the disk-activity, nand-disk and sharpsl-charge triggers. With led triggers disabled, the code optimises away. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html