* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Matthew Wilcox @ 2019-07-05 19:04 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20190705131446.GA10045@localhost>
On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> options when setting up an XFS. This makes it appropriate to be placed under
> the admin-guide tree.
>
> Thus, move xfs.txt to admin-guide and fix broken references.
What happened to the conversion to xfs.rst?
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Sheriff Esseson @ 2019-07-05 19:41 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel-mentees, darrick.wong, linux-xfs, corbet, linux-doc
In-Reply-To: <20190705190412.GB32320@bombadil.infradead.org>
On Fri, Jul 05, 2019 at 12:04:12PM -0700, Matthew Wilcox wrote:
> On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> > As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> > options when setting up an XFS. This makes it appropriate to be placed under
> > the admin-guide tree.
> >
> > Thus, move xfs.txt to admin-guide and fix broken references.
>
> What happened to the conversion to xfs.rst?
Okay, I was thinking placing the file properly should come first before the
conversion.
I'll continue work on the conversion right away. I'll send it on Monday, letting
the dust settle on this one.
>
> _______________________________________________
> Linux-kernel-mentees mailing list
> Linux-kernel-mentees@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
thanks.
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Luis Chamberlain @ 2019-07-05 20:15 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-2-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> Add core facilities for defining unit tests; this provides a common way
> to define test cases, functions that execute code which is under test
> and determine whether the code under test behaves as expected; this also
> provides a way to group together related test cases in test suites (here
> we call them test_modules).
>
> Just define test cases and how to execute them for now; setting
> expectations on code will be defined later.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
But a nitpick below, I think that can be fixed later with a follow up
patch.
> +/**
> + * struct kunit - represents a running instance of a test.
> + * @priv: for user to store arbitrary data. Commonly used to pass data created
> + * in the init function (see &struct kunit_suite).
> + *
> + * Used to store information about the current context under which the test is
> + * running. Most of this data is private and should only be accessed indirectly
> + * via public functions; the one exception is @priv which can be used by the
> + * test writer to store arbitrary data.
> + *
> + * A brief note on locking:
> + *
> + * First off, we need to lock because in certain cases a user may want to use an
> + * expectation in a thread other than the thread that the test case is running
> + * in.
This as a prefix to the struct without a lock seems odd. It would be
clearer I think if you'd explain here what locking mechanism we decided
to use and why it suffices today.
> +/**
> + * suite_test() - used to register a &struct kunit_suite with KUnit.
You mean kunit_test_suite()?
> + * @suite: a statically allocated &struct kunit_suite.
> + *
> + * Registers @suite with the test framework. See &struct kunit_suite for more
> + * information.
> + *
> + * NOTE: Currently KUnit tests are all run as late_initcalls; this means that
> + * they cannot test anything where tests must run at a different init phase. One
> + * significant restriction resulting from this is that KUnit cannot reliably
> + * test anything that is initialize in the late_init phase.
initialize prior to the late init phase.
That is, this is useless to test things running early.
> + *
> + * TODO(brendanhiggins@google.com): Don't run all KUnit tests as late_initcalls.
> + * I have some future work planned to dispatch all KUnit tests from the same
> + * place, and at the very least to do so after everything else is definitely
> + * initialized.
TODOs are odd to be adding to documentation, this is just not common
place practice. The NOTE should suffice for you.
Luis
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Luis Chamberlain @ 2019-07-05 20:20 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-2-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> +struct kunit {
> + void *priv;
> +
> + /* private: internal use only. */
> + const char *name; /* Read only after initialization! */
> + bool success; /* Read only after test_case finishes! */
> +};
No lock attribute above.
> +void kunit_init_test(struct kunit *test, const char *name)
> +{
> + spin_lock_init(&test->lock);
> + test->name = name;
> + test->success = true;
> +}
And yet here you initialize a spin lock... This won't compile. Seems
you forgot to remove this line. So I guess a re-spin is better.
Luis
^ permalink raw reply
* [PATCH] Documentation: coresight: covert txt to rst
From: Phong Tran @ 2019-07-05 20:45 UTC (permalink / raw)
To: corbet, mathieu.poirier, suzuki.poulose
Cc: skhan, mchehab, linux-arm-kernel, linux-doc, linux-kernel,
linux-kernel-mentees, Phong Tran
change the format file and adpate the text style
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
---
.../trace/{coresight.txt => coresight.rst} | 296 ++++++++++++---------
Documentation/trace/index.rst | 1 +
2 files changed, 167 insertions(+), 130 deletions(-)
rename Documentation/trace/{coresight.txt => coresight.rst} (59%)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
similarity index 59%
rename from Documentation/trace/coresight.txt
rename to Documentation/trace/coresight.rst
index efbc832146e7..bea24e70cfba 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.rst
@@ -1,5 +1,6 @@
- Coresight - HW Assisted Tracing on ARM
- ======================================
+======================================
+Coresight - HW Assisted Tracing on ARM
+======================================
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date: September 11th, 2014
@@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
creating an interface to the outside world where data can be transferred to a
host without fear of filling up the onboard coresight memory buffer.
-At typical coresight system would look like this:
+At typical coresight system would look like this::
*****************************************************************
**************************** AMBA AXI ****************************===||
@@ -95,6 +96,7 @@ Acronyms and Classification
Acronyms:
+======== =============================================================
PTM: Program Trace Macrocell
ETM: Embedded Trace Macrocell
STM: System trace Macrocell
@@ -104,6 +106,7 @@ TPIU: Trace Port Interface Unit
TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
CTI: Cross Trigger Interface
+======== =============================================================
Classification:
@@ -118,7 +121,7 @@ Misc:
Device Tree Bindings
-----------------------
+--------------------
See Documentation/devicetree/bindings/arm/coresight.txt for details.
@@ -133,57 +136,63 @@ The coresight framework provides a central point to represent, configure and
manage coresight devices on a platform. Any coresight compliant device can
register with the framework for as long as they use the right APIs:
-struct coresight_device *coresight_register(struct coresight_desc *desc);
-void coresight_unregister(struct coresight_device *csdev);
+.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
+.. c:function:: void coresight_unregister(struct coresight_device *csdev);
-The registering function is taking a "struct coresight_device *csdev" and
+The registering function is taking a :code:`struct coresight_device *csdev` and
register the device with the core framework. The unregister function takes
-a reference to a "struct coresight_device", obtained at registration time.
+a reference to a :code:`struct coresight_device`, obtained at registration time.
If everything goes well during the registration process the new devices will
show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
-root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:~#
+.. code:: console
-The functions take a "struct coresight_device", which looks like this:
+ root:~# ls /sys/bus/coresight/devices/
+ replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+ 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+ root:~#
-struct coresight_desc {
- enum coresight_dev_type type;
- struct coresight_dev_subtype subtype;
- const struct coresight_ops *ops;
- struct coresight_platform_data *pdata;
- struct device *dev;
- const struct attribute_group **groups;
-};
+The functions take a :code:`struct coresight_device`, which looks like this:
+
+.. code:: c
+
+ struct coresight_desc {
+ enum coresight_dev_type type;
+ struct coresight_dev_subtype subtype;
+ const struct coresight_ops *ops;
+ struct coresight_platform_data *pdata;
+ struct device *dev;
+ const struct attribute_group **groups;
+ };
The "coresight_dev_type" identifies what the device is, i.e, source link or
sink while the "coresight_dev_subtype" will characterise that type further.
-The "struct coresight_ops" is mandatory and will tell the framework how to
+The :code:`struct coresight_ops` is mandatory and will tell the framework how to
perform base operations related to the components, each component having
-a different set of requirement. For that "struct coresight_ops_sink",
-"struct coresight_ops_link" and "struct coresight_ops_source" have been
+a different set of requirement. For that :code:`struct coresight_ops_sink,
+struct coresight_ops_link` and :code:`struct coresight_ops_source` have been
provided.
-The next field, "struct coresight_platform_data *pdata" is acquired by calling
-"of_get_coresight_platform_data()", as part of the driver's _probe routine and
-"struct device *dev" gets the device reference embedded in the "amba_device":
+The next field, :code:`struct coresight_platform_data *pdata` is acquired by calling
+:code:`of_get_coresight_platform_data()`, as part of the driver's _probe routine and
+:code:`struct device *dev` gets the device reference embedded in the :code:`amba_device`:
-static int etm_probe(struct amba_device *adev, const struct amba_id *id)
-{
- ...
- ...
- drvdata->dev = &adev->dev;
- ...
-}
+.. code:: c
+
+ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
+ {
+ ...
+ ...
+ drvdata->dev = &adev->dev;
+ ...
+ }
Specific class of device (source, link, or sink) have generic operations
-that can be performed on them (see "struct coresight_ops"). The
-"**groups" is a list of sysfs entries pertaining to operations
+that can be performed on them (see :code:`struct coresight_ops`). The
+:code:`**groups` is a list of sysfs entries pertaining to operations
specific to that component only. "Implementation defined" customisations are
expected to be accessed and controlled using those entries.
@@ -204,49 +213,56 @@ There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
-root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
-root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
-root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
-1
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# ls
+ replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+ 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+ root:/sys/bus/coresight/devices# ls 20010000.etb
+ enable_sink status trigger_cntr
+ root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
+ root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
+ 1
+ root:/sys/bus/coresight/devices#
At boot time the current etm3x driver will configure the first address
comparator with "_stext" and "_etext", essentially tracing any instruction
that falls within that range. As such "enabling" a source will immediately
trigger a trace capture:
-root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
-1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
+ root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
+ 1
+ root:/sys/bus/coresight/devices# cat 20010000.etb/status
+ Depth: 0x2000
+ Status: 0x1
+ RAM read ptr: 0x0
+ RAM wrt ptr: 0x19d3 <----- The write pointer is moving
+ Trigger cnt: 0x0
+ Control: 0x1
+ Flush status: 0x0
+ Flush ctrl: 0x2001
+ root:/sys/bus/coresight/devices#
Trace collection is stopped the same way:
-root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
+ root:/sys/bus/coresight/devices#
The content of the ETB buffer can be harvested directly from /dev:
-root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
-of=~/cstrace.bin
+.. code:: console
-64+0 records in
-64+0 records out
-32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
-root:/sys/bus/coresight/devices#
+ root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
+ of=~/cstrace.bin
+ 64+0 records in
+ 64+0 records out
+ 32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
+ root:/sys/bus/coresight/devices#
The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
@@ -254,55 +270,57 @@ Following is a DS-5 output of an experimental loop that increments a variable up
to a certain value. The example is simple and yet provides a glimpse of the
wealth of possibilities that coresight provides.
-Info Tracing enabled
-Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
-Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
-Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
-Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Timestamp Timestamp: 17106715833
-Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
-Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
-Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
-Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
-Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
-Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
-Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
-Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
-Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
-Info Tracing enabled
-Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
-Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
-Timestamp Timestamp: 17107041535
+.. code:: c
+
+ Info Tracing enabled
+ Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
+ Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
+ Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
+ Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Timestamp Timestamp: 17106715833
+ Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
+ Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
+ Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
+ Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
+ Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
+ Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
+ Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
+ Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
+ Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
+ Info Tracing enabled
+ Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
+ Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
+ Timestamp Timestamp: 17107041535
2) Using perf framework:
@@ -312,6 +330,8 @@ controlling when tracing gets enabled based on when the process of interest is
scheduled. When configured in a system, Coresight PMUs will be listed when
queried by the perf command line tool:
+.. code:: console
+
linaro@linaro-nano:~$ ./perf list pmu
List of pre-defined events (to be used in -e):
@@ -329,6 +349,8 @@ Coresight system will typically have more than one sink, the name of the sink to
work with needs to be specified as an event option. Names for sink to choose
from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+.. code:: console
+
root@linaro-nano:~# ls /sys/bus/coresight/devices/
20010000.etf 20040000.funnel 20100000.stm 22040000.etm
22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
@@ -343,7 +365,7 @@ to use for the trace session.
More information on the above and other example on how to use Coresight with
the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
-repository [3].
+repository [#third]_.
2.1) AutoFDO analysis using the perf tools:
@@ -352,6 +374,8 @@ perf can be used to record and analyze trace of programs.
Execution can be recorded using 'perf record' with the cs_etm event,
specifying the name of the sink to record to, e.g:
+.. code:: console
+
perf record -e cs_etm/@20070000.etr/u --per-thread
The 'perf report' and 'perf script' commands can be used to analyze execution,
@@ -370,12 +394,16 @@ Generating coverage files for Feedback Directed Optimization: AutoFDO
'perf inject' accepts the --itrace option in which case tracing data is
removed and replaced with the synthesized events. e.g.
+.. code:: console
+
perf inject --itrace --strip -i perf.data -o perf.data.new
Below is an example of using ARM ETM for autoFDO. It requires autofdo
(https://github.com/google/autofdo) and gcc version 5. The bubble
sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
+.. code:: console
+
$ gcc-5 -O3 sort.c -o sort
$ taskset -c 2 ./sort
Bubble sorting array of 30000 elements
@@ -403,28 +431,36 @@ difference is that clients are driving the trace capture rather
than the program flow through the code.
As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
+found in sysfs with more information on each entry being found in [#first]_:
-root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root@genericarmv8:~#
+.. code:: console
+
+ root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+ enable_source hwevent_select port_enable subsystem uevent
+ hwevent_enable mgmt port_select traceid
+ root@genericarmv8:~#
Like any other source a sink needs to be identified and the STM enabled before
being used:
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+.. code:: console
+
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
From there user space applications can request and use channels using the devfs
interface provided for that purpose by the generic STM API:
-root@genericarmv8:~# ls -l /dev/20100000.stm
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
-root@genericarmv8:~#
+.. code:: console
+
+ root@genericarmv8:~# ls -l /dev/20100000.stm
+ crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
+ root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [#second]_.
+
+.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-Details on how to use the generic STM API can be found here [2].
+.. [#second] Documentation/trace/stm.rst
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.rst
-[3]. https://github.com/Linaro/perf-opencsd
+.. [#third] https://github.com/Linaro/perf-opencsd
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index 6b4107cf4b98..3330c5456bcb 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -23,3 +23,4 @@ Linux Tracing Technologies
intel_th
stm
sys-t
+ coresight
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 02/18] kunit: test: add test resource management API
From: Luis Chamberlain @ 2019-07-05 20:45 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-3-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:59PM -0700, Brendan Higgins wrote:
> diff --git a/kunit/test.c b/kunit/test.c
> index c030ba5a43e40..a70fbe449e922 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
> @@ -122,7 +122,8 @@ static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
>
> void kunit_init_test(struct kunit *test, const char *name)
> {
> - spin_lock_init(&test->lock);
Once you re-spin, this above line should be removed.
> + mutex_init(&test->lock);
> + INIT_LIST_HEAD(&test->resources);
> test->name = name;
> test->success = true;
> }
Luis
^ permalink raw reply
* Re: [PATCH v6 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
From: Luis Chamberlain @ 2019-07-05 20:45 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg, Iurii Zaikin
In-Reply-To: <20190704003615.204860-18-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:36:14PM -0700, Brendan Higgins wrote:
> From: Iurii Zaikin <yzaikin@google.com>
>
> KUnit tests for initialized data behavior of proc_dointvec that is
> explicitly checked in the code. Includes basic parsing tests including
> int min/max overflow.
>
> Signed-off-by: Iurii Zaikin <yzaikin@google.com>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Luis
^ permalink raw reply
* [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-07-05 20:47 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, ilias.apalodimas, sumit.garg, rdunlap,
Sasha Levin
Changes from v7:
- Address Jarkko's comments.
Sasha Levin (2):
fTPM: firmware TPM running in TEE
fTPM: add documentation for ftpm driver
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 27 ++
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 +++
6 files changed, 424 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
--
2.20.1
^ permalink raw reply
* [PATCH v8 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-07-05 20:47 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, ilias.apalodimas, sumit.garg, rdunlap,
Sasha Levin
In-Reply-To: <20190705204746.27543-1-sashal@kernel.org>
This patch adds support for a software-only implementation of a TPM
running in TEE.
There is extensive documentation of the design here:
https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ .
As well as reference code for the firmware available here:
https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
Tested-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
Signed-off-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
Co-authored-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 1 +
drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++++++++++++++
drivers/char/tpm/tpm_ftpm_tee.h | 40 ++++
4 files changed, 396 insertions(+)
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 88a3c06fc153..17bfbf9f572f 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -164,6 +164,11 @@ config TCG_VTPM_PROXY
/dev/vtpmX and a server-side file descriptor on which the vTPM
can receive commands.
+config TCG_FTPM_TEE
+ tristate "TEE based fTPM Interface"
+ depends on TEE && OPTEE
+ ---help---
+ This driver proxies for firmware TPM running in TEE.
source "drivers/char/tpm/st33zp24/Kconfig"
endif # TCG_TPM
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a01c4cab902a..c354cdff9c62 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
obj-$(CONFIG_TCG_CRB) += tpm_crb.o
obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
+obj-$(CONFIG_TCG_FTPM_TEE) += tpm_ftpm_tee.o
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
new file mode 100644
index 000000000000..74766a4d3280
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Microsoft Corporation
+ *
+ * Implements a firmware TPM as described here:
+ * https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/
+ *
+ * A reference implementation is available here:
+ * https://github.com/microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM
+ */
+
+#include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+#include "tpm.h"
+#include "tpm_ftpm_tee.h"
+
+/*
+ * TA_FTPM_UUID: BC50D971-D4C9-42C4-82CB-343FB7F37896
+ *
+ * Randomly generated, and must correspond to the GUID on the TA side.
+ * Defined here in the reference implementation:
+ * https://github.com/microsoft/ms-tpm-20-ref/blob/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/include/fTPM.h#L42
+ */
+static const uuid_t ftpm_ta_uuid =
+ UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+ 0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
+
+/**
+ * ftpm_tee_tpm_op_recv - retrieve fTPM response.
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h.
+ * @buf: the buffer to store data.
+ * @count: the number of bytes to read.
+ *
+ * Return:
+ * In case of success the number of bytes received.
+ * On failure, -errno.
+ */
+static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8 *buf, size_t count)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t len;
+
+ len = pvt_data->resp_len;
+ if (count < len) {
+ dev_err(&chip->dev,
+ "%s: Invalid size in recv: count=%zd, resp_len=%zd\n",
+ __func__, count, len);
+ return -EIO;
+ }
+
+ memcpy(buf, pvt_data->resp_buf, len);
+ pvt_data->resp_len = 0;
+
+ return len;
+}
+
+/**
+ * ftpm_tee_tpm_op_send - send TPM commands through the TEE shared memory.
+ * @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h
+ * @buf: the buffer to send.
+ * @len: the number of bytes to send.
+ *
+ * Return:
+ * In case of success, returns 0.
+ * On failure, -errno
+ */
+static int ftpm_tee_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t len)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
+ size_t resp_len;
+ int rc;
+ u8 *temp_buf;
+ struct tpm_header *resp_header;
+ struct tee_ioctl_invoke_arg transceive_args;
+ struct tee_param command_params[4];
+ struct tee_shm *shm = pvt_data->shm;
+
+ if (len > MAX_COMMAND_SIZE) {
+ dev_err(&chip->dev,
+ "%s: len=%zd exceeds MAX_COMMAND_SIZE supported by fTPM TA\n",
+ __func__, len);
+ return -EIO;
+ }
+
+ memset(&transceive_args, 0, sizeof(transceive_args));
+ memset(command_params, 0, sizeof(command_params));
+ pvt_data->resp_len = 0;
+
+ /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of fTPM TA */
+ transceive_args = (struct tee_ioctl_invoke_arg) {
+ .func = FTPM_OPTEE_TA_SUBMIT_COMMAND,
+ .session = pvt_data->session,
+ .num_params = 4,
+ };
+
+ /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
+ command_params[0] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
+ .u.memref = {
+ .shm = shm,
+ .size = len,
+ .shm_offs = 0,
+ },
+ };
+
+ temp_buf = tee_shm_get_va(shm, 0);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s: tee_shm_get_va failed for transmit\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+ memset(temp_buf, 0, (MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE));
+ memcpy(temp_buf, buf, len);
+
+ command_params[1] = (struct tee_param) {
+ .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
+ .u.memref = {
+ .shm = shm,
+ .size = MAX_RESPONSE_SIZE,
+ .shm_offs = MAX_COMMAND_SIZE,
+ },
+ };
+
+ rc = tee_client_invoke_func(pvt_data->ctx, &transceive_args,
+ command_params);
+ if ((rc < 0) || (transceive_args.ret != 0)) {
+ dev_err(&chip->dev, "%s: SUBMIT_COMMAND invoke error: 0x%x\n",
+ __func__, transceive_args.ret);
+ return (rc < 0) ? rc : transceive_args.ret;
+ }
+
+ temp_buf = tee_shm_get_va(shm, command_params[1].u.memref.shm_offs);
+ if (IS_ERR(temp_buf)) {
+ dev_err(&chip->dev, "%s: tee_shm_get_va failed for receive\n",
+ __func__);
+ return PTR_ERR(temp_buf);
+ }
+
+ resp_header = (struct tpm_header *)temp_buf;
+ resp_len = be32_to_cpu(resp_header->length);
+
+ /* sanity check resp_len */
+ if (resp_len < TPM_HEADER_SIZE) {
+ dev_err(&chip->dev, "%s: tpm response header too small\n",
+ __func__);
+ return -EIO;
+ }
+ if (resp_len > MAX_RESPONSE_SIZE) {
+ dev_err(&chip->dev,
+ "%s: resp_len=%zd exceeds MAX_RESPONSE_SIZE\n",
+ __func__, resp_len);
+ return -EIO;
+ }
+
+ /* sanity checks look good, cache the response */
+ memcpy(pvt_data->resp_buf, temp_buf, resp_len);
+ pvt_data->resp_len = resp_len;
+
+ return 0;
+}
+
+static void ftpm_tee_tpm_op_cancel(struct tpm_chip *chip)
+{
+ /* not supported */
+}
+
+static u8 ftpm_tee_tpm_op_status(struct tpm_chip *chip)
+{
+ return 0;
+}
+
+static bool ftpm_tee_tpm_req_canceled(struct tpm_chip *chip, u8 status)
+{
+ return 0;
+}
+
+static const struct tpm_class_ops ftpm_tee_tpm_ops = {
+ .flags = TPM_OPS_AUTO_STARTUP,
+ .recv = ftpm_tee_tpm_op_recv,
+ .send = ftpm_tee_tpm_op_send,
+ .cancel = ftpm_tee_tpm_op_cancel,
+ .status = ftpm_tee_tpm_op_status,
+ .req_complete_mask = 0,
+ .req_complete_val = 0,
+ .req_canceled = ftpm_tee_tpm_req_canceled,
+};
+
+/*
+ * Check whether this driver supports the fTPM TA in the TEE instance
+ * represented by the params (ver/data) to this function.
+ */
+static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+ /*
+ * Currently this driver only support GP Complaint OPTEE based fTPM TA
+ */
+ if ((ver->impl_id == TEE_IMPL_ID_OPTEE) &&
+ (ver->gen_caps & TEE_GEN_CAP_GP))
+ return 1;
+ else
+ return 0;
+}
+
+/**
+ * ftpm_tee_probe - initialize the fTPM
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * On success, 0. On failure, -errno.
+ */
+static int ftpm_tee_probe(struct platform_device *pdev)
+{
+ int rc;
+ struct tpm_chip *chip;
+ struct device *dev = &pdev->dev;
+ struct ftpm_tee_private *pvt_data = NULL;
+ struct tee_ioctl_open_session_arg sess_arg;
+
+ pvt_data = devm_kzalloc(dev, sizeof(struct ftpm_tee_private),
+ GFP_KERNEL);
+ if (!pvt_data)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, pvt_data);
+
+ /* Open context with TEE driver */
+ pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
+ NULL);
+ if (IS_ERR(pvt_data->ctx)) {
+ if (ERR_PTR(pvt_data->ctx) == -ENOENT)
+ return -EPROBE_DEFER;
+ dev_err(dev, "%s: tee_client_open_context failed\n", __func__);
+ return ERR_PTR(pvt_data->ctx);
+ }
+
+ /* Open a session with fTPM TA */
+ memset(&sess_arg, 0, sizeof(sess_arg));
+ memcpy(sess_arg.uuid, ftpm_ta_uuid.b, TEE_IOCTL_UUID_LEN);
+ sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+ sess_arg.num_params = 0;
+
+ rc = tee_client_open_session(pvt_data->ctx, &sess_arg, NULL);
+ if ((rc < 0) || (sess_arg.ret != 0)) {
+ dev_err(dev, "%s: tee_client_open_session failed, err=%x\n",
+ __func__, sess_arg.ret);
+ rc = -EINVAL;
+ goto out_tee_session;
+ }
+ pvt_data->session = sess_arg.session;
+
+ /* Allocate dynamic shared memory with fTPM TA */
+ pvt_data->shm = tee_shm_alloc(pvt_data->ctx,
+ MAX_COMMAND_SIZE + MAX_RESPONSE_SIZE,
+ TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+ if (IS_ERR(pvt_data->shm)) {
+ dev_err(dev, "%s: tee_shm_alloc failed\n", __func__);
+ rc = -ENOMEM;
+ goto out_shm_alloc;
+ }
+
+ /* Allocate new struct tpm_chip instance */
+ chip = tpm_chip_alloc(dev, &ftpm_tee_tpm_ops);
+ if (IS_ERR(chip)) {
+ dev_err(dev, "%s: tpm_chip_alloc failed\n", __func__);
+ rc = PTR_ERR(chip);
+ goto out_chip_alloc;
+ }
+
+ pvt_data->chip = chip;
+ pvt_data->chip->flags |= TPM_CHIP_FLAG_TPM2;
+
+ /* Create a character device for the fTPM */
+ rc = tpm_chip_register(pvt_data->chip);
+ if (rc) {
+ dev_err(dev, "%s: tpm_chip_register failed with rc=%d\n",
+ __func__, rc);
+ goto out_chip;
+ }
+
+ return 0;
+
+out_chip:
+ put_device(&pvt_data->chip->dev);
+out_chip_alloc:
+ tee_shm_free(pvt_data->shm);
+out_shm_alloc:
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+out_tee_session:
+ tee_client_close_context(pvt_data->ctx);
+
+ return rc;
+}
+
+/**
+ * ftpm_tee_remove - remove the TPM device
+ * @pdev: the platform_device description.
+ *
+ * Return:
+ * 0 always.
+ */
+static int ftpm_tee_remove(struct platform_device *pdev)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(&pdev->dev);
+
+ /* Release the chip */
+ tpm_chip_unregister(pvt_data->chip);
+
+ /* frees chip */
+ put_device(&pvt_data->chip->dev);
+
+ /* Free the shared memory pool */
+ tee_shm_free(pvt_data->shm);
+
+ /* close the existing session with fTPM TA*/
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+
+ /* close the context with TEE driver */
+ tee_client_close_context(pvt_data->ctx);
+
+ /* memory allocated with devm_kzalloc() is freed automatically */
+
+ return 0;
+}
+
+static const struct of_device_id of_ftpm_tee_ids[] = {
+ { .compatible = "microsoft,ftpm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_ftpm_tee_ids);
+
+static struct platform_driver ftpm_tee_driver = {
+ .driver = {
+ .name = "ftpm-tee",
+ .of_match_table = of_match_ptr(of_ftpm_tee_ids),
+ },
+ .probe = ftpm_tee_probe,
+ .remove = ftpm_tee_remove,
+};
+
+module_platform_driver(ftpm_tee_driver);
+
+MODULE_AUTHOR("Thirupathaiah Annapureddy <thiruan@microsoft.com>");
+MODULE_DESCRIPTION("TPM Driver for fTPM TA in TEE");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/char/tpm/tpm_ftpm_tee.h b/drivers/char/tpm/tpm_ftpm_tee.h
new file mode 100644
index 000000000000..f98daa7bf68c
--- /dev/null
+++ b/drivers/char/tpm/tpm_ftpm_tee.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) Microsoft Corporation
+ */
+
+#ifndef __TPM_FTPM_TEE_H__
+#define __TPM_FTPM_TEE_H__
+
+#include <linux/tee_drv.h>
+#include <linux/tpm.h>
+#include <linux/uuid.h>
+
+/* The TAFs ID implemented in this TA */
+#define FTPM_OPTEE_TA_SUBMIT_COMMAND (0)
+#define FTPM_OPTEE_TA_EMULATE_PPI (1)
+
+/* max. buffer size supported by fTPM */
+#define MAX_COMMAND_SIZE 4096
+#define MAX_RESPONSE_SIZE 4096
+
+/**
+ * struct ftpm_tee_private - fTPM's private data
+ * @chip: struct tpm_chip instance registered with tpm framework.
+ * @state: internal state
+ * @session: fTPM TA session identifier.
+ * @resp_len: cached response buffer length.
+ * @resp_buf: cached response buffer.
+ * @ctx: TEE context handler.
+ * @shm: Memory pool shared with fTPM TA in TEE.
+ */
+struct ftpm_tee_private {
+ struct tpm_chip *chip;
+ u32 session;
+ size_t resp_len;
+ u8 resp_buf[MAX_RESPONSE_SIZE];
+ struct tee_context *ctx;
+ struct tee_shm *shm;
+};
+
+#endif /* __TPM_FTPM_TEE_H__ */
--
2.20.1
^ permalink raw reply related
* [PATCH v8 2/2] fTPM: add documentation for ftpm driver
From: Sasha Levin @ 2019-07-05 20:47 UTC (permalink / raw)
To: peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev, ilias.apalodimas, sumit.garg, rdunlap,
Sasha Levin
In-Reply-To: <20190705204746.27543-1-sashal@kernel.org>
This patch adds basic documentation to describe the new fTPM driver.
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/security/tpm/index.rst | 1 +
Documentation/security/tpm/tpm_ftpm_tee.rst | 27 +++++++++++++++++++++
2 files changed, 28 insertions(+)
create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst
index af77a7bbb070..15783668644f 100644
--- a/Documentation/security/tpm/index.rst
+++ b/Documentation/security/tpm/index.rst
@@ -4,4 +4,5 @@ Trusted Platform Module documentation
.. toctree::
+ tpm_ftpm_tee
tpm_vtpm_proxy
diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst b/Documentation/security/tpm/tpm_ftpm_tee.rst
new file mode 100644
index 000000000000..8c2bae16e3d9
--- /dev/null
+++ b/Documentation/security/tpm/tpm_ftpm_tee.rst
@@ -0,0 +1,27 @@
+=============================================
+Firmware TPM Driver
+=============================================
+
+This document describes the firmware Trusted Platform Module (fTPM)
+device driver.
+
+Introduction
+============
+
+This driver is a shim for firmware implemented in ARM's TrustZone
+environment. The driver allows programs to interact with the TPM in the same
+way they would interact with a hardware TPM.
+
+Design
+======
+
+The driver acts as a thin layer that passes commands to and from a TPM
+implemented in firmware. The driver itself doesn't contain much logic and is
+used more like a dumb pipe between firmware and kernel/userspace.
+
+The firmware itself is based on the following paper:
+https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf
+
+When the driver is loaded it will expose ``/dev/tpmX`` character devices to
+userspace which will enable userspace to communicate with the firmware TPM
+through this device.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Luis Chamberlain @ 2019-07-05 20:48 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-19-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
> Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Come to think of it, I'd welcome Iurii to be added as a maintainer,
with the hope Iurii would be up to review only the kunit changes. Of
course if Iurii would be up to also help review future proc changes,
even better. 3 pair of eyeballs is better than 2 pairs.
Luis
^ permalink raw reply
* [PATCH] Documentation: cpu-freq: Convert core.txt file to ReST format
From: Shreeya Patel @ 2019-07-05 21:04 UTC (permalink / raw)
To: skhan, rjw, viresh.kumar, corbet, linux-pm, linux-kernel,
linux-doc, linux-kernel-mentees
Convert core file to ReST format, in order to allow it to
be parsed by Sphinx. Make a minor change of correcting the wrong
function name cpufreq_put_cpu to cpufreq_cpu_put.
Also create an index.rst file in cpu-freq and add it's entry
in the main Documentation/index.rst file.
Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
---
Documentation/cpu-freq/core.rst | 114 +++++++++++++++++++++++++++++
Documentation/cpu-freq/core.txt | 120 -------------------------------
Documentation/cpu-freq/index.rst | 14 ++++
Documentation/index.rst | 1 +
4 files changed, 129 insertions(+), 120 deletions(-)
create mode 100644 Documentation/cpu-freq/core.rst
delete mode 100644 Documentation/cpu-freq/core.txt
create mode 100644 Documentation/cpu-freq/index.rst
diff --git a/Documentation/cpu-freq/core.rst b/Documentation/cpu-freq/core.rst
new file mode 100644
index 000000000000..b4cf48633797
--- /dev/null
+++ b/Documentation/cpu-freq/core.rst
@@ -0,0 +1,114 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+CPUFreq Core
+============
+
+Authors:
+
+- Dominik Brodowski <linux@brodo.de>,
+- David Kimdon <dwhedon@debian.org>,
+- Rafael J. Wysocki <rafael.j.wysocki@intel.com>,
+- Viresh Kumar <viresh.kumar@linaro.org>
+
+
+Clock scaling allows you to change the clock speed of the CPUs on the
+fly. This is a nice method to save battery power, because the lower
+the clock speed, the less power the CPU consumes.
+
+
+1. General Information
+----------------------
+
+The CPUFreq core code is located in :file:`drivers/cpufreq/cpufreq.c`. This
+cpufreq code offers a standardized interface for the CPUFreq
+architecture drivers (those pieces of code that do actual
+frequency transitions), as well as to "notifiers". These are device
+drivers or other part of the kernel that need to be informed of
+policy changes (ex. thermal modules like ACPI) or of all
+frequency changes (ex. timing code) or even need to force certain
+speed limits (like LCD drivers on ARM architecture). Additionally, the
+kernel "constant" :c:data:`loops_per_jiffy` is updated on frequency changes
+here.
+
+Reference counting of the cpufreq policies is done by :c:func:`cpufreq_cpu_put`
+and :c:func:`cpufreq_cpu_put`, which make sure that the cpufreq driver is
+correctly registered with the core, and will not be unloaded until
+:c:func:`cpufreq_cpu_put` is called. That also ensures that the respective cpufreq
+policy doesn't get freed while being used.
+
+2. CPUFreq notifiers
+--------------------
+
+CPUFreq notifiers conform to the standard kernel notifier interface.
+See :file:`linux/include/linux/notifier.h` for details on notifiers.
+
+There are two different CPUFreq notifiers - policy notifiers and
+transition notifiers.
+
+
+2.1 CPUFreq policy notifiers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are notified when a new policy is intended to be set. Each
+CPUFreq policy notifier is called twice for a policy transition:
+
+ 1) During :c:macro:`CPUFREQ_ADJUST` all CPUFreq notifiers may change
+ the limit if they see a need for this - may it be thermal considerations
+ or hardware limitations.
+
+ 2) And during :c:macro:`CPUFREQ_NOTIFY` all notifiers are informed of the
+ new policy - if two hardware drivers failed to agree on a new policy
+ before this stage, the incompatible hardware shall be shut down, and the user
+ informed of this.
+
+The phase is specified in the second argument to the notifier.
+
+The third argument, a :c:data:`void *pointer`, points to a :c:type:`struct cpufreq_policy`
+consisting of several values, including min, max (the lower and upper
+frequencies (in kHz) of the new policy).
+
+
+2.2 CPUFreq transition notifiers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are notified twice for each online CPU in the policy, when the
+CPUfreq driver switches the CPU core frequency and this change has no
+any external implications.
+
+The second argument specifies the phase - :c:macro:`CPUFREQ_PRECHANGE` or
+:c:macro:`CPUFREQ_POSTCHANGE`.
+
+The third argument is a :c:type:`struct cpufreq_freqs` with the following
+values:
+
+| cpu - number of the affected CPU
+| old - old frequency
+| new - new frequency
+| flags - flags of the cpufreq driver
+
+
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
+------------------------------------------------------------------
+For details about OPP, see :file:`Documentation/power/opp.txt`
+
+:c:func:`dev_pm_opp_init_cpufreq_table` - This function provides a ready
+to use conversion routine to translate the OPP layer's internal information
+about the available frequencies into a format readily providable to cpufreq.
+
+WARNING: Do not use this function in interrupt context.
+
+ Example::
+
+ soc_pm_init()
+ {
+ /* Do things */
+ r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
+ if (!r)
+ policy->freq_table = freq_table;
+ /* Do other things */
+ }
+
+NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
+addition to CONFIG_PM_OPP.
+
+:c:func:`dev_pm_opp_free_cpufreq_table` - Free up the table allocated by :c:func:`dev_pm_opp_init_cpufreq_table`
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
deleted file mode 100644
index 073f128af5a7..000000000000
--- a/Documentation/cpu-freq/core.txt
+++ /dev/null
@@ -1,120 +0,0 @@
- CPU frequency and voltage scaling code in the Linux(TM) kernel
-
-
- L i n u x C P U F r e q
-
- C P U F r e q C o r e
-
-
- Dominik Brodowski <linux@brodo.de>
- David Kimdon <dwhedon@debian.org>
- Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Viresh Kumar <viresh.kumar@linaro.org>
-
-
-
- Clock scaling allows you to change the clock speed of the CPUs on the
- fly. This is a nice method to save battery power, because the lower
- the clock speed, the less power the CPU consumes.
-
-
-Contents:
----------
-1. CPUFreq core and interfaces
-2. CPUFreq notifiers
-3. CPUFreq Table Generation with Operating Performance Point (OPP)
-
-1. General Information
-=======================
-
-The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This
-cpufreq code offers a standardized interface for the CPUFreq
-architecture drivers (those pieces of code that do actual
-frequency transitions), as well as to "notifiers". These are device
-drivers or other part of the kernel that need to be informed of
-policy changes (ex. thermal modules like ACPI) or of all
-frequency changes (ex. timing code) or even need to force certain
-speed limits (like LCD drivers on ARM architecture). Additionally, the
-kernel "constant" loops_per_jiffy is updated on frequency changes
-here.
-
-Reference counting of the cpufreq policies is done by cpufreq_cpu_get
-and cpufreq_cpu_put, which make sure that the cpufreq driver is
-correctly registered with the core, and will not be unloaded until
-cpufreq_put_cpu is called. That also ensures that the respective cpufreq
-policy doesn't get freed while being used.
-
-2. CPUFreq notifiers
-====================
-
-CPUFreq notifiers conform to the standard kernel notifier interface.
-See linux/include/linux/notifier.h for details on notifiers.
-
-There are two different CPUFreq notifiers - policy notifiers and
-transition notifiers.
-
-
-2.1 CPUFreq policy notifiers
-----------------------------
-
-These are notified when a new policy is intended to be set. Each
-CPUFreq policy notifier is called twice for a policy transition:
-
-1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
- they see a need for this - may it be thermal considerations or
- hardware limitations.
-
-2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
- - if two hardware drivers failed to agree on a new policy before this
- stage, the incompatible hardware shall be shut down, and the user
- informed of this.
-
-The phase is specified in the second argument to the notifier.
-
-The third argument, a void *pointer, points to a struct cpufreq_policy
-consisting of several values, including min, max (the lower and upper
-frequencies (in kHz) of the new policy).
-
-
-2.2 CPUFreq transition notifiers
---------------------------------
-
-These are notified twice for each online CPU in the policy, when the
-CPUfreq driver switches the CPU core frequency and this change has no
-any external implications.
-
-The second argument specifies the phase - CPUFREQ_PRECHANGE or
-CPUFREQ_POSTCHANGE.
-
-The third argument is a struct cpufreq_freqs with the following
-values:
-cpu - number of the affected CPU
-old - old frequency
-new - new frequency
-flags - flags of the cpufreq driver
-
-3. CPUFreq Table Generation with Operating Performance Point (OPP)
-==================================================================
-For details about OPP, see Documentation/power/opp.txt
-
-dev_pm_opp_init_cpufreq_table -
- This function provides a ready to use conversion routine to translate
- the OPP layer's internal information about the available frequencies
- into a format readily providable to cpufreq.
-
- WARNING: Do not use this function in interrupt context.
-
- Example:
- soc_pm_init()
- {
- /* Do things */
- r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
- if (!r)
- policy->freq_table = freq_table;
- /* Do other things */
- }
-
- NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
- addition to CONFIG_PM_OPP.
-
-dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
diff --git a/Documentation/cpu-freq/index.rst b/Documentation/cpu-freq/index.rst
new file mode 100644
index 000000000000..fd81d4f501cc
--- /dev/null
+++ b/Documentation/cpu-freq/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+CPU Frequency and Voltage Scaling Documentation
+===============================================
+
+.. class:: toc-title
+
+ Table of contents
+
+.. toctree::
+ :maxdepth: 2
+
+ core.rst
diff --git a/Documentation/index.rst b/Documentation/index.rst
index a7566ef62411..934206bc1daf 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -102,6 +102,7 @@ needed).
vm/index
bpf/index
misc-devices/index
+ cpu-freq/index
Architecture-specific documentation
-----------------------------------
--
2.17.1
^ permalink raw reply related
* Quotes needed For July Shipments
From: Sales -Jpexcc. @ 2019-07-05 21:39 UTC (permalink / raw)
To: Recipients
Hello dear,
We are in the market for your products after meeting at your stand during last expo.
Please kindly send us your latest catalog and price list so as to start a new project/order as promised during the exhibition.
I would appreciate your response about the above details required so we can revert back to you asap.
Kind regards
Rhema Zoeh
^ permalink raw reply
* [PATCH 3/3] kbuild: add a flag to force absolute path for srctree
From: Masahiro Yamada @ 2019-07-06 3:07 UTC (permalink / raw)
To: linux-kbuild
Cc: Sam Ravnborg, Pawan Gupta, Masahiro Yamada, linux-doc,
linux-kernel, Jonathan Corbet, Michal Marek
In-Reply-To: <20190706030713.6221-1-yamada.masahiro@socionext.com>
In old days, Kbuild always used an absolute path for $(srctree).
Since commit 890676c65d69 ("kbuild: Use relative path when building in
the source tree"), $(srctree) is '.' when not using O=.
Yet, using absolute paths is useful in some cases even without O=, for
instance, to create a cscope file with absolute path tags.
O=. was used as an idiom to force Kbuild to use absolute paths even
when you are building in the source tree.
Since commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any
directory"), Kbuild is too clever to be tricked. Even if you pass O=.
Kbuild notices you are building in the source tree, then use '.' for
$(srctree).
So, "make O=. cscope" is no help to create absolute path tags.
We cannot force one or the other according to commit e93bc1a0cab3
("Revert "kbuild: specify absolute paths for cscope""). Both of
relative path and absolute path have pros and cons.
This commit adds a new flag KBUILD_ABS_SRCTREE to allow users to
choose the absolute path for $(srctree).
"make KBUILD_ABS_SRCTREE=1 cscope" will work as a replacement of
"make O=. cscope".
I added Fixes since that commit broke some users' workflow.
Fixes: 25b146c5b8ce ("kbuild: allow Kbuild to start from any directory")
Reported-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Documentation/kbuild/kbuild.txt | 9 +++++++++
Makefile | 4 ++++
scripts/tags.sh | 3 +--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 7a7e2aa2fab5..3ef42f87f275 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -182,6 +182,15 @@ The output directory is often set using "O=..." on the commandline.
The value can be overridden in which case the default value is ignored.
+KBUILD_ABS_SRCTREE
+--------------------------------------------------
+Kbuild uses a relative path to point to the tree when possible. For instance,
+when building in the source tree, the source tree path is '.'
+
+Setting this flag requests Kbuild to use absolute path to the source tree.
+There are some useful cases to do so, like when generating tag files with
+absolute path entries etc.
+
KBUILD_SIGN_PIN
--------------------------------------------------
This variable allows a passphrase or PIN to be passed to the sign-file
diff --git a/Makefile b/Makefile
index 534a5dc796b1..6dc453f86f00 100644
--- a/Makefile
+++ b/Makefile
@@ -244,6 +244,10 @@ else
building_out_of_srctree := 1
endif
+ifneq ($(KBUILD_ABS_SRCTREE),)
+srctree := $(abs_srctree)
+endif
+
objtree := .
VPATH := $(srctree)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 7fea4044749b..4e18ae5282a6 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -17,8 +17,7 @@ ignore="$(echo "$RCS_FIND_IGNORE" | sed 's|\\||g' )"
# tags and cscope files should also ignore MODVERSION *.mod.c files
ignore="$ignore ( -name *.mod.c ) -prune -o"
-# Do not use full path if we do not use O=.. builds
-# Use make O=. {tags|cscope}
+# Use make KBUILD_ABS_SRCTREE=1 {tags|cscope}
# to force full paths for a non-O= build
if [ "${srctree}" = "." -o -z "${srctree}" ]; then
tree=
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] Documentation: cpu-freq: Convert core.txt file to ReST format
From: Rafael J. Wysocki @ 2019-07-06 7:58 UTC (permalink / raw)
To: Shreeya Patel
Cc: skhan, Rafael J. Wysocki, Viresh Kumar, Jonathan Corbet, Linux PM,
Linux Kernel Mailing List, open list:DOCUMENTATION,
linux-kernel-mentees
In-Reply-To: <20190705210428.8039-1-shreeya.patel23498@gmail.com>
On Fri, Jul 5, 2019 at 11:04 PM Shreeya Patel
<shreeya.patel23498@gmail.com> wrote:
>
> Convert core file to ReST format, in order to allow it to
> be parsed by Sphinx. Make a minor change of correcting the wrong
> function name cpufreq_put_cpu to cpufreq_cpu_put.
> Also create an index.rst file in cpu-freq and add it's entry
> in the main Documentation/index.rst file.
>
> Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
I've said "no" no three previous attempts and this one is not different.
I don't want to have anything .rst in Documentation/cpu-freq/.
There is a *new* admin-guide doc for cpufreq already and what is
missing is a *new* driver-api one.
Thanks!
^ permalink raw reply
* Re: [PATCH 24/43] docs: leds: convert to ReST
From: Mauro Carvalho Chehab @ 2019-07-06 10:41 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Vadim Pasternak, Pavel Machek, Dan Murphy,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, linux-leds, netfilter-devel, coreteam, netdev
In-Reply-To: <0b2a2452-20ca-1651-e03b-a15a8502b028@gmail.com>
Em Fri, 28 Jun 2019 21:01:40 +0200
Jacek Anaszewski <jacek.anaszewski@gmail.com> escreveu:
> Hi Mauro,
>
> On 6/28/19 2:20 PM, Mauro Carvalho Chehab wrote:
> > Rename the leds documentation files to ReST, add an
> > index for them and adjust in order to produce a nice html
> > output via the Sphinx build system.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > ---
> > Documentation/laptops/thinkpad-acpi.txt | 4 +-
> > Documentation/leds/index.rst | 25 ++
> > .../leds/{leds-blinkm.txt => leds-blinkm.rst} | 64 ++---
> > ...s-class-flash.txt => leds-class-flash.rst} | 49 ++--
> > .../leds/{leds-class.txt => leds-class.rst} | 15 +-
> > .../leds/{leds-lm3556.txt => leds-lm3556.rst} | 100 ++++++--
> > .../leds/{leds-lp3944.txt => leds-lp3944.rst} | 23 +-
> > Documentation/leds/leds-lp5521.rst | 115 +++++++++
> > Documentation/leds/leds-lp5521.txt | 101 --------
> > Documentation/leds/leds-lp5523.rst | 147 ++++++++++++
> > Documentation/leds/leds-lp5523.txt | 130 ----------
> > Documentation/leds/leds-lp5562.rst | 137 +++++++++++
> > Documentation/leds/leds-lp5562.txt | 120 ----------
> > Documentation/leds/leds-lp55xx.rst | 224 ++++++++++++++++++
> > Documentation/leds/leds-lp55xx.txt | 194 ---------------
> > Documentation/leds/leds-mlxcpld.rst | 118 +++++++++
> > Documentation/leds/leds-mlxcpld.txt | 110 ---------
> > ...edtrig-oneshot.txt => ledtrig-oneshot.rst} | 11 +-
> > ...ig-transient.txt => ledtrig-transient.rst} | 63 +++--
> > ...edtrig-usbport.txt => ledtrig-usbport.rst} | 11 +-
> > Documentation/leds/{uleds.txt => uleds.rst} | 5 +-
> > MAINTAINERS | 2 +-
> > drivers/leds/trigger/Kconfig | 2 +-
> > drivers/leds/trigger/ledtrig-transient.c | 2 +-
> > net/netfilter/Kconfig | 2 +-
> > 25 files changed, 996 insertions(+), 778 deletions(-)
> > create mode 100644 Documentation/leds/index.rst
> > rename Documentation/leds/{leds-blinkm.txt => leds-blinkm.rst} (57%)
> > rename Documentation/leds/{leds-class-flash.txt => leds-class-flash.rst} (74%)
> > rename Documentation/leds/{leds-class.txt => leds-class.rst} (92%)
> > rename Documentation/leds/{leds-lm3556.txt => leds-lm3556.rst} (70%)
> > rename Documentation/leds/{leds-lp3944.txt => leds-lp3944.rst} (78%)
> > create mode 100644 Documentation/leds/leds-lp5521.rst
> > delete mode 100644 Documentation/leds/leds-lp5521.txt
> > create mode 100644 Documentation/leds/leds-lp5523.rst
> > delete mode 100644 Documentation/leds/leds-lp5523.txt
> > create mode 100644 Documentation/leds/leds-lp5562.rst
> > delete mode 100644 Documentation/leds/leds-lp5562.txt
> > create mode 100644 Documentation/leds/leds-lp55xx.rst
> > delete mode 100644 Documentation/leds/leds-lp55xx.txt
> > create mode 100644 Documentation/leds/leds-mlxcpld.rst
> > delete mode 100644 Documentation/leds/leds-mlxcpld.txt
> > rename Documentation/leds/{ledtrig-oneshot.txt => ledtrig-oneshot.rst} (90%)
> > rename Documentation/leds/{ledtrig-transient.txt => ledtrig-transient.rst} (81%)
> > rename Documentation/leds/{ledtrig-usbport.txt => ledtrig-usbport.rst} (86%)
> > rename Documentation/leds/{uleds.txt => uleds.rst} (95%)
>
> Patches 4/9 and 24/43 applied to the for-next branch of linux-leds.git.
Thanks!
I'll keep this one on my tree:
[PATCH 10/39] docs: leds: add it to the driver-api book
From the other series. If everything goes well, either Jon or I should
be sending upstream by the end of the merge window, after rebasing it,
together with a bunch of other patches touching the driver-api index.rst.
That should hopefully avoid merge conflicts.
Regards,
Mauro
^ permalink raw reply
* Re: [PATCH 01/43] docs: infiniband: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-07-06 11:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Doug Ledford, linux-rdma
In-Reply-To: <20190703180641.GA26394@ziepe.ca>
Em Wed, 3 Jul 2019 15:06:41 -0300
Jason Gunthorpe <jgg@ziepe.ca> escreveu:
> On Fri, Jun 28, 2019 at 09:19:57AM -0300, Mauro Carvalho Chehab wrote:
> > The InfiniBand docs are plain text with no markups.
> > So, all we needed to do were to add the title markups and
> > some markup sequences in order to properly parse tables,
> > lists and literal blocks.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > .../{core_locking.txt => core_locking.rst} | 64 ++++++-----
> > Documentation/infiniband/index.rst | 23 ++++
> > .../infiniband/{ipoib.txt => ipoib.rst} | 24 ++--
> > .../infiniband/{opa_vnic.txt => opa_vnic.rst} | 108 +++++++++---------
> > .../infiniband/{sysfs.txt => sysfs.rst} | 4 +-
> > .../{tag_matching.txt => tag_matching.rst} | 5 +
> > .../infiniband/{user_mad.txt => user_mad.rst} | 33 ++++--
> > .../{user_verbs.txt => user_verbs.rst} | 12 +-
> > drivers/infiniband/core/user_mad.c | 2 +-
> > drivers/infiniband/ulp/ipoib/Kconfig | 2 +-
> > 10 files changed, 174 insertions(+), 103 deletions(-)
> > rename Documentation/infiniband/{core_locking.txt => core_locking.rst} (78%)
> > create mode 100644 Documentation/infiniband/index.rst
> > rename Documentation/infiniband/{ipoib.txt => ipoib.rst} (90%)
> > rename Documentation/infiniband/{opa_vnic.txt => opa_vnic.rst} (63%)
> > rename Documentation/infiniband/{sysfs.txt => sysfs.rst} (69%)
> > rename Documentation/infiniband/{tag_matching.txt => tag_matching.rst} (98%)
> > rename Documentation/infiniband/{user_mad.txt => user_mad.rst} (90%)
> > rename Documentation/infiniband/{user_verbs.txt => user_verbs.rst} (93%)
>
> I'm not sure anymore if I sent a note or not, but this patch was
> already applied to the rdma.git:
>
> commit 97162a1ee8a1735fc7a7159fe08de966d88354ce
> Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Date: Sat Jun 8 23:27:03 2019 -0300
>
> docs: infiniband: convert docs to ReST and rename to *.rst
>
> The InfiniBand docs are plain text with no markups. So, all we needed to
> do were to add the title markups and some markup sequences in order to
> properly parse tables, lists and literal blocks.
>
> At its new index.rst, let's add a :orphan: while this is not linked to the
> main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Ah, ok, thanks!
Not sure why but this one still applies on the top of -next.
Probably just the usual merge noise that happens close to
a new merge window.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 35/39] docs: infiniband: add it to the driver-api bookset
From: Mauro Carvalho Chehab @ 2019-07-06 11:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Doug Ledford, linux-rdma
In-Reply-To: <20190703180802.GA26557@ziepe.ca>
Em Wed, 3 Jul 2019 15:08:02 -0300
Jason Gunthorpe <jgg@ziepe.ca> escreveu:
> On Fri, Jun 28, 2019 at 09:30:28AM -0300, Mauro Carvalho Chehab wrote:
> > While this contains some uAPI stuff, it was intended to be
> > read by a kernel doc. So, let's not move it to a different
> > dir, but, instead, just add it to the driver-api bookset.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Documentation/index.rst | 1 +
> > Documentation/infiniband/index.rst | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index ea33cbbccd9d..e69d2fde7735 100644
> > +++ b/Documentation/index.rst
> > @@ -96,6 +96,7 @@ needed).
> > block/index
> > hid/index
> > iio/index
> > + infiniband/index
> > leds/index
> > media/index
> > networking/index
> > diff --git a/Documentation/infiniband/index.rst b/Documentation/infiniband/index.rst
> > index 22eea64de722..9cd7615438b9 100644
> > +++ b/Documentation/infiniband/index.rst
> > @@ -1,4 +1,4 @@
> > -:orphan:
> > +.. SPDX-License-Identifier: GPL-2.0
> >
> > ==========
> > InfiniBand
>
> Should this one go to the rdma.git as well? It looks like yes
I'm OK if you want to add to rdma.git. However, this will likely rise
conflicts, though, as this series has lots of other patches touching
Documentation/index.rst.
So, I suspect that it would be easier to merge this together with the
other patches via the docs tree, by the end of the merge window.
If you prefer to apply it against your tree, my plan is to do
a final rebase at the second week of the merge window, in order to
avoid such conflicts.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 39/39] docs: gpio: add sysfs interface to the admin-guide
From: Mauro Carvalho Chehab @ 2019-07-06 11:43 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet,
Bartosz Golaszewski, Rafael J. Wysocki, Len Brown, Harry Wei,
Alex Shi, open list:GPIO SUBSYSTEM, ACPI Devel Maling List
In-Reply-To: <CACRpkdbBA612W0x6Y-dwe3E4dhH2ospmn+m2YJ8Sh_Um6XGYhA@mail.gmail.com>
Em Wed, 3 Jul 2019 10:44:38 +0200
Linus Walleij <linus.walleij@linaro.org> escreveu:
> On Fri, Jun 28, 2019 at 2:30 PM Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
>
> > While this is stated as obsoleted, the sysfs interface described
> > there is still valid, and belongs to the admin-guide.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> This doesn't apply to my tree because of dependencies in the
> index
Yeah, this /39 patch series heavily touch the index files.
Better to merge them altogether.
> so I guess it's best if you merge it:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks!
Mauro
>
> Yours,
> Linus Walleij
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 18/39] docs: admin-guide: add kdump documentation into it
From: Mauro Carvalho Chehab @ 2019-07-06 11:46 UTC (permalink / raw)
To: Dave Young
Cc: Alex Shi, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, Jonathan Corbet, Baoquan He, Vivek Goyal,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Harry Wei, Jerry Hoemann, Wim Van Sebroeck, Guenter Roeck,
Russell King, Catalin Marinas, Will Deacon, Yoshinori Sato,
Rich Felker, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, kexec, linuxppc-dev, linux-watchdog,
linux-arm-kernel, linux-sh
In-Reply-To: <20190705055904.GB2790@localhost.localdomain>
Em Fri, 5 Jul 2019 13:59:04 +0800
Dave Young <dyoung@redhat.com> escreveu:
> On 07/05/19 at 11:43am, Alex Shi wrote:
> >
> >
> > 在 2019/6/28 下午8:30, Mauro Carvalho Chehab 写道:
> > > The Kdump documentation describes procedures with admins use
> > > in order to solve issues on their systems.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > > Documentation/admin-guide/bug-hunting.rst | 4 ++--
> > > Documentation/admin-guide/index.rst | 1 +
> > > Documentation/{ => admin-guide}/kdump/gdbmacros.txt | 0
> > > Documentation/{ => admin-guide}/kdump/index.rst | 1 -
> > > Documentation/{ => admin-guide}/kdump/kdump.rst | 0
> > > Documentation/{ => admin-guide}/kdump/vmcoreinfo.rst | 0
> >
> > I am not sure if it's convenience for people to have more levels in docs.
> >
> > But I guess, move archs into a Documentation/arch/ dir should be fine. like Documentation/arch/{x86,arm,arm64,ia64,m68k,s390,powerpc,...}
>
> Alex, moving kdump to admin-guide sounds reasonable to me. I also agree
> with you for those arch dependent files can be moved to
> Documentation/arch/, maybe you are talking about some other patches in
> the series for the arch/?
Alex,
It makes sense for me to have a Documentation/arch directory, and place
the arch-specific docs over there.
There's actually a technical advantage on doing that: Sphinx is dumb
with regards to PDF/LaTeX output: it requires all top documents to be
listed at Documentation/conf.py, under this var:
latex_documents = [
...
]
As it creates one runtime Makefile at Documentation/output per listed
document there. So, the more we group such documents, the less merge
conflicts we'll have at Documentation/conf.py.
Btw, there's a [TECH TOPIC] proposal for KS/2019 meant to discuss
Documentation.
I suspect we could discuss the pros/cons of doing such change there.
My personal view is that we should keep the Documentation/ root dir as
clean as possible as a long term goal.
On the other hand, it makes the path bigger and harder to rename.
On a side note, last time we discussed documentation at KS I remember
I proposed to shortcut "Documentation/" to just "docs/". The consensus
on that time were to keep the big name. I still think that a shorter
one could help people to remind where documentation will be located.
Thanks,
Mauro
^ permalink raw reply
* [PATCH v2] kbuild: get rid of misleading $(AS) from documents
From: Masahiro Yamada @ 2019-07-06 16:25 UTC (permalink / raw)
To: linux-kbuild
Cc: Sam Ravnborg, Masahiro Yamada, linux-doc, linux-kernel,
Jonathan Corbet, Michal Marek
The assembler files in the kernel are *.S instead of *.s, so they must
be preprocessed. Since 'as' of GNU binutils is not able to preprocess,
we always use $(CC) as an assembler driver.
$(AS) is almost unused in Kbuild. As of writing, there is just one place
that directly invokes $(AS).
$ git grep -e '$(AS)' -e '${AS}' -e '$AS' -e '$(AS:' -e '${AS:' -- :^Documentation
drivers/net/wan/Makefile: AS68K = $(AS)
The documentation about *_AFLAGS* sounds like the flags were passed
to $(AS). This is somewhat misleading.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
---
Changes in v2:
- Rephrase without using "assembling"
Documentation/kbuild/kbuild.txt | 5 ++---
Documentation/kbuild/makefiles.txt | 12 ++++++------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 9c230ea71963..2c6188abb213 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -31,12 +31,11 @@ Additional options to the assembler (for built-in and modules).
AFLAGS_MODULE
--------------------------------------------------
-Additional module specific options to use for $(AS).
+Additional assembler options for modules.
AFLAGS_KERNEL
--------------------------------------------------
-Additional options for $(AS) when used for assembler
-code for code that is compiled as built-in.
+Additional assembler options for built-in.
KCFLAGS
--------------------------------------------------
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index d65ad5746f94..895bbbf38a0c 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -306,7 +306,7 @@ more details, with real examples.
variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
entire tree.
- asflags-y specifies options for assembling with $(AS).
+ asflags-y specifies assembler options.
Example:
#arch/sparc/kernel/Makefile
@@ -441,7 +441,7 @@ more details, with real examples.
as-instr checks if the assembler reports a specific instruction
and then outputs either option1 or option2
C escapes are supported in the test instruction
- Note: as-instr-option uses KBUILD_AFLAGS for $(AS) options
+ Note: as-instr-option uses KBUILD_AFLAGS for assembler options
cc-option
cc-option is used to check if $(CC) supports a given option, and if
@@ -814,7 +814,7 @@ When kbuild executes, the following steps are followed (roughly):
In this example, the binary $(obj)/image is a binary version of
vmlinux. The usage of $(call if_changed,xxx) will be described later.
- KBUILD_AFLAGS $(AS) assembler flags
+ KBUILD_AFLAGS assembler flags
Default value - see top level Makefile
Append or modify as required per architecture.
@@ -853,15 +853,15 @@ When kbuild executes, the following steps are followed (roughly):
The first example utilises the trick that a config option expands
to 'y' when selected.
- KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in
+ KBUILD_AFLAGS_KERNEL Assembler options specific for built-in
$(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
resident kernel code.
- KBUILD_AFLAGS_MODULE Options for $(AS) when building modules
+ KBUILD_AFLAGS_MODULE Assembler options specific for modules
$(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
- are used for $(AS).
+ are used for assembler.
From commandline AFLAGS_MODULE shall be used (see kbuild.txt).
KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in
--
2.17.1
^ permalink raw reply related
* [PATCH] docs: automarkup.py: ignore exceptions when seeking for xrefs
From: Mauro Carvalho Chehab @ 2019-07-06 16:28 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
When using the automarkup extension with:
make pdfdocs
without passing an specific book, the code will raise an exception:
File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 86, in auto_markup
node.parent.replace(node, markup_funcs(name, app, node))
File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 59, in markup_funcs
'function', target, pxref, lit_text)
File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/domains/c.py", line 308, in resolve_xref
contnode, target)
File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/util/nodes.py", line 450, in make_refnode
'#' + targetid)
File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 159, in get_relative_uri
return self.get_target_uri(to, typ)
File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 152, in get_target_uri
raise NoUri
sphinx.environment.NoUri
This happens because not all references will belong to a single
PDF/LaTeX document.
Better to just ignore those than breaking Sphinx build.
Fixes: d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/sphinx/automarkup.py | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py
index b300cf129869..dba14374f269 100644
--- a/Documentation/sphinx/automarkup.py
+++ b/Documentation/sphinx/automarkup.py
@@ -55,8 +55,13 @@ def markup_funcs(docname, app, node):
reftype = 'function',
reftarget = target, modname = None,
classname = None)
- xref = cdom.resolve_xref(app.env, docname, app.builder,
- 'function', target, pxref, lit_text)
+
+ # When building pdf documents, this may raise a NoUri exception
+ try:
+ xref = cdom.resolve_xref(app.env, docname, app.builder,
+ 'function', target, pxref, lit_text)
+ except:
+ xref = None
#
# Toss the xref into the list if we got it; otherwise just put
# the function text.
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] Documentation: cpu-freq: Convert core.txt file to ReST format
From: Shreeya Patel @ 2019-07-06 19:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: skhan, Rafael J. Wysocki, Viresh Kumar, Jonathan Corbet, Linux PM,
Linux Kernel Mailing List, open list:DOCUMENTATION,
linux-kernel-mentees
In-Reply-To: <CAJZ5v0hovK+BY0kozGvkyCgR5CFHpZUu71BZRjUUdCYV8fM5Hg@mail.gmail.com>
On Sat, 2019-07-06 at 09:58 +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 5, 2019 at 11:04 PM Shreeya Patel
> <shreeya.patel23498@gmail.com> wrote:
> >
> > Convert core file to ReST format, in order to allow it to
> > be parsed by Sphinx. Make a minor change of correcting the wrong
> > function name cpufreq_put_cpu to cpufreq_cpu_put.
> > Also create an index.rst file in cpu-freq and add it's entry
> > in the main Documentation/index.rst file.
> >
> > Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
>
> I've said "no" no three previous attempts and this one is not
> different.
>
Sorry, I was not knowing about it.
> I don't want to have anything .rst in Documentation/cpu-freq/.
>
> There is a *new* admin-guide doc for cpufreq already and what is
> missing is a *new* driver-api one.
>
Yes I saw that but it didn't include all the details given in
Documentation/cpu-freq hence I thought of sending this initial patch.
Thanks
> Thanks!
^ permalink raw reply
* [PATCH] doc: email-clients miscellaneous fixes
From: Federico Vaga @ 2019-07-06 21:01 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Federico Vaga, linux-doc, linux-kernel
Fixed some style inconsistencies and remove old statement referring to
kmail missing feature (saving email from the view window is possible).
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
Documentation/process/email-clients.rst | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst
index 07faa5457bcb..5273d06c8ff6 100644
--- a/Documentation/process/email-clients.rst
+++ b/Documentation/process/email-clients.rst
@@ -40,7 +40,7 @@ Emailed patches should be in ASCII or UTF-8 encoding only.
If you configure your email client to send emails with UTF-8 encoding,
you avoid some possible charset problems.
-Email clients should generate and maintain References: or In-Reply-To:
+Email clients should generate and maintain "References:" or "In-Reply-To:"
headers so that mail threading is not broken.
Copy-and-paste (or cut-and-paste) usually does not work for patches
@@ -89,7 +89,7 @@ Claws Mail (GUI)
Works. Some people use this successfully for patches.
-To insert a patch use :menuselection:`Message-->Insert` File (:kbd:`CTRL-I`)
+To insert a patch use :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`)
or an external editor.
If the inserted patch has to be edited in the Claws composition window
@@ -132,8 +132,8 @@ wrapping.
At the bottom of your email, put the commonly-used patch delimiter before
inserting your patch: three hyphens (``---``).
-Then from the :menuselection:`Message` menu item, select insert file and
-choose your patch.
+Then from the :menuselection:`Message` menu item, select
+:menuselection:`insert file` and choose your patch.
As an added bonus you can customise the message creation toolbar menu
and put the :menuselection:`insert file` icon there.
@@ -149,18 +149,16 @@ patches so do not GPG sign them. Signing patches that have been inserted
as inlined text will make them tricky to extract from their 7-bit encoding.
If you absolutely must send patches as attachments instead of inlining
-them as text, right click on the attachment and select properties, and
-highlight :menuselection:`Suggest automatic display` to make the attachment
+them as text, right click on the attachment and select :menuselection:`properties`,
+and highlight :menuselection:`Suggest automatic display` to make the attachment
inlined to make it more viewable.
When saving patches that are sent as inlined text, select the email that
contains the patch from the message list pane, right click and select
:menuselection:`save as`. You can use the whole email unmodified as a patch
-if it was properly composed. There is no option currently to save the email
-when you are actually viewing it in its own window -- there has been a request
-filed at kmail's bugzilla and hopefully this will be addressed. Emails are
-saved as read-write for user only so you will have to chmod them to make them
-group and world readable if you copy them elsewhere.
+if it was properly composed. Emails are saved as read-write for user only so
+you will have to chmod them to make them group and world readable if you copy
+them elsewhere.
Lotus Notes (GUI)
*****************
--
2.21.0
^ permalink raw reply related
* [PATCH 0/3] [PATCH 0/3] Documentation: virtual: convert files from .txt to
From: Luke Nowakowski-Krijger @ 2019-07-06 21:38 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Converted a few documents in virtual and virtual/kvm to .rst format.
Also added toctree hooks wherever there were .rst files. Adding hooks to
the main doc tree should be in another patch series once there are more
files in the directory.
After confirming with the appropriate lists that all the
Documentation/virtual/* files are not obsolete I will continue
converting the rest of the .txt files to .rst.
Luke Nowakowski-Krijger (3):
Documentation: virtual: Add toctree hooks
Documentation: kvm: Convert cpuid.txt to .rst
Documentation: virtual: Convert paravirt_ops.txt to .rst
Documentation/virtual/index.rst | 18 ++++
Documentation/virtual/kvm/cpuid.rst | 99 +++++++++++++++++++
Documentation/virtual/kvm/cpuid.txt | 83 ----------------
Documentation/virtual/kvm/index.rst | 12 +++
.../{paravirt_ops.txt => paravirt_ops.rst} | 19 ++--
5 files changed, 140 insertions(+), 91 deletions(-)
create mode 100644 Documentation/virtual/index.rst
create mode 100644 Documentation/virtual/kvm/cpuid.rst
delete mode 100644 Documentation/virtual/kvm/cpuid.txt
create mode 100644 Documentation/virtual/kvm/index.rst
rename Documentation/virtual/{paravirt_ops.txt => paravirt_ops.rst} (65%)
--
2.20.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox