Re: [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

[Anurup M]

On Thursday 03 November 2016 11:56 PM, Krzysztof Kozlowski wrote:

On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:

1) Device tree bindings for Hisilicon SoC PMU.
2) Add example for Hisilicon L3 cache, MN and DDRC PMU.

Get rid of this weird indentation in all patches.

Thanks. I shall remove the TAB from the commit message in all patches.



Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
---
  .../devicetree/bindings/arm/hisilicon/pmu.txt  | 127 +
  1 file changed, 127 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
new file mode 100644
index 000..e7b35e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
@@ -0,0 +1,127 @@
+Hisilicon SoC hip05/06/07 ARMv8 PMU
+===
+
+The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
+system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR
+comtroller. These PMU devices are independent and have hardware logic to
+gather statistics and performance information.
+
+HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die
+is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
+e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
+
+The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.
+For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
+the parent node will be the djtag node of the corresponding CPU die(SCCL).
+
+For uncore PMU devices there are some common required properties as detailed
+below.
+
+Required properties:
+   - compatible : This field contain two values. The first value is
+   always "hisilicon" and second value is the Module type as shown
+   in below examples:

Over-complicated sentence. Just:

- compatible : One of:
"hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
device (Version 1)
...
...

Thanks. Shall refine it in next version.

BTW, No need of CC-ing me. I am not a maintainer of relevant subsystems.

Sure.

Thanks,
Anurup

Best regards,
Krzysztof


--
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 3/3] tpm: move documentation under Documentation/security

[Jarkko Sakkinen]

In order too make Documentation root directory cleaner move the tpm
directory under Documentation/security.

Signed-off-by: Jarkko Sakkinen 
---
 Documentation/index.rst | 2 +-
 Documentation/security/index.rst| 7 +++
 Documentation/{ => security}/tpm/index.rst  | 0
 Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst | 0
 Documentation/{ => security}/tpm/xen-tpmfront.txt   | 0
 5 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/security/index.rst
 rename Documentation/{ => security}/tpm/index.rst (100%)
 rename Documentation/{ => security}/tpm/tpm_vtpm_proxy.rst (100%)
 rename Documentation/{ => security}/tpm/xen-tpmfront.txt (100%)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 0058b65..b4c3034 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -19,7 +19,7 @@ Contents:
media/dvb-drivers/index
media/v4l-drivers/index
gpu/index
-   tpm/index
+   security/index
 
 Indices and tables
 ==
diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
new file mode 100644
index 000..9bae6bb
--- /dev/null
+++ b/Documentation/security/index.rst
@@ -0,0 +1,7 @@
+==
+Security documentation
+==
+
+.. toctree::
+
+   tpm/index
diff --git a/Documentation/tpm/index.rst b/Documentation/security/tpm/index.rst
similarity index 100%
rename from Documentation/tpm/index.rst
rename to Documentation/security/tpm/index.rst
diff --git a/Documentation/tpm/tpm_vtpm_proxy.rst 
b/Documentation/security/tpm/tpm_vtpm_proxy.rst
similarity index 100%
rename from Documentation/tpm/tpm_vtpm_proxy.rst
rename to Documentation/security/tpm/tpm_vtpm_proxy.rst
diff --git a/Documentation/tpm/xen-tpmfront.txt 
b/Documentation/security/tpm/xen-tpmfront.txt
similarity index 100%
rename from Documentation/tpm/xen-tpmfront.txt
rename to Documentation/security/tpm/xen-tpmfront.txt
-- 
2.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

[PATCH 2/3] tpm: transition tpm_vtpm_proxy documentation to the Sphinx

[Jarkko Sakkinen]

Transitioned the tpm_vtpm_proxy documentation to the Sphinx
infrastructure and removed parts from the documentation that are easier
to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
to be compatible with this approach and wrote associated documentation
comments.

Signed-off-by: Jarkko Sakkinen 
---
 Documentation/index.rst|  1 +
 Documentation/tpm/index.rst|  7 +++
 .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 55 +++---
 3 files changed, 25 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/tpm/index.rst
 rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} (53%)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index e0fc729..0058b65 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -19,6 +19,7 @@ Contents:
media/dvb-drivers/index
media/v4l-drivers/index
gpu/index
+   tpm/index
 
 Indices and tables
 ==
diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
new file mode 100644
index 000..af77a7b
--- /dev/null
+++ b/Documentation/tpm/index.rst
@@ -0,0 +1,7 @@
+=
+Trusted Platform Module documentation
+=
+
+.. toctree::
+
+   tpm_vtpm_proxy
diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt 
b/Documentation/tpm/tpm_vtpm_proxy.rst
similarity index 53%
rename from Documentation/tpm/tpm_vtpm_proxy.txt
rename to Documentation/tpm/tpm_vtpm_proxy.rst
index 30d1902..ea08e76 100644
--- a/Documentation/tpm/tpm_vtpm_proxy.txt
+++ b/Documentation/tpm/tpm_vtpm_proxy.rst
@@ -1,71 +1,50 @@
+=
 Virtual TPM Proxy Driver for Linux Containers
+=
 
-Authors: Stefan Berger (IBM)
+| Authors:
+| Stefan Berger 
 
 This document describes the virtual Trusted Platform Module (vTPM)
 proxy device driver for Linux containers.
 
-INTRODUCTION
-
+Introduction
+
 
 The goal of this work is to provide TPM functionality to each Linux
 container. This allows programs to interact with a TPM in a container
 the same way they interact with a TPM on the physical system. Each
 container gets its own unique, emulated, software TPM.
 
-
-DESIGN
---
+Design
+==
 
 To make an emulated software TPM available to each container, the container
 management stack needs to create a device pair consisting of a client TPM
-character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
+character device ``/dev/tpmX`` (with X=0,1,2...) and a 'server side' file
 descriptor. The former is moved into the container by creating a character
 device with the appropriate major and minor numbers while the file descriptor
 is passed to the TPM emulator. Software inside the container can then send
 TPM commands using the character device and the emulator will receive the
 commands via the file descriptor and use it for sending back responses.
 
-To support this, the virtual TPM proxy driver provides a device /dev/vtpmx
+To support this, the virtual TPM proxy driver provides a device ``/dev/vtpmx``
 that is used to create device pairs using an ioctl. The ioctl takes as
 an input flags for configuring the device. The flags  for example indicate
 whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
 The result of the ioctl are the file descriptor for the 'server side'
 as well as the major and minor numbers of the character device that was 
created.
-Besides that the number of the TPM character device is return. If for
-example /dev/tpm10 was created, the number (dev_num) 10 is returned.
-
-The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
-
-struct vtpm_proxy_new_dev {
-   __u32 flags; /* input */
-   __u32 tpm_num;   /* output */
-   __u32 fd;/* output */
-   __u32 major; /* output */
-   __u32 minor; /* output */
-};
-
-Note that if unsupported flags are passed to the device driver, the ioctl will
-fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl is
-called on the device driver, the ioctl will fail and errno will be set to
-ENOTTY.
-
-See /usr/include/linux/vtpm_proxy.h for definitions related to the public 
interface
-of this vTPM device driver.
+Besides that the number of the TPM character device is returned. If for
+example ``/dev/tpm10`` was created, the number (``dev_num``) 10 is returned.
 
 Once the device has been created, the driver will immediately try to talk
 to the TPM. All commands from the driver can be read from the file descriptor
 returned by the ioctl. The commands should be responded to immediately.
 
-Depending on the version of TPM the following commands will be sent by the
-driver:
+UAPI
+
 
-- TPM 1.2:
-  - the driver will send a TPM_Startup command to 

Re: [PATCH] proc: Report no_new_privs state

[Jann Horn]

On Thu, Nov 03, 2016 at 02:40:41PM -0700, Kees Cook wrote:
> Similar to being able to examine if a process has been correctly confined
> with seccomp, the state of no_new_privs is equally interesting, so this
> adds it to /proc/$pid/status.
> 
> Signed-off-by: Kees Cook 

(Note: The proc.5 manpage also lists all the entries of the "status" file,
so it should also be updated.)

Reviewed-by: Jann Horn 

> ---
>  Documentation/filesystems/proc.txt | 2 ++
>  fs/proc/array.c| 5 +++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index 74329fd0add2..c03f2f91c6ab 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -191,6 +191,7 @@ read the file /proc/PID/status:
>CapPrm: 
>CapEff: 
>CapBnd: 
> +  NoNewPrivs: 0
>Seccomp:0
>voluntary_ctxt_switches:0
>nonvoluntary_ctxt_switches: 1
> @@ -262,6 +263,7 @@ Table 1-2: Contents of the status files (as of 4.1)
>   CapPrm  bitmap of permitted capabilities
>   CapEff  bitmap of effective capabilities
>   CapBnd  bitmap of capabilities bounding set
> + NoNewPrivs  no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, 
> ...)
>   Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
>   Cpus_allowedmask of CPUs on which this process may run
>   Cpus_allowed_list   Same as previous, but in "list format"
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 81818adb8e9e..082676ab4878 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -342,10 +342,11 @@ static inline void task_cap(struct seq_file *m, struct 
> task_struct *p)
>  
>  static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
>  {
> + seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));
>  #ifdef CONFIG_SECCOMP
> - seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode);
> - seq_putc(m, '\n');
> + seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);
>  #endif
> + seq_putc(m, '\n');
>  }
>  
>  static inline void task_context_switch_counts(struct seq_file *m,
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Nexus Security


signature.asc
Description: Digital signature

[PATCH] proc: Report no_new_privs state

[Kees Cook]

Similar to being able to examine if a process has been correctly confined
with seccomp, the state of no_new_privs is equally interesting, so this
adds it to /proc/$pid/status.

Signed-off-by: Kees Cook 
---
 Documentation/filesystems/proc.txt | 2 ++
 fs/proc/array.c| 5 +++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index 74329fd0add2..c03f2f91c6ab 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -191,6 +191,7 @@ read the file /proc/PID/status:
   CapPrm: 
   CapEff: 
   CapBnd: 
+  NoNewPrivs: 0
   Seccomp:0
   voluntary_ctxt_switches:0
   nonvoluntary_ctxt_switches: 1
@@ -262,6 +263,7 @@ Table 1-2: Contents of the status files (as of 4.1)
  CapPrm  bitmap of permitted capabilities
  CapEff  bitmap of effective capabilities
  CapBnd  bitmap of capabilities bounding set
+ NoNewPrivs  no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
  Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
  Cpus_allowedmask of CPUs on which this process may run
  Cpus_allowed_list   Same as previous, but in "list format"
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 81818adb8e9e..082676ab4878 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -342,10 +342,11 @@ static inline void task_cap(struct seq_file *m, struct 
task_struct *p)
 
 static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
 {
+   seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));
 #ifdef CONFIG_SECCOMP
-   seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode);
-   seq_putc(m, '\n');
+   seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);
 #endif
+   seq_putc(m, '\n');
 }
 
 static inline void task_context_switch_counts(struct seq_file *m,
-- 
2.7.4


-- 
Kees Cook
Nexus 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: [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

[Krzysztof Kozlowski]

On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>   1) Device tree bindings for Hisilicon SoC PMU.
>   2) Add example for Hisilicon L3 cache, MN and DDRC PMU.

Get rid of this weird indentation in all patches.


> 
> Signed-off-by: Anurup M 
> Signed-off-by: Shaokun Zhang 
> ---
>  .../devicetree/bindings/arm/hisilicon/pmu.txt  | 127 
> +
>  1 file changed, 127 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 000..e7b35e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,127 @@
> +Hisilicon SoC hip05/06/07 ARMv8 PMU
> +===
> +
> +The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
> +system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR
> +comtroller. These PMU devices are independent and have hardware logic to
> +gather statistics and performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
> +e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU 
> device.
> +
> +The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die(SCCL).
> +
> +For uncore PMU devices there are some common required properties as detailed
> +below.
> +
> +Required properties:
> + - compatible : This field contain two values. The first value is
> + always "hisilicon" and second value is the Module type as shown
> + in below examples:

Over-complicated sentence. Just:

- compatible : One of:
"hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
device (Version 1)
...
...

BTW, No need of CC-ing me. I am not a maintainer of relevant subsystems.

Best regards,
Krzysztof
--
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/sphinx: set literal block highlight language to none

[Jani Nikula]

On Thu, 03 Nov 2016, Jonathan Corbet  wrote:
> On Thu,  3 Nov 2016 11:07:33 +0200
> Jani Nikula  wrote:
>
>> Set the default highlight language to "none", i.e. do not try to guess
>> the language and do automatic syntax highlighting on literal blocks.
>
> As you might guess, I'm totally in favor of this; I think it's the right
> choice.
>
> The kernel summit and such have me under a pile of docs (and other)
> email; it may be next week before I'm properly caught up, sorry.

I figured this would be the case, so I piled them all up [1]. I promise
to not send you more for a while. ;)

BR,
Jani.


[1] http://lkml.kernel.org/r/87k2ckj0nd@intel.com


-- 
Jani Nikula, Intel Open Source Technology Center
--
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/sphinx: set literal block highlight language to none

[Jonathan Corbet]

On Thu,  3 Nov 2016 11:07:33 +0200
Jani Nikula  wrote:

> Set the default highlight language to "none", i.e. do not try to guess
> the language and do automatic syntax highlighting on literal blocks.

As you might guess, I'm totally in favor of this; I think it's the right
choice.

The kernel summit and such have me under a pile of docs (and other)
email; it may be next week before I'm properly caught up, sorry.

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] tpm: transition tpm_vtpm_proxy documentation to the Sphinx

[Jarkko Sakkinen]

On Thu, Nov 03, 2016 at 10:21:36AM +0200, Jani Nikula wrote:
> On Wed, 02 Nov 2016, Jarkko Sakkinen  wrote:
> > Transitioned the tpm_vtpm_proxy documentation to the Sphinx
> > infrastructure and removed parts from the documentation that are easier
> > to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
> > to be compatible with this approach and wrote associated documentation
> > comments.
> >
> > Signed-off-by: Jarkko Sakkinen 
> > ---
> >  Documentation/index.rst|  1 +
> >  Documentation/tpm/index.rst|  7 +++
> >  .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 53 +---
> >  drivers/char/tpm/tpm_vtpm_proxy.c  | 72 
> > ++
> >  include/uapi/linux/vtpm_proxy.h| 23 +--
> 
> I'm not sure it's a good idea to combine this much code change with the
> documentation change. Perhaps split up, at least the function
> movement/abstraction bits?

Sure. I scraped this up quickly to get some feedback whether I'm doing
this right at all :-)

> 
> >  5 files changed, 89 insertions(+), 67 deletions(-)
> >  create mode 100644 Documentation/tpm/index.rst
> >  rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} (56%)
> >
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index e0fc729..0058b65 100644
> > --- a/Documentation/index.rst
> > +++ b/Documentation/index.rst
> > @@ -19,6 +19,7 @@ Contents:
> > media/dvb-drivers/index
> > media/v4l-drivers/index
> > gpu/index
> > +   tpm/index
> >  
> >  Indices and tables
> >  ==
> > diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
> > new file mode 100644
> > index 000..316cdbb
> > --- /dev/null
> > +++ b/Documentation/tpm/index.rst
> > @@ -0,0 +1,7 @@
> > +=
> > +TPM documentation
> > +=
> 
> This will pop up at the top level of the documentation. I'm not saying
> that's necessarily wrong per se, but IMO you should spell out Trusted
> Platform Module here instead of just using the acronym.
> 
> (Sure we have "GPU" at the top level, but I think that's a better known
> acronym. And we might change that to "Graphics" anyway.)

Got you. I'll change it to Trusted Platform Module.

> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

/Jarkko
--
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: [tpmdd-devel] [PATCH] tpm: transition tpm_vtpm_proxy documentation to the Sphinx

[Jarkko Sakkinen]

Thanks for the comments. I'll revise this.

/Jarkko

On Wed, Nov 02, 2016 at 03:26:00PM -0700, Stefan Berger wrote:
>Jarkko Sakkinen  wrote on 11/02/2016
>12:01:56 PM:
> 
>>
>> Transitioned the tpm_vtpm_proxy documentation to the Sphinx
>> infrastructure and removed parts from the documentation that are easier
>> to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
>> to be compatible with this approach and wrote associated documentation
>> comments.
>>
>> Signed-off-by: Jarkko Sakkinen 
>> ---
>>  Documentation/index.rst|  1 +
>>  Documentation/tpm/index.rst|  7 +++
>>  .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 53
>+---
>>  drivers/char/tpm/tpm_vtpm_proxy.c  | 72 +++
>> +++
>>  include/uapi/linux/vtpm_proxy.h| 23 +--
>>  5 files changed, 89 insertions(+), 67 deletions(-)
>>  create mode 100644 Documentation/tpm/index.rst
>>  rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst}
>(56%)
>>
>> diff --git a/Documentation/index.rst b/Documentation/index.rst
>> index e0fc729..0058b65 100644
>> --- a/Documentation/index.rst
>> +++ b/Documentation/index.rst
>> @@ -19,6 +19,7 @@ Contents:
>> media/dvb-drivers/index
>> media/v4l-drivers/index
>> gpu/index
>> +   tpm/index
>>  
>>  Indices and tables
>>  ==
>> diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
>> new file mode 100644
>> index 000..316cdbb
>> --- /dev/null
>> +++ b/Documentation/tpm/index.rst
>> @@ -0,0 +1,7 @@
>> +=
>> +TPM documentation
>> +=
>> +
>> +.. toctree::
>> +
>> +   tpm_vtpm_proxy
>> diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt b/Documentation/
>> tpm/tpm_vtpm_proxy.rst
>> similarity index 56%
>> rename from Documentation/tpm/tpm_vtpm_proxy.txt
>> rename to Documentation/tpm/tpm_vtpm_proxy.rst
>> index 30d1902..f991aff 100644
>> --- a/Documentation/tpm/tpm_vtpm_proxy.txt
>> +++ b/Documentation/tpm/tpm_vtpm_proxy.rst
>[...]
>>  To make an emulated software TPM available to each container, the
>container
>>  management stack needs to create a device pair consisting of a client
>TPM
>> -character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
>> +character device ``/dev/tpmX`` (with X=0,1,2...) and a 'server side'
>file
>>  descriptor. The former is moved into the container by creating a
>character
>>  device with the appropriate major and minor numbers while the file
>descriptor
>>  is passed to the TPM emulator. Software inside the container can then
>send
>>  TPM commands using the character device and the emulator will receive
>the
>>  commands via the file descriptor and use it for sending back responses.
>>  
>> -To support this, the virtual TPM proxy driver provides a device
>/dev/vtpmx
>> +To support this, the virtual TPM proxy driver provides a device ``/
>> dev/vtpmx``
>>  that is used to create device pairs using an ioctl. The ioctl takes as
>>  an input flags for configuring the device. The flags  for example
>indicate
>>  whether TPM 1.2 or TPM 2 functionality is supported by the TPM
>emulator.
>>  The result of the ioctl are the file descriptor for the 'server side'
>>  as well as the major and minor numbers of the character device that
>> was created.
>>  Besides that the number of the TPM character device is return. If for
> 
>Existing typo: return -> returned.
>> -example /dev/tpm10 was created, the number (dev_num) 10 is returned.
>> -
>> -The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
>> -
>> -struct vtpm_proxy_new_dev {
>> -   __u32 flags; /* input */
>> -   __u32 tpm_num;   /* output */
>> -   __u32 fd;/* output */
>> -   __u32 major; /* output */
>> -   __u32 minor; /* output */
>> -};
>> -
>> -Note that if unsupported flags are passed to the device driver,
>theioctl will
>> -fail and errno will be set to EOPNOTSUPP. Similarly, if an
>> unsupported ioctl is
>> -called on the device driver, the ioctl will fail and errno will be set
>to
>> -ENOTTY.
> 
>Users would now have to look into the spec for this.
> 
>> -
>> -See /usr/include/linux/vtpm_proxy.h for definitions related to the
>> public interface
>> -of this vTPM device driver.
>> +example ``/dev/tpm10`` was created, the number (``dev_num``) 10 is
>returned.
>>  
>>  Once the device has been created, the driver will 

[PULL] sphinx fixes for docs-next

[Jani Nikula]

Hi Jon, I shoved all of my recent documentation fixes into a branch to
hopefully make it easier for you to track them, whether you pull this in
directly or not. I added Reviewed-by/Tested-by tags from the list; the
last ones haven't received any review yet.

It's not all about pdf, but with these and Mauro's patches [1] make
pdfdocs works for me.

BR,
Jani.


[1] cover.1478040090.git.mchehab@osg.samsung.com">http://mid.mail-archive.com/cover.1478040090.git.mchehab@osg.samsung.com


The following changes since commit 9d2cccdd6c226181c42a7bb0c5ede1583687b618:

  Merge branch 'doc-tweaks' into docs-next (2016-10-27 17:47:58 -0600)

are available in the git repository at:

  git://people.freedesktop.org/~jani/drm sphinx-fixes-for-docs-next

for you to fetch changes up to 07c7e30c1885393b07efcaf62d51b219755b6bf5:

  Documentation/admin-guide: split the device list to a separate file 
(2016-11-03 12:39:23 +0200)


Jani Nikula (11):
  Documentation/sphinx: let the user specify PDFLATEX and LATEXOPTS
  Documentation/sphinx: make it possible to build latexdocs without pdflatex
  Documentation/sphinx: remove superfluous trailing ; from quiet_cmd_sphinx
  Documentation/sphinx: change pdflatex interaction mode to batchmode
  Documentation/sphinx: include admin-guide in the latex/pdf build
  Documentation/sphinx: set literal block highlight language to none
  Documentation/admin-guide: use code-block with proper language
  Documentation/dev-tools: use code-block with proper language
  Documentation/gpu: use code-block with proper language
  Documentation/admin-guide: split the kernel parameter list to a separate 
file
  Documentation/admin-guide: split the device list to a separate file

Markus Heiser (1):
  Documentation/sphinx: fix make SPHINXDIRS="dirs" pdfdocs for more than 
one dir

 Documentation/Makefile.sphinx   |   19 +-
 Documentation/admin-guide/devices.rst   | 3086 +---
 Documentation/admin-guide/devices.txt   | 3081 
 Documentation/admin-guide/java.rst  |   52 +-
 Documentation/admin-guide/kernel-parameters.rst | 4374 +--
 Documentation/admin-guide/kernel-parameters.txt | 4367 ++
 Documentation/admin-guide/mono.rst  |4 +-
 Documentation/admin-guide/ramoops.rst   |4 +-
 Documentation/conf.py   |4 +-
 Documentation/dev-tools/gcov.rst|8 +-
 Documentation/dev-tools/kcov.rst|4 +-
 Documentation/gpu/drm-kms.rst   |2 +-
 Documentation/gpu/drm-mm.rst|2 +-
 13 files changed, 7513 insertions(+), 7494 deletions(-)
 create mode 100644 Documentation/admin-guide/devices.txt
 create mode 100644 Documentation/admin-guide/kernel-parameters.txt



-- 
Jani Nikula, Intel Open Source Technology Center
--
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 RFC 0/4] Fix PDF build errors

[Jani Nikula]

On Thu, 03 Nov 2016, Jani Nikula  wrote:
> These two (on top of Mauro's patches and my patch to include the
> admin-guide in the pdfdocs build) fix the pdf build for me. Apparently
> having the lng literal blocks in separate files changes sphinx
> processing in a way favorable to the latex output.
>
> I'm not overly excited about this, but I think this is a good
> intermediate solution to get pdf build working, and if we get 0day to
> crunch pdfbuild too, we'll have a better chance of keeping it working
> if/when we change stuff again. Fingers crossed.

The major change in the resulting pdf seems to be that with the include
directive the literal blocks are not wrapped in rectangles. Small price
to pay.

BR,
Jani.


PS. Despite all the bumps in the road and complaints about Sphinx & pdf,
I think the pdf output is generally pretty nice. I never managed to
finish the pdf build with DocBook, so this is infinitely better than the
old toolchain for me. ;) Thanks everyone for making it work!


-- 
Jani Nikula, Intel Open Source Technology Center
--
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 RFC 0/4] Fix PDF build errors

[Jani Nikula]

These two (on top of Mauro's patches and my patch to include the
admin-guide in the pdfdocs build) fix the pdf build for me. Apparently
having the lng literal blocks in separate files changes sphinx
processing in a way favorable to the latex output.

I'm not overly excited about this, but I think this is a good
intermediate solution to get pdf build working, and if we get 0day to
crunch pdfbuild too, we'll have a better chance of keeping it working
if/when we change stuff again. Fingers crossed.

BR,
Jani.


--
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/3] Documentation/dev-tools: use code-block with proper language

[Jani Nikula]

Now that we don't have automatic syntax highlighting, use the code-block
directive with the explicitly selected language, where appropriate.

Signed-off-by: Jani Nikula 
---
 Documentation/dev-tools/gcov.rst | 8 ++--
 Documentation/dev-tools/kcov.rst | 4 +++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst
index 19eedfea8800..69a7d90c320a 100644
--- a/Documentation/dev-tools/gcov.rst
+++ b/Documentation/dev-tools/gcov.rst
@@ -201,7 +201,9 @@ Appendix A: gather_on_build.sh
 --
 
 Sample script to gather coverage meta files on the build machine
-(see 6a)::
+(see 6a):
+
+.. code-block:: sh
 
 #!/bin/bash
 
@@ -232,7 +234,9 @@ Appendix B: gather_on_test.sh
 -
 
 Sample script to gather coverage data files on the test machine
-(see 6b)::
+(see 6b):
+
+.. code-block:: sh
 
 #!/bin/bash -e
 
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index aca0e27ca197..2c41b713841f 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -24,7 +24,9 @@ Profiling data will only become accessible once debugfs has 
been mounted::
 
 mount -t debugfs none /sys/kernel/debug
 
-The following program demonstrates kcov usage from within a test program::
+The following program demonstrates kcov usage from within a test program:
+
+.. code-block:: c
 
 #include 
 #include 
-- 
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

[PATCH 1/3] Documentation/admin-guide: use code-block with proper language

[Jani Nikula]

Now that we don't have automatic syntax highlighting, use the code-block
directive with the explicitly selected language, where appropriate.

Signed-off-by: Jani Nikula 
---
 Documentation/admin-guide/java.rst| 52 +++
 Documentation/admin-guide/mono.rst|  4 ++-
 Documentation/admin-guide/ramoops.rst |  4 ++-
 3 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/Documentation/admin-guide/java.rst 
b/Documentation/admin-guide/java.rst
index a0de7c1a1ed9..8744e272e6f8 100644
--- a/Documentation/admin-guide/java.rst
+++ b/Documentation/admin-guide/java.rst
@@ -66,7 +66,9 @@ other program after you have done the following:
Both the javawrapper shellscript and the javaclassname program
were supplied by Colin J. Watson .
 
-Javawrapper shell script::
+Javawrapper shell script:
+
+.. code-block:: sh
 
   #!/bin/bash
   # /usr/local/bin/javawrapper - the wrapper for binfmt_misc/java
@@ -155,29 +157,31 @@ Javawrapper shell script::
   shift
   /usr/bin/java $FQCLASS "$@"
 
-javaclassname.c::
+javaclassname.c:
+
+.. code-block:: c
 
   /* javaclassname.c
- *
- * Extracts the class name from a Java class file; intended for use in a Java
- * wrapper of the type supported by the binfmt_misc option in the Linux kernel.
- *
- * Copyright (C) 1999 Colin J. Watson .
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
+   *
+   * Extracts the class name from a Java class file; intended for use in a Java
+   * wrapper of the type supported by the binfmt_misc option in the Linux 
kernel.
+   *
+   * Copyright (C) 1999 Colin J. Watson .
+   *
+   * 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.
+   *
+   * This program is distributed in the hope that it will be useful,
+   * but WITHOUT ANY WARRANTY; without even the implied warranty of
+   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   * GNU General Public License for more details.
+   *
+   * You should have received a copy of the GNU General Public License
+   * along with this program; if not, write to the Free Software
+   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+   */
 
   #include 
   #include 
@@ -378,7 +382,9 @@ added to your CLASSPATH during execution.
 
 
 To test your new setup, enter in the following simple Java app, and name
-it "HelloWorld.java"::
+it "HelloWorld.java":
+
+.. code-block:: java
 
class HelloWorld {
public static void main(String args[]) {
diff --git a/Documentation/admin-guide/mono.rst 
b/Documentation/admin-guide/mono.rst
index 9a9744ca0cf3..cdddc099af64 100644
--- a/Documentation/admin-guide/mono.rst
+++ b/Documentation/admin-guide/mono.rst
@@ -31,7 +31,9 @@ other program after you have done the following:
more about the configuration process.
 
 3) Add the following entries to ``/etc/rc.local`` or similar script
-   to be run at system startup::
+   to be run at system startup:
+
+   .. code-block:: sh
 
 # Insert BINFMT_MISC module into the kernel
 if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
diff --git a/Documentation/admin-guide/ramoops.rst 
b/Documentation/admin-guide/ramoops.rst
index fe95c027e37c..4efd7ce77565 100644
--- a/Documentation/admin-guide/ramoops.rst
+++ b/Documentation/admin-guide/ramoops.rst
@@ -78,7 +78,9 @@ Setting the ramoops parameters can be done in several 
different manners:
};
 
  C. Use a platform device and set the platform data. The parameters can then
- be set through that platform data. An example of doing that is::
+ be set through that platform data. An example of doing that is:
+
+ .. code-block:: c
 
   #include 
   [...]
-- 
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

[PATCH 3/3] Documentation/gpu: use code-block with proper language

[Jani Nikula]

Now that we don't have automatic syntax highlighting, use the code-block
directive with the explicitly selected language, where appropriate.

Signed-off-by: Jani Nikula 
---
 Documentation/gpu/drm-kms.rst | 2 +-
 Documentation/gpu/drm-mm.rst  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 53b872c105d2..38af5d1cc59f 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -215,7 +215,7 @@ Connectors state change detection must be cleanup up with a 
call to
 Output discovery and initialization example
 ---
 
-::
+.. code-block:: c
 
 void intel_crt_init(struct drm_device *dev)
 {
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index bca808535dfd..cb5daffcd6be 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -45,7 +45,7 @@ the radeon_ttm.c file for an example of usage.
 
 The ttm_global_reference structure is made up of several fields:
 
-::
+.. code-block:: c
 
   struct ttm_global_reference {
   enum ttm_global_types global_type;
-- 
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 RFC 0/4] Fix PDF build errors

[Jani Nikula]

On Wed, 02 Nov 2016, Markus Heiser  wrote:
> Am 02.11.2016 um 17:47 schrieb Mauro Carvalho Chehab :
>> I'm staring to think that we should just redefine the default for ::
>> to be "none", and use the "C" handling **only** when explicitly
>> requested.
>> 
>> I remember that Jon did such suggestion sometime ago.
>
> *shrug* ... I think about kernel-doc comments in the sources,
> mostly you will have small examples and won't those verbose 
> ".. code-block::" markup / using "::" keeps the comment compact.

I sent the patch [1] to default to "none". It's never wrong, not even
for code. But getting the highlighting wrong, OTOH, is pretty bad. We
have that.

And really, if you look at the kernel-doc comments and the rst
documentation, we don't have all that many literal blocks that would
benefit from syntax highlighting in the first place.

BR,
Jani.


[1] 
http://lkml.kernel.org/r/1478164053-4562-1-git-send-email-jani.nik...@intel.com

-- 
Jani Nikula, Intel Open Source Technology Center
--
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] Documentation/sphinx: set literal block highlight language to none

[Jani Nikula]

Set the default highlight language to "none", i.e. do not try to guess
the language and do automatic syntax highlighting on literal blocks.

Eyeballing around the generated documentation, we don't seem to actually
have a lot of literal blocks that would benefit from syntax
highlighting. The C code blocks we do have are typically very short, and
most of the literal blocks are things that shouldn't be highlighted (or,
do not have a pygments lexer). This seems to be true for literal blocks
both in the rst source files and in source code comments.

Not highlighting code is never wrong, but guessing the language wrong
almost invariably leads to silly or confusing highlighting.

At the time of writing, admin-guide/oops-tracing.rst and
admin-guide/ramoops.rst contain good examples of 1) a small C code
snippet not highlighted, 2) a hex dump highligted as who knows what, 3)
device tree block highlighted as C or maybe Python, 4) a terminal
interaction highlighted as code in some language, and finally, 5) some C
code snippets correctly identified as C. I think we're better off
disabling language guessing, and going by explicitly identified
languages for longer code blocks.

It is still possible to enable highlighting on an rst source file basis
using the highlight directive:

.. higlight:: language

and on a literal block basis using the code-block directive:

.. code-block:: language

See http://www.sphinx-doc.org/en/latest/markup/code.html for details.

Cc: Jonathan Corbet 
Cc: Mauro Carvalho Chehab 
Cc: Markus Heiser 
Signed-off-by: Jani Nikula 
---
 Documentation/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 0c758a4f61f1..7ee45ac44dbc 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -136,7 +136,7 @@ pygments_style = 'sphinx'
 todo_include_todos = False
 
 primary_domain = 'C'
-highlight_language = 'guess'
+highlight_language = 'none'
 
 # -- Options for HTML output --
 
-- 
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 1/3] Documentation/sphinx: let the user specify PDFLATEX and LATEXOPTS

[Jani Nikula]

On Wed, 02 Nov 2016, Markus Heiser  wrote:
> Am 02.11.2016 um 10:40 schrieb Jani Nikula :
>
>> Refer to xelatex and latex options via variables. This allows the user
>> to override the pdflatex and latex options to use on the make command
>> line for experimenting. As a side effect, this makes the makefile a bit
>> tidier.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>> Documentation/Makefile.sphinx | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
>> index 92deea30b183..1314e3ee31c4 100644
>> --- a/Documentation/Makefile.sphinx
>> +++ b/Documentation/Makefile.sphinx
>> @@ -10,6 +10,8 @@ _SPHINXDIRS   = $(patsubst 
>> $(srctree)/Documentation/%/conf.py,%,$(wildcard $(src
>> SPHINX_CONF   = conf.py
>> PAPER =
>> BUILDDIR  = $(obj)/output
>> +PDFLATEX  = xelatex
>
> IMO, this is not a good idea since it could awakening expectations
> we can not fulfill, even not for "experimenting" with 'latex'.

You're reading too much into this patch. It's not so much that you could
switch to something else, but you could e.g. specify the full path to
xelatex. See SPHINXBUILD. It doesn't set the expectation you could use
something other than Sphinx.

BR,
Jani.


>
> (pdf)latex and xelatex differ in many ways, e.g. pdflatex needs inputenc
> and uses babel, while xelatex has utf-8 support and uses polyglossia.
>
>  
> http://tex.stackexchange.com/questions/2984/frequently-loaded-packages-differences-between-pdflatex-and-xelatex
>
> Thats why Mauros adds:
>
> +# Don't mangle with UTF-8 chars
> +'inputenc': '',
> +'utf8extra': '',
> +
>
> to the conf.py 
>
>  https://www.mail-archive.com/linux-doc@vger.kernel.org/msg05182.html
>
> Further IMO this way to use xelatex is just a "ugly hack", sphinx
> itself has no xelatex support. E.g. the sphinx team added 
> polyglossia only now:
>
>  
> https://github.com/sphinx-doc/sphinx/commit/5af1713d604f54b1aaf9e35f9c0fb4433b0f6e7a
>  
>
> The problem here is, that the sphinx team tries to extend a latex-writer
> with some "xelatex" features, where a xelatex-writer is needed.
> Another problem is, that Sphinx's TeX approach has no theming, this means
> everything is placed in the sphinx.sty and there is no API for
> a theming which is version compatible. Combined with the fact that we 
> want support from Sphinx 1.2, we have also no chance to ship our
> own sphinx.sty.
>
> I'am working on such a xelatex-writer, addressing those aspects, but there is
> a lot of work to do (will take months of my spare-time).
>
> In short: Sphinx's TeX support is ugly, we should not try to support 
> more variants than xelatex which was introduced by the patch from Mauro.
>
> -- Markus --
>
> 
>
> For those of us who are german readers, here is a good answer about
> in what ways pdflatex and xelatex differ (sorry only in german):
>
>  
> http://texwelt.de/wissen/fragen/5868/was-ist-der-unterschied-zwischen-latex-pdflatex-lualatex-und-xelatex
>  
>
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
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