date:20170819

Re: [PATCH v3 07/10] dt-bindings: add compatible string for Allwinner R40 CCU

2017-08-19 Thread Chen-Yu Tsai

On Sun, May 28, 2017 at 11:09 PM, Chen-Yu Tsai  wrote:
> On Sat, May 27, 2017 at 6:23 PM, Icenowy Zheng  wrote:
>> Allwinner R40 has a clock controlling unit like the ones on other
>> Allwinner SoCs after sun6i, and can also use a CCU-based driver.
>>
>> Add a compatible string for it.
>>
>> Signed-off-by: Icenowy Zheng 
>> Acked-by: Rob Herring 
>
> Reviewed-by: Chen-Yu Tsai 

Fixed the conflict and applied for 4.14. Next time please include this when you
send the driver patches.

ChenYu
--
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

[RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

2017-08-19 Thread Masahiro Yamada

In Linux build system convention, we do not run tools such as
flex, bison, gperf during the kernel building.  Instead, manage
generated C files in the repository with _shipped suffixes.
They are simply shipped (copied) removing the _shipped suffixes
during the kernel building.

Commit 7373f4f83c71 ("kbuild: add implicit rules for parser generation")
added a mechanism to regenerate intermediate C files easily.
The build rules are surrounded with ifdef REGENERATE_PARSERS.
So, we need to pass REGENERATE_PARSERS=1 from the command line
when we want to update them.

Here is one question.  Is it acceptable to use those rules all the time?
That is, generate those C files by flex, bison, gperf during the
kernel building.

This means, the build system depends on more external tools.
>From the users' point of view, they will need to install
flex, bison, gperf in order to build the kernel.
>From the developers' point of view, the advantage is
we do not need to version-control generated files, i.e. _shipped files
will be deleted.

I'd like to know if this is acceptable or not.

For example, currently some files are simply shipped (copied)
when building the kconfig program.

  $ make mrproper; make defconfig
HOSTCC  scripts/basic/fixdep
HOSTCC  scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC  scripts/kconfig/zconf.tab.o
HOSTLD  scripts/kconfig/conf
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #

With this series, they are created from *real* sources
(*.y, *.l, *.gperf files).

  $ make mrproper; make defconfig
HOSTCC  scripts/basic/fixdep
HOSTCC  scripts/kconfig/conf.o
YACCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
GPERF   scripts/kconfig/zconf.hash.c
HOSTCC  scripts/kconfig/zconf.tab.o
HOSTLD  scripts/kconfig/conf
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #

Note:
The tool versions in Documentation/process/changes.rst are just
place-holders for now.  We need to figure out the minimal versions
if we like to switch to this approach.



Masahiro Yamada (3):
  kbuild: generate *.hash.c during build
  kbuild: generate *.lex.c during build
  kbuild: generate *.tab.c and *.tab.h during build

 Documentation/process/changes.rst|   36 +
 scripts/Makefile.lib |   26 +-
 scripts/dtc/Makefile |6 +-
 scripts/dtc/dtc-lexer.lex.c_shipped  | 2259 ---
 scripts/dtc/dtc-parser.tab.c_shipped | 2303 
 scripts/dtc/dtc-parser.tab.h_shipped |  125 --
 scripts/genksyms/Makefile|4 +-
 scripts/genksyms/keywords.hash.c_shipped |  230 ---
 scripts/genksyms/lex.lex.c_shipped   | 2291 ---
 scripts/genksyms/parse.tab.c_shipped | 2394 -
 scripts/genksyms/parse.tab.h_shipped |  119 --
 scripts/kconfig/Makefile |1 +
 scripts/kconfig/zconf.hash.c_shipped |  297 
 scripts/kconfig/zconf.lex.c_shipped  | 2473 --
 scripts/kconfig/zconf.tab.c_shipped  | 2471 -
 15 files changed, 53 insertions(+), 14982 deletions(-)
 delete mode 100644 scripts/dtc/dtc-lexer.lex.c_shipped
 delete mode 100644 scripts/dtc/dtc-parser.tab.c_shipped
 delete mode 100644 scripts/dtc/dtc-parser.tab.h_shipped
 delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
 delete mode 100644 scripts/genksyms/lex.lex.c_shipped
 delete mode 100644 scripts/genksyms/parse.tab.c_shipped
 delete mode 100644 scripts/genksyms/parse.tab.h_shipped
 delete mode 100644 scripts/kconfig/zconf.hash.c_shipped
 delete mode 100644 scripts/kconfig/zconf.lex.c_shipped
 delete mode 100644 scripts/kconfig/zconf.tab.c_shipped

-- 
2.7.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

[RFC PATCH 1/3] kbuild: generate *.hash.c during build

2017-08-19 Thread Masahiro Yamada

*.hash.c files are artifacts generated from *.gperf by using gperf.
Instead of running gperf, we conventionally version-control
*.hash.c_shipped files and copy them to *.hash.c during build.

It is true that this approach can minimize external tool dependency,
but we need to update the shipped files from time to time.  This
commit switches to build-time generation of the intermediate C files.

Signed-off-by: Masahiro Yamada 
---

 Documentation/process/changes.rst|  12 ++
 scripts/Makefile.lib |  11 +-
 scripts/genksyms/Makefile|   1 +
 scripts/genksyms/keywords.hash.c_shipped | 230 
 scripts/kconfig/Makefile |   1 +
 scripts/kconfig/zconf.hash.c_shipped | 297 ---
 6 files changed, 19 insertions(+), 533 deletions(-)
 delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
 delete mode 100644 scripts/kconfig/zconf.hash.c_shipped

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index adbb50ae5246..793e96fe47e3 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -31,6 +31,7 @@ you probably needn't concern yourself with isdn4k-utils.
 == ===  

 GNU C  3.2  gcc --version
 GNU make   3.81 make --version
+gperf  3.0.4gperf --version
 binutils   2.20 ld -v
 util-linux 2.10ofdformat --version
 module-init-tools  0.9.10   depmod -V
@@ -72,6 +73,12 @@ Make
 
 You will need GNU make 3.81 or later to build the kernel.
 
+gperf
+-
+
+Since Linux 4.14, the build system generates perfect hash functions
+during build.  This requires gperf 3.04 or later.
+
 Binutils
 
 
@@ -338,6 +345,11 @@ Make
 
 - 
 
+gperf
+-
+
+- 
+
 Binutils
 
 
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 58c05e5d9870..da7b42f7a5b8 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -192,16 +192,15 @@ $(foreach m, $(notdir $1), \
$(addprefix $(obj)/, $(foreach s, $3, $($(m:%$(strip $2)=%$(s)))
 endef
 
-ifdef REGENERATE_PARSERS
-
 # GPERF
 # ---
-quiet_cmd_gperf = GPERF $@
+quiet_cmd_gperf = GPERF   $@
   cmd_gperf = gperf -t --output-file $@ -a -C -E -g -k 1,3,$$ -p -t $<
 
-.PRECIOUS: $(src)/%.hash.c_shipped
-$(src)/%.hash.c_shipped: $(src)/%.gperf
-   $(call cmd,gperf)
+$(src)/%.hash.c: $(src)/%.gperf FORCE
+   $(call if_changed,gperf)
+
+ifdef REGENERATE_PARSERS
 
 # LEX
 # ---
diff --git a/scripts/genksyms/Makefile b/scripts/genksyms/Makefile
index aca33b98bf63..ce09b96fcb7b 100644
--- a/scripts/genksyms/Makefile
+++ b/scripts/genksyms/Makefile
@@ -11,4 +11,5 @@ HOSTCFLAGS_lex.lex.o := -I$(src)
 # dependencies on generated files need to be listed explicitly
 $(obj)/lex.lex.o: $(obj)/keywords.hash.c $(obj)/parse.tab.h
 
+targets:= keywords.hash.c
 clean-files:= keywords.hash.c lex.lex.c parse.tab.c parse.tab.h
diff --git a/scripts/genksyms/keywords.hash.c_shipped 
b/scripts/genksyms/keywords.hash.c_shipped
deleted file mode 100644
index 738018ba7375..
--- a/scripts/genksyms/keywords.hash.c_shipped
+++ /dev/null
@@ -1,230 +0,0 @@
-/* ANSI-C code produced by gperf version 3.0.4 */
-/* Command-line: gperf -t --output-file 
scripts/genksyms/keywords.hash.c_shipped -a -C -E -g -k '1,3,$' -p -t 
scripts/genksyms/keywords.gperf  */
-
-#if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \
-  && ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \
-  && (')' == 41) && ('*' == 42) && ('+' == 43) && (',' == 44) \
-  && ('-' == 45) && ('.' == 46) && ('/' == 47) && ('0' == 48) \
-  && ('1' == 49) && ('2' == 50) && ('3' == 51) && ('4' == 52) \
-  && ('5' == 53) && ('6' == 54) && ('7' == 55) && ('8' == 56) \
-  && ('9' == 57) && (':' == 58) && (';' == 59) && ('<' == 60) \
-  && ('=' == 61) && ('>' == 62) && ('?' == 63) && ('A' == 65) \
-  && ('B' == 66) && ('C' == 67) && ('D' == 68) && ('E' == 69) \
-  && ('F' == 70) && ('G' == 71) && ('H' == 72) && ('I' == 73) \
-  && ('J' == 74) && ('K' == 75) && ('L' == 76) && ('M' == 77) \
-  && ('N' == 78) && ('O' == 79) && ('P' == 80) && ('Q' == 81) \
-  && ('R' == 82) && ('S' == 83) && ('T' == 84) && ('U' == 85) \
-  && ('V' == 86) && ('W' == 87) && ('X' == 88) && ('Y' == 89) \
-  && ('Z' == 90) && ('[' == 91) && ('\\' == 92) && (']' == 93) \
-  && ('^' == 94) && ('_' == 95) && ('a' == 97) && ('b' == 98) \
-  && ('c' == 99) && ('d' == 100) && ('e' == 101) && ('f' == 102) \
-  && ('g' == 103) && ('h' == 104) && ('i' == 105) && ('j'

[PATCH RFC] media: open.rst: document devnode-centric and mc-centric types

2017-08-19 Thread Mauro Carvalho Chehab

When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node. Yet, we never made it clear, at the V4L2 spec,
about the differences between both types.

Let's document them with the current implementation.

Signed-off-by: Mauro Carvalho Chehab 
---

This patch is a result of this week's discussion we had with regards to merging
a patch series from Sakari documenting the need of propagating streaming
control between sub-devices on some complex mc-centric devices.

One big gap on our documentation popped up: while we have distinct behavior
for mc-centric and devnode-centric types of V4L2 devices, we never clearly
documented about that.

This RFC patch is a first attempt to have a definition of those types, and to
standardize the names we use to distinguish between those types.

Comments are welcome.


 Documentation/media/uapi/v4l/open.rst | 37 +++
 1 file changed, 37 insertions(+)

diff --git a/Documentation/media/uapi/v4l/open.rst 
b/Documentation/media/uapi/v4l/open.rst
index afd116edb40d..9cf4f74c466a 100644
--- a/Documentation/media/uapi/v4l/open.rst
+++ b/Documentation/media/uapi/v4l/open.rst
@@ -6,6 +6,43 @@
 Opening and Closing Devices
 ***
 
+Types of V4L2 devices
+=
+
+V4L2 devices are usually complex: they're implemented via a main driver and
+several other drivers. The main driver always exposes a V4L2 device node
+(see :ref:`v4l2_device_naming`). The other devices are called **sub-devices**.
+They are usually controlled via a serial bus (I2C or SMBus).
+
+When V4L2 started, there was only one type of device, fully controlled via
+V4L2 device nodes. We call those devices as **devnode-centric devices**.
+Since the end of 2010, a new type of V4L2 device was added, in order to
+support complex devices that are common on embedded systems. Those devices
+are controlled mainly via the media controller. So, they're called:
+**mc-centric devices**.
+
+On a **devnode-centric device**, the device and their corresponding hardware
+pipelines are controlled via the V4L2 device node. They may optionally
+expose the hardware pipelines via the
+:ref:`media controller API `.
+
+On a **mc-centric device**, before using the V4L2 device, it is required to
+set the hardware pipelines via the
+:ref:`media controller API `. On those devices, the
+sub-devices' configuration can be controlled via the
+:ref:`sub-device API `, with creates one device node per sub device.
+On such devices, the V4L2 device node is mainly responsible for controlling
+the streaming features, while the media controller and the subdevices device
+nodes are responsible for configuring the hardware.
+
+.. note::
+
+   Currently, it is forbidden for a **devnode-centric device** to expose
+   subdevices via :ref:`sub-device API `, although this might
+   change in the future.
+
+
+.. _v4l2_device_naming:
 
 Device Naming
 =
-- 
2.13.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: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

2017-08-19 Thread Cao jin

Hi,
  I am stuck in a similar problem recent days by chance.
  I am just curious about the purpose of introduction of these *_shipped
file, are they just for user's convenience when user doesn't install the
those tools?

-- 
Sincerely,
Cao jin

On 08/19/2017 04:49 PM, Masahiro Yamada wrote:
> In Linux build system convention, we do not run tools such as
> flex, bison, gperf during the kernel building.  Instead, manage
> generated C files in the repository with _shipped suffixes.
> They are simply shipped (copied) removing the _shipped suffixes
> during the kernel building.
> 
> Commit 7373f4f83c71 ("kbuild: add implicit rules for parser generation")
> added a mechanism to regenerate intermediate C files easily.
> The build rules are surrounded with ifdef REGENERATE_PARSERS.
> So, we need to pass REGENERATE_PARSERS=1 from the command line
> when we want to update them.
> 
> Here is one question.  Is it acceptable to use those rules all the time?
> That is, generate those C files by flex, bison, gperf during the
> kernel building.
> 
> This means, the build system depends on more external tools.
>>From the users' point of view, they will need to install
> flex, bison, gperf in order to build the kernel.
>>From the developers' point of view, the advantage is
> we do not need to version-control generated files, i.e. _shipped files
> will be deleted.
> 
> I'd like to know if this is acceptable or not.
> 
> For example, currently some files are simply shipped (copied)
> when building the kconfig program.
> 
>   $ make mrproper; make defconfig
> HOSTCC  scripts/basic/fixdep
> HOSTCC  scripts/kconfig/conf.o
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/zconf.lex.c
> SHIPPED scripts/kconfig/zconf.hash.c
> HOSTCC  scripts/kconfig/zconf.tab.o
> HOSTLD  scripts/kconfig/conf
>   *** Default configuration is based on 'x86_64_defconfig'
>   #
>   # configuration written to .config
>   #
> 
> With this series, they are created from *real* sources
> (*.y, *.l, *.gperf files).
> 
>   $ make mrproper; make defconfig
> HOSTCC  scripts/basic/fixdep
> HOSTCC  scripts/kconfig/conf.o
> YACCscripts/kconfig/zconf.tab.c
> LEX scripts/kconfig/zconf.lex.c
> GPERF   scripts/kconfig/zconf.hash.c
> HOSTCC  scripts/kconfig/zconf.tab.o
> HOSTLD  scripts/kconfig/conf
>   *** Default configuration is based on 'x86_64_defconfig'
>   #
>   # configuration written to .config
>   #
> 
> Note:
> The tool versions in Documentation/process/changes.rst are just
> place-holders for now.  We need to figure out the minimal versions
> if we like to switch to this approach.
> 
> 
> 
> Masahiro Yamada (3):
>   kbuild: generate *.hash.c during build
>   kbuild: generate *.lex.c during build
>   kbuild: generate *.tab.c and *.tab.h during build
> 
>  Documentation/process/changes.rst|   36 +
>  scripts/Makefile.lib |   26 +-
>  scripts/dtc/Makefile |6 +-
>  scripts/dtc/dtc-lexer.lex.c_shipped  | 2259 ---
>  scripts/dtc/dtc-parser.tab.c_shipped | 2303 
>  scripts/dtc/dtc-parser.tab.h_shipped |  125 --
>  scripts/genksyms/Makefile|4 +-
>  scripts/genksyms/keywords.hash.c_shipped |  230 ---
>  scripts/genksyms/lex.lex.c_shipped   | 2291 ---
>  scripts/genksyms/parse.tab.c_shipped | 2394 -
>  scripts/genksyms/parse.tab.h_shipped |  119 --
>  scripts/kconfig/Makefile |1 +
>  scripts/kconfig/zconf.hash.c_shipped |  297 
>  scripts/kconfig/zconf.lex.c_shipped  | 2473 
> --
>  scripts/kconfig/zconf.tab.c_shipped  | 2471 -
>  15 files changed, 53 insertions(+), 14982 deletions(-)
>  delete mode 100644 scripts/dtc/dtc-lexer.lex.c_shipped
>  delete mode 100644 scripts/dtc/dtc-parser.tab.c_shipped
>  delete mode 100644 scripts/dtc/dtc-parser.tab.h_shipped
>  delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
>  delete mode 100644 scripts/genksyms/lex.lex.c_shipped
>  delete mode 100644 scripts/genksyms/parse.tab.c_shipped
>  delete mode 100644 scripts/genksyms/parse.tab.h_shipped
>  delete mode 100644 scripts/kconfig/zconf.hash.c_shipped
>  delete mode 100644 scripts/kconfig/zconf.lex.c_shipped
>  delete mode 100644 scripts/kconfig/zconf.tab.c_shipped
> 



--
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] docs: fix security/keys paths and section headings

2017-08-19 Thread Josh Holland

A few changes to security/keys documentation as suggested by Nick Desaulniers.

This is my first patch series, so apologies for the inevitable errors in
formatting, recipients, etc.

Josh Holland (2):
  docs: Standardise capitalisation of section headers in core.rst
  docs: Fix paths in security/keys

 Documentation/security/keys/core.rst  | 26 +++
 Documentation/security/keys/request-key.rst   |  2 +-
 Documentation/security/keys/trusted-encrypted.rst |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

-- 
2.14.1

--
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] docs: Standardise capitalisation of section headers in core.rst

2017-08-19 Thread Josh Holland

The table of contents in security/keys/core.rst had different
capitalisation to the section headers, which broke case-sensitive
search.

Signed-off-by: Josh Holland 
---
 Documentation/security/keys/core.rst | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/security/keys/core.rst 
b/Documentation/security/keys/core.rst
index 1648fa80b..7c39c595c 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -16,17 +16,17 @@ The key service can be configured on by enabling:
 
 This document has the following sections:
 
-   - Key overview
-   - Key service overview
-   - Key access permissions
-   - SELinux support
-   - New procfs files
-   - Userspace system call interface
-   - Kernel services
-   - Notes on accessing payload contents
-   - Defining a key type
-   - Request-key callback service
-   - Garbage collection
+   - Key Overview
+   - Key Service Overview
+   - Key Access Permissions
+   - SELinux Support
+   - New ProcFS Files
+   - Userspace System Call Interface
+   - Kernel Services
+   - Notes On Accessing Payload Contents
+   - Defining a Key Type
+   - Request-Key Callback Service
+   - Garbage Collection
 
 
 Key Overview
-- 
2.14.1

--
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: Fix paths in security/keys

2017-08-19 Thread Josh Holland

Several paths in the security/keys documentation were incorrect.

Signed-off-by: Josh Holland 
---
 Documentation/security/keys/core.rst  | 4 ++--
 Documentation/security/keys/request-key.rst   | 2 +-
 Documentation/security/keys/trusted-encrypted.rst | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/security/keys/core.rst 
b/Documentation/security/keys/core.rst
index 7c39c595c..396c7cc4f 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -443,7 +443,7 @@ The main syscalls are:
  /sbin/request-key will be invoked in an attempt to obtain a key. The
  callout_info string will be passed as an argument to the program.
 
- See also Documentation/security/keys-request-key.txt.
+ See also Documentation/security/keys/request-key.rst.
 
 
 The keyctl syscall functions are:
@@ -973,7 +973,7 @@ payload contents" for more information.
 If successful, the key will have been attached to the default keyring for
 implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
 
-See also Documentation/security/keys-request-key.txt.
+See also Documentation/security/keys/request-key.rst.
 
 
  *  To search for a key, passing auxiliary data to the upcaller, call::
diff --git a/Documentation/security/keys/request-key.rst 
b/Documentation/security/keys/request-key.rst
index aba327841..b2d16abaa 100644
--- a/Documentation/security/keys/request-key.rst
+++ b/Documentation/security/keys/request-key.rst
@@ -3,7 +3,7 @@ Key Request Service
 ===
 
 The key request service is part of the key retention service (refer to
-Documentation/security/keys.txt).  This document explains more fully how
+Documentation/security/core.rst).  This document explains more fully how
 the requesting algorithm works.
 
 The process starts by either the kernel requesting a service by calling
diff --git a/Documentation/security/keys/trusted-encrypted.rst 
b/Documentation/security/keys/trusted-encrypted.rst
index 7b503831b..3bb24e09a 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk 
and file encryption
 are anticipated.  In particular the new format 'ecryptfs' has been defined in
 in order to use encrypted keys to mount an eCryptfs filesystem.  More details
 about the usage can be found in the file
-``Documentation/security/keys-ecryptfs.txt``.
+``Documentation/security/keys/ecryptfs.rst``.
-- 
2.14.1

--
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: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

2017-08-19 Thread Linus Torvalds

On Sat, Aug 19, 2017 at 1:49 AM, Masahiro Yamada
 wrote:
>
> Here is one question.  Is it acceptable to use those rules all the time?
> That is, generate those C files by flex, bison, gperf during the
> kernel building.

Yeah, I think we probably should do that.

However, when I just tested, I noticed that we have issues with
re-generating those files. With gperf 3.1 installed, I get

  In file included from scripts/kconfig/zconf.tab.c:213:0:
  scripts/kconfig/zconf.gperf:147:1: error: conflicting types for
‘kconf_id_lookup’
  scripts/kconfig/zconf.gperf:12:31: note: previous declaration of
‘kconf_id_lookup’ was here
   static const struct kconf_id *kconf_id_lookup(register const char
*str, register unsigned int len);
 ^~~

because gperf now generates

   const struct kconf_id *
  -kconf_id_lookup (register const char *str, register unsigned int len)
  +kconf_id_lookup (register const char *str, register size_t len)

and I'm not sure how to detect that automatically. It seems to be a
gperf-3.1 change, and gperf doesn't seem to generate any version
markers.

Working around that, I hit:

  In file included from scripts/genksyms/lex.lex.c:1921:0:
  scripts/genksyms/keywords.gperf:54:1: error: conflicting types for
‘is_reserved_word’
   static, STATIC_KEYW
   ^~~~
  In file included from scripts/genksyms/lex.lex.c:1921:0:
  scripts/genksyms/keywords.gperf:6:30: note: previous declaration of
‘is_reserved_word’ was here
   static const struct resword *is_reserved_word(register const char
*str, register unsigned int len);
  ^~~~

so we have at least two cases of this in the source tree.

So one of the advantages of the pre-shipped files is that we can avoid
that kind of crazy version issues with the tools.

But if we can solve the versioning thing easily, I certainly don't
mind getting rid of the pre-generated files. Having to have
flex/bison/gperf isn't a huge onus on the kernel build system.

  Linus
--
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: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

2017-08-19 Thread Linus Torvalds

On Sat, Aug 19, 2017 at 10:03 AM, Linus Torvalds
 wrote:
>
> So one of the advantages of the pre-shipped files is that we can avoid
> that kind of crazy version issues with the tools.

Side note: the traditional way to handle this is autoconf etc. Since I
think autoconf is evil crap, I refuse to have anything what-so-ever to
do with it.

gperf is clearly written by clowns that don't understand about
compatibility issues - it would have been trivial for them to add some
kind of marker define so that you could test for this directly rather
than depend on some kind of autoconf "try to build and see if it
fails" crap.

So I think the best option would be to jhust get rid of gperf, and use
a normal hash function instead (even if it isn't "perfect" - it's not
like perfect hashes are so wonderful).

I wonder if those two ID lookups are even worth hashing at all - the
arrays aren't so big, and the uses aren't so timing-critical, so it's
entirely possible that we could just get rid of any hashing at all and
just use some stupid linear search thing.

I assume that flex/bison are stable enough that we don't have the same
kind of annoying stupid version issues with it.

Anybody want to look at just getting rid of the gperf use?

  Linus
--
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: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

2017-08-19 Thread Linus Torvalds

On Sat, Aug 19, 2017 at 10:14 AM, Linus Torvalds
 wrote:
>
> Anybody want to look at just getting rid of the gperf use?

I took a stab at it. It wasn't too bad, although I think this needs a
*lot* of testing, and I think it needs checking of Makefile
dependencies etc.

NOTE NOTE NOTE! This may be *COMPLETELY* broken. It just happens to
build for me.  So when I say "it wasn't too bad", I really mean "it
wasn't too bad, but I didn't spend a lot of effort on it either".

Honestly, the code is better and more legible without gperf, imho. And
it removes more lines than it adds - and even if you ignore changes to
the shipped lines, it's only an additional 15 lines of code,

It's likely not even any slower, but who the hell knows.. Do we even
care? It's almost certainly faster if you compare to generating that
gperf code.

  Linus
From bb3290d91695bb1ae78ab86f18fb4d7ad8e5ebcc Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Sat, 19 Aug 2017 10:17:02 -0700
Subject: [PATCH] Remove gperf usage from toolchain

It turns out that gperf-3.1 changed types in the generated code in ways
that aren't even trivially detectable without having to generate a test-file.

It's just not worth using tools and libraries from clowns that don't
understand or care about compatibility.  So get rid of gperf.

Signed-off-by: Linus Torvalds 
---
 Documentation/dontdiff   |   1 -
 scripts/genksyms/Makefile|   4 +-
 scripts/genksyms/keywords.c  |  74 
 scripts/genksyms/keywords.gperf  |  61 ---
 scripts/genksyms/keywords.hash.c_shipped | 230 
 scripts/genksyms/lex.l   |   8 +-
 scripts/genksyms/lex.lex.c_shipped   |   8 +-
 scripts/kconfig/.gitignore   |   1 -
 scripts/kconfig/Makefile |   4 +-
 scripts/kconfig/kconf_id.c   |  54 ++
 scripts/kconfig/lkc.h|   2 +-
 scripts/kconfig/zconf.gperf  |  50 --
 scripts/kconfig/zconf.hash.c_shipped | 297 ---
 scripts/kconfig/zconf.tab.c_shipped  |  10 +-
 scripts/kconfig/zconf.y  |  10 +-
 15 files changed, 151 insertions(+), 663 deletions(-)
 create mode 100644 scripts/genksyms/keywords.c
 delete mode 100644 scripts/genksyms/keywords.gperf
 delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
 create mode 100644 scripts/kconfig/kconf_id.c
 delete mode 100644 scripts/kconfig/zconf.gperf
 delete mode 100644 scripts/kconfig/zconf.hash.c_shipped

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 358b47c06ad4..2228fcc8e29f 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -259,5 +259,4 @@ wakeup.bin
 wakeup.elf
 wakeup.lds
 zImage*
-zconf.hash.c
 zoffset.h
diff --git a/scripts/genksyms/Makefile b/scripts/genksyms/Makefile
index aca33b98bf63..3c23bab3367b 100644
--- a/scripts/genksyms/Makefile
+++ b/scripts/genksyms/Makefile
@@ -9,6 +9,6 @@ HOSTCFLAGS_parse.tab.o := -I$(src)
 HOSTCFLAGS_lex.lex.o := -I$(src)
 
 # dependencies on generated files need to be listed explicitly
-$(obj)/lex.lex.o: $(obj)/keywords.hash.c $(obj)/parse.tab.h
+$(obj)/lex.lex.o: $(obj)/parse.tab.h
 
-clean-files	:= keywords.hash.c lex.lex.c parse.tab.c parse.tab.h
+clean-files	:= lex.lex.c parse.tab.c parse.tab.h
diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
new file mode 100644
index ..9f40bcd17d07
--- /dev/null
+++ b/scripts/genksyms/keywords.c
@@ -0,0 +1,74 @@
+static struct resword {
+	const char *name;
+	int token;
+} keywords[] = {
+	{ "EXPORT_SYMBOL", EXPORT_SYMBOL_KEYW },
+	{ "EXPORT_SYMBOL_GPL", EXPORT_SYMBOL_KEYW },
+	{ "EXPORT_SYMBOL_GPL_FUTURE", EXPORT_SYMBOL_KEYW },
+	{ "EXPORT_UNUSED_SYMBOL", EXPORT_SYMBOL_KEYW },
+	{ "EXPORT_UNUSED_SYMBOL_GPL", EXPORT_SYMBOL_KEYW },
+	{ "__asm", ASM_KEYW },
+	{ "__asm__", ASM_KEYW },
+	{ "__attribute", ATTRIBUTE_KEYW },
+	{ "__attribute__", ATTRIBUTE_KEYW },
+	{ "__const", CONST_KEYW },
+	{ "__const__", CONST_KEYW },
+	{ "__extension__", EXTENSION_KEYW },
+	{ "__inline", INLINE_KEYW },
+	{ "__inline__", INLINE_KEYW },
+	{ "__signed", SIGNED_KEYW },
+	{ "__signed__", SIGNED_KEYW },
+	{ "__typeof", TYPEOF_KEYW },
+	{ "__typeof__", TYPEOF_KEYW },
+	{ "__volatile", VOLATILE_KEYW },
+	{ "__volatile__", VOLATILE_KEYW },
+	{ "__builtin_va_list", VA_LIST_KEYW },
+
+	// According to rth, c99 defines "_Bool", __restrict", __restrict__", "restrict".  KAO
+	{ "_Bool", BOOL_KEYW },
+	{ "_restrict", RESTRICT_KEYW },
+	{ "__restrict__", RESTRICT_KEYW },
+	{ "restrict", RESTRICT_KEYW },
+	{ "asm", ASM_KEYW },
+
+	// attribute commented out in modutils 2.4.2.  People are using 'attribute' as a
+	// field name which breaks the genksyms parser.  It is not a gcc keyword anyway.
+	// KAO. },
+	// { "attribute", ATTRIBUTE_KEYW },
+
+	{ "auto", AUTO_KEYW },
+	{ "char", CHAR_KEYW },
+	{ "const", CONST_KEYW },
+	{ "double", DOUBLE_KEYW },
+	{ "enum", ENUM_KEYW },
+	{ "extern", EXTER

Re: [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation

2017-08-19 Thread Eric W. Biederman

Ram Pai  writes:

> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index d4e545d..fe1e7c7 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -247,6 +248,15 @@ void user_single_step_siginfo(struct task_struct *tsk,
>   info->si_addr = (void __user *)regs->nip;
>  }
>  
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +static void fill_sig_info_pkey(int si_code, siginfo_t *info, unsigned long 
> addr)
> +{
> + if (si_code != SEGV_PKUERR)
> + return;

Given that SEGV_PKUERR is a signal specific si_code this test is
insufficient to detect an pkey error.  You also need to check
that signr == SIGSEGV

> + info->si_pkey = get_paca()->paca_pkey;
> +}
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
>  void _exception(int signr, struct pt_regs *regs, int code, unsigned long 
> addr)
>  {
>   siginfo_t info;
> @@ -274,6 +284,11 @@ void _exception(int signr, struct pt_regs *regs, int 
> code, unsigned long addr)
>   info.si_signo = signr;
>   info.si_code = code;
>   info.si_addr = (void __user *) addr;
> +
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> + fill_sig_info_pkey(code, &info, addr);
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
>   force_sig_info(signr, &info, current);
>  }

Eric
--
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: [dm-devel] [PATCH v5 12/19] dm: move dm-verity to generic async completion

2017-08-19 Thread Mikulas Patocka



On Mon, 14 Aug 2017, Gilad Ben-Yossef wrote:

> dm-verity is starting async. crypto ops and waiting for them to complete.
> Move it over to generic code doing the same.
> 
> This also fixes a possible data coruption bug created by the
> use of wait_for_completion_interruptible() without dealing
> correctly with an interrupt aborting the wait prior to the
> async op finishing.

What is the exact problem there? The interruptible sleep is called from a 
workqueue and workqueues have all signals blocked. Are signals unblocked 
for some reason there?

Should there be another patch for stable kernels that fixes the 
interruptible sleep?

Mikulas

> Signed-off-by: Gilad Ben-Yossef 
> ---
>  drivers/md/dm-verity-target.c | 81 
> +++
>  drivers/md/dm-verity.h|  5 ---
>  2 files changed, 20 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> index 79f18d4..8df08a8 100644
> --- a/drivers/md/dm-verity-target.c
> +++ b/drivers/md/dm-verity-target.c
> @@ -92,74 +92,33 @@ static sector_t verity_position_at_level(struct dm_verity 
> *v, sector_t block,
>   return block >> (level * v->hash_per_block_bits);
>  }
>  
> -/*
> - * Callback function for asynchrnous crypto API completion notification
> - */
> -static void verity_op_done(struct crypto_async_request *base, int err)
> -{
> - struct verity_result *res = (struct verity_result *)base->data;
> -
> - if (err == -EINPROGRESS)
> - return;
> -
> - res->err = err;
> - complete(&res->completion);
> -}
> -
> -/*
> - * Wait for async crypto API callback
> - */
> -static inline int verity_complete_op(struct verity_result *res, int ret)
> -{
> - switch (ret) {
> - case 0:
> - break;
> -
> - case -EINPROGRESS:
> - case -EBUSY:
> - ret = wait_for_completion_interruptible(&res->completion);
> - if (!ret)
> - ret = res->err;
> - reinit_completion(&res->completion);
> - break;
> -
> - default:
> - DMERR("verity_wait_hash: crypto op submission failed: %d", ret);
> - }
> -
> - if (unlikely(ret < 0))
> - DMERR("verity_wait_hash: crypto op failed: %d", ret);
> -
> - return ret;
> -}
> -
>  static int verity_hash_update(struct dm_verity *v, struct ahash_request *req,
>   const u8 *data, size_t len,
> - struct verity_result *res)
> + struct crypto_wait *wait)
>  {
>   struct scatterlist sg;
>  
>   sg_init_one(&sg, data, len);
>   ahash_request_set_crypt(req, &sg, NULL, len);
>  
> - return verity_complete_op(res, crypto_ahash_update(req));
> + return crypto_wait_req(crypto_ahash_update(req), wait);
>  }
>  
>  /*
>   * Wrapper for crypto_ahash_init, which handles verity salting.
>   */
>  static int verity_hash_init(struct dm_verity *v, struct ahash_request *req,
> - struct verity_result *res)
> + struct crypto_wait *wait)
>  {
>   int r;
>  
>   ahash_request_set_tfm(req, v->tfm);
>   ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP |
>   CRYPTO_TFM_REQ_MAY_BACKLOG,
> - verity_op_done, (void *)res);
> - init_completion(&res->completion);
> + crypto_req_done, (void *)wait);
> + crypto_init_wait(wait);
>  
> - r = verity_complete_op(res, crypto_ahash_init(req));
> + r = crypto_wait_req(crypto_ahash_init(req), wait);
>  
>   if (unlikely(r < 0)) {
>   DMERR("crypto_ahash_init failed: %d", r);
> @@ -167,18 +126,18 @@ static int verity_hash_init(struct dm_verity *v, struct 
> ahash_request *req,
>   }
>  
>   if (likely(v->salt_size && (v->version >= 1)))
> - r = verity_hash_update(v, req, v->salt, v->salt_size, res);
> + r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
>  
>   return r;
>  }
>  
>  static int verity_hash_final(struct dm_verity *v, struct ahash_request *req,
> -  u8 *digest, struct verity_result *res)
> +  u8 *digest, struct crypto_wait *wait)
>  {
>   int r;
>  
>   if (unlikely(v->salt_size && (!v->version))) {
> - r = verity_hash_update(v, req, v->salt, v->salt_size, res);
> + r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
>  
>   if (r < 0) {
>   DMERR("verity_hash_final failed updating salt: %d", r);
> @@ -187,7 +146,7 @@ static int verity_hash_final(struct dm_verity *v, struct 
> ahash_request *req,
>   }
>  
>   ahash_request_set_crypt(req, NULL, digest, 0);
> - r = verity_complete_op(res, crypto_ahash_final(req));
> + r = crypto_wait_req(crypto_ahash_final(req), wait);
>  out:
>   return r;

Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

2017-08-19 Thread Theodore Ts'o

On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> On Aug 18, 2017, at 1:47 PM, Eric Biggers  wrote:
> > +Key hierarchy
> > +=
> > +
> > +Master Keys
> > +---
> > +
> > +Userspace should generate master keys either using a cryptographically
> > +secure random number generator, e.g. by reading from ``/dev/urandom``
> > +or calling getrandom(), or by using a KDF (Key Derivation Function).
> > +Note that whenever a KDF is used to "stretch" a lower-entropy secret
> > +such as a passphrase, it is critical that a KDF designed for this
> > +purpose be used, such as scrypt, PBKDF2, or Argon2.
> 
> One minor suggestion - when generating a master key for a filesystem,
> I'd think it is preferable to use /dev/random instead of /dev/urandom
> to ensure there is enough entropy.

I would just say "use getrandom" and be done with it.  More
importantly, we probably just want to direct users to use either
https://github.com/google/fscrypt or Android key management system at
the beginning of the file.

If the readers of this documentation file need to be told how to get
good random number generators, they're very likely to make any number
of other basic security mistakes.  If people don't think the fscrypt
user program isn't user-friendly or flexible enough to encompass their
use case, it's probably better to encourage them to submit
enhancements to an existing open source key management system such as
google/fscrypt.  If we minimize the number of userspace
implementations, the easier it will be to make sure they are
appropriately audited for security issues...

- Ted

--
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] dt-bindings: add compatible string for Allwinner V3s SoC

2017-08-19 Thread Icenowy Zheng

The compatible string for Allwinner V3s SoC used to be missing.

Add it to the binding document.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index d2c46449b4eb..f35c6ada5a65 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
   nextthing,gr8
-- 
2.13.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

[PATCH 2/2] ARM: sunxi: add support for R40 SoC

2017-08-19 Thread Icenowy Zheng

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 Documentation/arm/sunxi/README  | 6 ++
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index d7b1f016bd62..4fa836782e46 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -75,6 +75,12 @@ SunXi family
 + Datasheet
   http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
 
+  - Allwinner R40 (sun8i)
++ Datasheet
+  https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
++ User Manual
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
+
 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner-sun8i-r40
   allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..311e6c4fc4f4 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-v3s",
+   "allwinner,sun8i-r40",
NULL,
 };
 
-- 
2.13.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: [PATCH v3 07/10] dt-bindings: add compatible string for Allwinner R40 CCU

[RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[RFC PATCH 1/3] kbuild: generate *.hash.c during build

[PATCH RFC] media: open.rst: document devnode-centric and mc-centric types

Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[PATCH 0/2] docs: fix security/keys paths and section headings

[PATCH 1/2] docs: Standardise capitalisation of section headers in core.rst

[PATCH 2/2] docs: Fix paths in security/keys

Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

Re: [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation

Re: [dm-devel] [PATCH v5 12/19] dm: move dm-verity to generic async completion

Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[PATCH 1/2] dt-bindings: add compatible string for Allwinner V3s SoC

[PATCH 2/2] ARM: sunxi: add support for R40 SoC

16 matches

Site Navigation

Mail list logo

Footer information