Re: doc: Italian translation
On Monday, 28 May 2018 15:08:28 CEST Jonathan Corbet wrote: > On Sun, 27 May 2018 16:55:55 +0200 > > Federico Vaga wrote: > > here the doc-guide translated in Italian. This set of patches > > includes some minor changes to the main one. The idea of this > > first set of patches is also to adjust the structure and our > > expectations. > > I've only done a quick scan so far. It looks reasonable, but I have > a couple of requests: > > - Please include a proper changelog with each patch describing what > the patch does and why. Otherwise I'll have to fill them in, and > that makes me grumpy...:) Ok > - You might as well add a MAINTAINERS entry. The other > translations don't have them, but they should. Ok > - For extra credit: it's time to move the translations out of the >top-level index into an index.rst in the translations directory. > Then the top-level file can have a single pointer to the > translations. I completely agree on this point. I can prepare a patch that does it. > > We tried to translate everything in **Italian**; which means that > > we avoided imported English words wherever there is the > > possibility to use the Italian ones. Of course, this is not > > always possible, or worst doing the translation make it less > > clear, for example the word "file". > > "We"? Is there somebody else's work represented here too? If so, > they should appear in the signoff chain (or as a Co-developed-by > credit). I did, in patch 3/5 and 4/5 there is Alessia as "signed-off" (in CC here). > > Another point. I noticed that the disclaimer for other > > translations is in English, so I did the same. But actually > > shouldn't be in Italian, since that page will be read by Italian > > speakers? > > Perhaps, though part of the idea is to give the English speakers, > too, some vague clue of what they're looking at. Make sense. I will keep it like this then. Thanks > > Thanks, > > jon -- Federico Vaga http://www.federicovaga.it/ -- 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: doc: Italian translation
On Sun, 27 May 2018 16:55:55 +0200 Federico Vaga wrote: > here the doc-guide translated in Italian. This set of patches includes > some minor changes to the main one. The idea of this first set of patches > is also to adjust the structure and our expectations. I've only done a quick scan so far. It looks reasonable, but I have a couple of requests: - Please include a proper changelog with each patch describing what the patch does and why. Otherwise I'll have to fill them in, and that makes me grumpy...:) - You might as well add a MAINTAINERS entry. The other translations don't have them, but they should. - For extra credit: it's time to move the translations out of the top-level index into an index.rst in the translations directory. Then the top-level file can have a single pointer to the translations. > We tried to translate everything in **Italian**; which means that we avoided > imported English words wherever there is the possibility to use the Italian > ones. Of course, this is not always possible, or worst doing the translation > make it less clear, for example the word "file". "We"? Is there somebody else's work represented here too? If so, they should appear in the signoff chain (or as a Co-developed-by credit). > Another point. I noticed that the disclaimer for other translations is > in English, so I did the same. But actually shouldn't be in Italian, since > that page will be read by Italian speakers? Perhaps, though part of the idea is to give the English speakers, too, some vague clue of what they're looking at. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2
On Thu, May 24, 2018 at 02:55:25PM -0400, Waiman Long wrote: > On 05/24/2018 11:43 AM, Peter Zijlstra wrote: > > I'm confused... why exactly do we have both domain and load_balance ? > > The domain is for partitioning the CPUs only. It doesn't change the load > balancing state. So the load_balance flag is still need to turn on and > off load balancing. OK, so we have to two boolean flags, giving 4 possible states. Lets just go through them one by on: A) domain:0 load_balance:0 -- we have no exclusive domain, but have load-balancing disabled across them. AFAICT this should be an invalid state. B) domain:0 load_balance:1 -- we have no exclusive domain, but have load-balancing enabled. AFAICT this is the default state and is a no-op. C) domain:1 load_balance:0 -- we have an exclusive domain, and have load-balancing disabled across it. This is, AFAICT, identical to having a bunch of sub/sibling groups each with a single CPU domain. D) domain:1 load_balance:1 -- we have an exclusive domain, and have load-balancing enabled. This is a partition. Now, I think I've overlooked the fact that load_balance==1 only really means something when the parent's load_balance==0, but I'm not sure that really changes anything. So, afaict, the above only have two useful states: B and D. Which again raises the question, why two knobs? What useful configurations does it allow? -- 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 v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
W dniu 28.05.2018 o 11:32, Marcus Folkesson pisze: > Hi Andrzej, > > Thank you for reviewing. > > On Mon, May 28, 2018 at 11:12:27AM +0200, Andrzej Pietrasiewicz wrote: >> W dniu 28.05.2018 o 10:38, Marcus Folkesson pisze: >>> Hi Andrzej, >>> >>> On Mon, May 28, 2018 at 09:04:51AM +0200, Andrzej Pietrasiewicz wrote: Mi Marcus, W dniu 26.05.2018 o 23:19, Marcus Folkesson pisze: > Chip Card Interface Device (CCID) protocol is a USB protocol that > allows a smartcard device to be connected to a computer via a card > reader using a standard USB interface, without the need for each > manufacturer > of smartcards to provide its own reader or protocol. > > This gadget driver makes Linux show up as a CCID device to the host and > let a > userspace daemon act as the smartcard. > > This is useful when the Linux gadget itself should act as a cryptographic > device or forward APDUs to an embedded smartcard device. > > Signed-off-by: Marcus Folkesson > --- > > +config USB_CONFIGFS_CCID > + bool "Chip Card Interface Device (CCID)" > + depends on USB_CONFIGFS > + select USB_F_CCID > + help > + The CCID function driver provides generic emulation of a > + Chip Card Interface Device (CCID). > + > + You will need a user space server talking to /dev/ccidg*, > + since the kernel itself does not implement CCID/TPDU/APDU > + protocol. Your function needs a userspace daemon to work. It seems you want to use FunctionFS for such a purpose instead of creating a new function. Andrzej >>> > + since the kernel itself does not implement CCID/TPDU/APDU >>> Oops, the driver does handle CCID. >> >> Which parts of code do this handling? > > My bad, I was thinking about the USB descriptors and endpoints setup. > That is of cause not part of the CCID protocol. > >> >> Is there any kind of state machine usual for protocols? >> If the protocol is stateless then isn't it just a data format then? > > The protocol is stateless. > >> >> Which part of this handling must be done in kernel and why? >> >> Does the said handling do anything other than forwarding the >> traffic between USB and a character device? > > No, it forward the CCID messages to the character device to be handled > by the application. > >> My opinion is: this wants to be done with FunctionFS. Andrzej -- 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 v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
Hi Andrzej, Thank you for reviewing. On Mon, May 28, 2018 at 11:12:27AM +0200, Andrzej Pietrasiewicz wrote: > W dniu 28.05.2018 o 10:38, Marcus Folkesson pisze: > > Hi Andrzej, > > > > On Mon, May 28, 2018 at 09:04:51AM +0200, Andrzej Pietrasiewicz wrote: > >> Mi Marcus, > >> > >> W dniu 26.05.2018 o 23:19, Marcus Folkesson pisze: > >>> Chip Card Interface Device (CCID) protocol is a USB protocol that > >>> allows a smartcard device to be connected to a computer via a card > >>> reader using a standard USB interface, without the need for each > >>> manufacturer > >>> of smartcards to provide its own reader or protocol. > >>> > >>> This gadget driver makes Linux show up as a CCID device to the host and > >>> let a > >>> userspace daemon act as the smartcard. > >>> > >>> This is useful when the Linux gadget itself should act as a cryptographic > >>> device or forward APDUs to an embedded smartcard device. > >>> > >>> Signed-off-by: Marcus Folkesson > >>> --- > >> > >>> > >>> +config USB_CONFIGFS_CCID > >>> + bool "Chip Card Interface Device (CCID)" > >>> + depends on USB_CONFIGFS > >>> + select USB_F_CCID > >>> + help > >>> + The CCID function driver provides generic emulation of a > >>> + Chip Card Interface Device (CCID). > >>> + > >>> + You will need a user space server talking to /dev/ccidg*, > >>> + since the kernel itself does not implement CCID/TPDU/APDU > >>> + protocol. > >> > >> Your function needs a userspace daemon to work. > >> It seems you want to use FunctionFS for such a purpose > >> instead of creating a new function. > >> > >> Andrzej > > > >>> + since the kernel itself does not implement CCID/TPDU/APDU > > Oops, the driver does handle CCID. > > Which parts of code do this handling? My bad, I was thinking about the USB descriptors and endpoints setup. That is of cause not part of the CCID protocol. > > Is there any kind of state machine usual for protocols? > If the protocol is stateless then isn't it just a data format then? The protocol is stateless. > > Which part of this handling must be done in kernel and why? > > Does the said handling do anything other than forwarding the > traffic between USB and a character device? No, it forward the CCID messages to the character device to be handled by the application. > > What is the character device used for? I know: read, write and poll. > But why? To do what? It is used for the application to fetch, interpret and then perform actions depending on commands. > > > > > Well, yes, It needs an application that perform the "smartcard operations", > > such as > > generate keys or sign data, as this depends on how it should be used. > > > > The actual smartcard operations could for example be in software, > > use a crypto engine in SoC or external HSM (Hardware Security Module). > > > > Without the application, the gadget shows up as a smart card reader > > with an unconnected smartcard. > > > > Does showing up as anything require anything other than merely > providing USB descriptors? I guess. > > Andrzej Thank you, Marcus -- 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 v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
W dniu 28.05.2018 o 10:38, Marcus Folkesson pisze: > Hi Andrzej, > > On Mon, May 28, 2018 at 09:04:51AM +0200, Andrzej Pietrasiewicz wrote: >> Mi Marcus, >> >> W dniu 26.05.2018 o 23:19, Marcus Folkesson pisze: >>> Chip Card Interface Device (CCID) protocol is a USB protocol that >>> allows a smartcard device to be connected to a computer via a card >>> reader using a standard USB interface, without the need for each >>> manufacturer >>> of smartcards to provide its own reader or protocol. >>> >>> This gadget driver makes Linux show up as a CCID device to the host and let >>> a >>> userspace daemon act as the smartcard. >>> >>> This is useful when the Linux gadget itself should act as a cryptographic >>> device or forward APDUs to an embedded smartcard device. >>> >>> Signed-off-by: Marcus Folkesson >>> --- >> >>> >>> +config USB_CONFIGFS_CCID >>> + bool "Chip Card Interface Device (CCID)" >>> + depends on USB_CONFIGFS >>> + select USB_F_CCID >>> + help >>> + The CCID function driver provides generic emulation of a >>> + Chip Card Interface Device (CCID). >>> + >>> + You will need a user space server talking to /dev/ccidg*, >>> + since the kernel itself does not implement CCID/TPDU/APDU >>> + protocol. >> >> Your function needs a userspace daemon to work. >> It seems you want to use FunctionFS for such a purpose >> instead of creating a new function. >> >> Andrzej > >>> + since the kernel itself does not implement CCID/TPDU/APDU > Oops, the driver does handle CCID. Which parts of code do this handling? Is there any kind of state machine usual for protocols? If the protocol is stateless then isn't it just a data format then? Which part of this handling must be done in kernel and why? Does the said handling do anything other than forwarding the traffic between USB and a character device? What is the character device used for? I know: read, write and poll. But why? To do what? > > Well, yes, It needs an application that perform the "smartcard operations", > such as > generate keys or sign data, as this depends on how it should be used. > > The actual smartcard operations could for example be in software, > use a crypto engine in SoC or external HSM (Hardware Security Module). > > Without the application, the gadget shows up as a smart card reader > with an unconnected smartcard. > Does showing up as anything require anything other than merely providing USB descriptors? Andrzej -- 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
[RFT v3 2/4] perf script python: Add addr into perf sample dict
ARM CoreSight auxtrace uses 'sample->addr' to record the target address for branch instructions, so the data of 'sample->addr' is required for tracing data analysis. This commit collects data of 'sample->addr' into perf sample dict, finally can be used for python script for parsing event. Signed-off-by: Leo Yan --- tools/perf/util/scripting-engines/trace-event-python.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c index 10dd5fc..7f8afac 100644 --- a/tools/perf/util/scripting-engines/trace-event-python.c +++ b/tools/perf/util/scripting-engines/trace-event-python.c @@ -531,6 +531,8 @@ static PyObject *get_perf_sample_dict(struct perf_sample *sample, PyLong_FromUnsignedLongLong(sample->period)); pydict_set_item_string_decref(dict_sample, "phys_addr", PyLong_FromUnsignedLongLong(sample->phys_addr)); + pydict_set_item_string_decref(dict_sample, "addr", + PyLong_FromUnsignedLongLong(sample->addr)); set_sample_read_in_dict(dict_sample, sample, evsel); pydict_set_item_string_decref(dict, "sample", dict_sample); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT v3 3/4] perf script python: Add script for CoreSight trace disassembler
This commit adds python script to parse CoreSight tracing event and
use command 'objdump' for disassembled lines, finally we can generate
readable program execution flow for reviewing tracing data.
The script receives CoreSight tracing packet with below format:
++++
packet(n):|addr|ip |cpu |
++++
packet(n+1): |addr|ip |cpu |
++++
packet::ip is the last address of current branch instruction and
packet::addr presents the start address of the next coming branch
instruction. So for one branch instruction which starts in packet(n),
its execution flow starts from packet(n)::addr and it stops at
packet(n+1)::ip. As results we need to combine the two continuous
packets to generate the instruction range, this is the rationale for the
script implementation:
[ sample(n)::addr .. sample(n+1)::ip ]
Credits to Tor Jeremiassen who have written the script skeleton and
provides the ideas for reading symbol file according to build-id,
creating memory map for dso and basic packet handling. Mathieu Poirier
contributed fixes for build-id and memory map bugs. The detailed
development history for this script you can find from [1]. Based on Tor
and Mathieu work, the script is updated samples handling for the
corrected sample format. Another minor enhancement is to support for
without build-id case, the script can parse kernel symbols with option
'-k' for vmlinux file path.
[1]
https://github.com/Linaro/perf-opencsd/commits/perf-opencsd-v4.15/tools/perf/scripts/python/cs-trace-disasm.py
Co-authored-by: Tor Jeremiassen
Co-authored-by: Mathieu Poirier
Signed-off-by: Leo Yan
---
tools/perf/scripts/python/arm-cs-trace-disasm.py | 235 +++
1 file changed, 235 insertions(+)
create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py
diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py
b/tools/perf/scripts/python/arm-cs-trace-disasm.py
new file mode 100644
index 000..1239ab4
--- /dev/null
+++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
@@ -0,0 +1,235 @@
+# arm-cs-trace-disasm.py: ARM CoreSight Trace Dump With Disassember
+# SPDX-License-Identifier: GPL-2.0
+#
+# Tor Jeremiassen is original author who wrote script
+# skeleton, Mathieu Poirier contributed
+# fixes for build-id and memory map; Leo Yan
+# updated the packet parsing with new samples format.
+
+import os
+import sys
+import re
+from subprocess import *
+from optparse import OptionParser, make_option
+
+# Command line parsing
+
+option_list = [
+ # formatting options for the bottom entry of the stack
+ make_option("-k", "--vmlinux", dest="vmlinux_name",
+ help="Set path to vmlinux file"),
+ make_option("-d", "--objdump", dest="objdump_name",
+ help="Set path to objdump executable file"),
+ make_option("-v", "--verbose", dest="verbose",
+ action="store_true", default=False,
+ help="Enable debugging log")
+]
+
+parser = OptionParser(option_list=option_list)
+(options, args) = parser.parse_args()
+
+if (options.objdump_name == None):
+ sys.exit("No objdump executable file specified - use -d or --objdump
option")
+
+# Initialize global dicts and regular expression
+
+build_ids = dict()
+mmaps = dict()
+disasm_cache = dict()
+cpu_data = dict()
+disasm_re = re.compile("^\s*([0-9a-fA-F]+):")
+disasm_func_re = re.compile("^\s*([0-9a-fA-F]+)\s\<.*\>:")
+cache_size = 32*1024
+prev_cpu = -1
+
+def parse_buildid():
+ global build_ids
+
+ buildid_regex = "([a-fA-f0-9]+)[ \t]([^ \n]+)"
+ buildid_re = re.compile(buildid_regex)
+
+ results = check_output(["perf", "buildid-list"]).split('\n');
+ for line in results:
+ m = buildid_re.search(line)
+ if (m == None):
+ continue;
+
+ id_name = m.group(2)
+ id_num = m.group(1)
+
+ if (id_name == "[kernel.kallsyms]") :
+ append = "/kallsyms"
+ elif (id_name == "[vdso]") :
+ append = "/vdso"
+ else:
+ append = "/elf"
+
+ build_ids[id_name] = os.environ['PERF_BUILDID_DIR'] + \
+ "/" + id_name + "/" + id_num + append;
+ # Replace duplicate slash chars to single slash char
+ build_ids[id_name] = build_ids[id_name].replace('//', '/', 1)
+
+ if ((options.vmlinux_name == None) and ("[kernel.kallsyms]" in
build_ids)):
+ print "kallsyms cannot be used to dump assembler"
+
+ # Set vmlinux path to replace kallsyms file, if without buildid we still
+ # can use vmlinux to prase kernel symbols
+ if ((options.vmlinux_name != None)):
+ bui
[RFT v3 4/4] coresight: Document for CoreSight trace disassembler
This commit documents CoreSight trace disassembler usage and gives example for it. Signed-off-by: Leo Yan --- Documentation/trace/coresight.txt | 52 +++ 1 file changed, 52 insertions(+) diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt index 6f0120c..b8f2359 100644 --- a/Documentation/trace/coresight.txt +++ b/Documentation/trace/coresight.txt @@ -381,3 +381,55 @@ sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tuto $ taskset -c 2 ./sort_autofdo Bubble sorting array of 3 elements 5806 ms + + +Tracing data disassembler +- + +'perf script' supports to use script to parse tracing packet and rely on +'objdump' for disassembled lines, this can convert tracing data to readable +program execution flow for easily reviewing tracing data. + +The CoreSight trace disassembler is located in the folder: +tools/perf/scripts/python/arm-cs-trace-disasm.py. This script support below +options: + + -d, --objdump: Set path to objdump executable, this option is + mandatory. + -k, --vmlinux: Set path to vmlinux file. + -v, --verbose: Enable debugging log, after enable this option the + script dumps every event data. + +Below is one example for using python script to dump CoreSight trace +disassembler: + + $ perf script -s arm-cs-trace-disasm.py -i perf.data \ + -F cpu,event,ip,addr,sym -- -d objdump -k ./vmlinux > cs-disasm.log + +Below is one example for the disassembler log: + +ARM CoreSight Trace Data Assembler Dump + 08a5f2dc : + 08a5f2dc: 34a0cbz w0, 08a5f2f0 + 08a5f2f0 : + 08a5f2f0: f9400260ldr x0, [x19] + 08a5f2f4: d5033f9fdsb sy + 08a5f2f8: 913ec000add x0, x0, #0xfb0 + 08a5f2fc: b91fstr wzr, [x0] + 08a5f300: f9400bf3ldr x19, [sp, #16] + 08a5f304: a8c27bfdldp x29, x30, [sp], #32 + 08a5f308: d65f03c0ret + 08a5fa18 : + 08a5fa18: 1425b 08a5faac + 08a5faac : + 08a5faac: b9406261ldr w1, [x19, #96] + 08a5fab0: 52800015mov w21, #0x0 // #0 + 08a5fab4: f901ca61str x1, [x19, #912] + 08a5fab8: 2a1503e0mov w0, w21 + 08a5fabc: 3940e261ldrbw1, [x19, #56] + 08a5fac0: f901ce61str x1, [x19, #920] + 08a5fac4: a94153f3ldp x19, x20, [sp, #16] + 08a5fac8: a9425bf5ldp x21, x22, [sp, #32] + 08a5facc: a94363f7ldp x23, x24, [sp, #48] + 08a5fad0: a8c47bfdldp x29, x30, [sp], #64 + 08a5fad4: d65f03c0ret -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT v3 0/4] Perf script: Add python script for CoreSight trace disassembler
This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.
Patch 0001 is one fixing patch to generate samples for the start packet
and exception packets.
Patch 0002 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.
Patch 0003 is to add python script for trace disassembler.
Patch 0004 is to add doc to explain python script usage and give
example for it.
This patch series has been rebased on acme git tree [1] with the commit
19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and tested
on Hikey (ARM64 octa CA53 cores).
In this version the script has no dependency on ARM64 platform and is
expected to support ARM32 platform, but I am lacking ARM32 platform for
testing on it, so firstly upstream to support ARM64 platform.
This patch series is firstly to support 'per-thread' recording tracing
data, but we also need to verify the script can dump trace disassembler
CPU wide tracing and kernel panic kdump tracing data. I also verified
this patch series which can work with kernel panic kdump tracing data,
because Mathieu is working on CPU wide tracing related work, so after
this we need to retest for CPU wide tracing and kdump tracing to ensure
the python script can handle well for all cases.
You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases.
Changes from v2:
* Synced with Rob for handling CS_ETM_TRACE_ON packet, so refined 0001
patch according to dicussion;
* Minor cleanup and fixes in 0003 patch for python script: remove 'svc'
checking.
Changes from v1:
* According to Mike and Rob suggestion, add the fixing to generate samples
for the start packet and exception packets.
* Simplify the python script to remove the exception prediction algorithm,
we can rely on the sane exception packets for disassembler.
Leo Yan (4):
perf cs-etm: Generate branch sample for missed packets
perf script python: Add addr into perf sample dict
perf script python: Add script for CoreSight trace disassembler
coresight: Document for CoreSight trace disassembler
Documentation/trace/coresight.txt | 52 +
tools/perf/scripts/python/arm-cs-trace-disasm.py | 235 +
tools/perf/util/cs-etm.c | 93 ++--
.../util/scripting-engines/trace-event-python.c| 2 +
4 files changed, 362 insertions(+), 20 deletions(-)
create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
traces") reworks the samples generation flow from CoreSight trace to
match the correct format so Perf report tool can display the samples
properly.
But the change has side effect for branch packet handling, it only
generate branch samples by checking previous packet flag
'last_instr_taken_branch' is true, this results in below three kinds
packets are missed to generate branch samples:
- The start tracing packet at the beginning of tracing data;
- The exception handling packet;
- If one CS_ETM_TRACE_ON packet is inserted, we also miss to handle it
for branch samples. CS_ETM_TRACE_ON packet itself can give the info
that there have a discontinuity in the trace, on the other hand we
also miss to generate proper branch sample for packets before and
after CS_ETM_TRACE_ON packet.
This patch is to add branch sample handling for up three kinds packets:
- In function cs_etm__sample(), check if 'prev_packet->sample_type' is
zero and in this case it generates branch sample for the start tracing
packet; furthermore, we also need to handle the condition for
prev_packet::end_addr is zero in the cs_etm__last_executed_instr();
- In function cs_etm__sample(), check if 'prev_packet->exc' is true and
generate branch sample for exception handling packet;
- If there has one CS_ETM_TRACE_ON packet is coming, we firstly generate
branch sample in the function cs_etm__flush(), this can save complete
info for the previous CS_ETM_RANGE packet just before CS_ETM_TRACE_ON
packet. We also generate branch sample for the new CS_ETM_RANGE
packet after CS_ETM_TRACE_ON packet, this have two purposes, the
first one purpose is to save the info for the new CS_ETM_RANGE packet,
the second purpose is to save CS_ETM_TRACE_ON packet info so we can
have hint for a discontinuity in the trace.
For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
the decoder layer as dummy value. This patch is to convert these
values to zeros for more readable; this is accomplished by functions
cs_etm__last_executed_instr() and cs_etm__first_executed_instr(). The
later one is a new function introduced by this patch.
Reviewed-by: Robert Walker
Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 93 +---
1 file changed, 73 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..8418173 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,20 @@ static inline void cs_etm__reset_last_branch_rb(struct
cs_etm_queue *etmq)
static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
{
/*
+* The packet is the start tracing packet if the end_addr is zero,
+* returns 0 for this case.
+*/
+ if (!packet->end_addr)
+ return 0;
+
+ /*
+* The packet is the CS_ETM_TRACE_ON packet if the end_addr is
+* magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
+*/
+ if (packet->end_addr == 0xdeadbeefdeadbeefUL)
+ return 0;
+
+ /*
* The packet records the execution range with an exclusive end address
*
* A64 instructions are constant size, so the last executed
@@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct
cs_etm_packet *packet)
return packet->end_addr - A64_INSTR_SIZE;
}
+static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
+{
+ /*
+* The packet is the CS_ETM_TRACE_ON packet if the start_addr is
+* magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
+*/
+ if (packet->start_addr == 0xdeadbeefdeadbeefUL)
+ return 0;
+
+ return packet->start_addr;
+}
+
static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
{
/*
@@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct
cs_etm_queue *etmq)
be = &bs->entries[etmq->last_branch_pos];
be->from = cs_etm__last_executed_instr(etmq->prev_packet);
- be->to = etmq->packet->start_addr;
+ be->to = cs_etm__first_executed_instr(etmq->packet);
/* No support for mispredict */
be->flags.mispred = 0;
be->flags.predicted = 1;
@@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue
*etmq)
sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
sample.pid = etmq->pid;
sample.tid = etmq->tid;
- sample.addr = etmq->packet->start_addr;
+ sample.addr = cs_etm__first_executed_instr(etmq->packet);
sample.id = etmq->etm->branches_id;
sample.stream_id = etmq->etm->branches_id;
sample.period = 1;
Re: [PATCH v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
Hi Andrzej, On Mon, May 28, 2018 at 09:04:51AM +0200, Andrzej Pietrasiewicz wrote: > Mi Marcus, > > W dniu 26.05.2018 o 23:19, Marcus Folkesson pisze: > > Chip Card Interface Device (CCID) protocol is a USB protocol that > > allows a smartcard device to be connected to a computer via a card > > reader using a standard USB interface, without the need for each > > manufacturer > > of smartcards to provide its own reader or protocol. > > > > This gadget driver makes Linux show up as a CCID device to the host and let > > a > > userspace daemon act as the smartcard. > > > > This is useful when the Linux gadget itself should act as a cryptographic > > device or forward APDUs to an embedded smartcard device. > > > > Signed-off-by: Marcus Folkesson > > --- > > > > > +config USB_CONFIGFS_CCID > > + bool "Chip Card Interface Device (CCID)" > > + depends on USB_CONFIGFS > > + select USB_F_CCID > > + help > > + The CCID function driver provides generic emulation of a > > + Chip Card Interface Device (CCID). > > + > > + You will need a user space server talking to /dev/ccidg*, > > + since the kernel itself does not implement CCID/TPDU/APDU > > + protocol. > > Your function needs a userspace daemon to work. > It seems you want to use FunctionFS for such a purpose > instead of creating a new function. > > Andrzej > > + since the kernel itself does not implement CCID/TPDU/APDU Oops, the driver does handle CCID. Well, yes, It needs an application that perform the "smartcard operations", such as generate keys or sign data, as this depends on how it should be used. The actual smartcard operations could for example be in software, use a crypto engine in SoC or external HSM (Hardware Security Module). Without the application, the gadget shows up as a smart card reader with an unconnected smartcard. I guess it could be accomplished with FunctionFS as well. Best regards Marcus Folkesson -- 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 v2 2/3] Documentation: usb: add documentation for USB CCID Gadget Device
Hi Randy, On Sun, May 27, 2018 at 04:36:24PM -0700, Randy Dunlap wrote: > Hi, > > I have a few documentation comments below... > > On 05/26/2018 02:19 PM, Marcus Folkesson wrote: > > Add documentation to give a brief description on how to use the > > CCID Gadget Device. > > This includes a description for all attributes followed by an example on > > how to setup the device with ConfigFS. > > > > Signed-off-by: Marcus Folkesson > > --- > > Documentation/usb/gadget_ccid.rst | 267 > > ++ > > 1 file changed, 267 insertions(+) > > create mode 100644 Documentation/usb/gadget_ccid.rst > > > > diff --git a/Documentation/usb/gadget_ccid.rst > > b/Documentation/usb/gadget_ccid.rst > > new file mode 100644 > > index ..5ac806b14604 > > --- /dev/null > > +++ b/Documentation/usb/gadget_ccid.rst > > @@ -0,0 +1,267 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > + > > +CCID Gadget > > + > > + > > +:Author: Marcus Folkesson > > + > > +Introduction > > + > > + > > +The CCID Gadget will present itself as a CCID device to the host system. > > +The device supports two endpoints for now; BULK IN and BULK OUT. > > +These endpoints is exposed to userspace via /dev/ccidg*. > >are exposed > > > + > > +All CCID commands are sent on the BULK-OUT endpoint. Each command sent to > > the CCID > > +has an associated ending response. Some commands can also have intermediate > > +responses. The response is sent on the BULK-IN endpoint. > > +See Figure 3-3 in the CCID Specification [1]_ for more details. > > + > > +The CCID commands must be handled in userspace since the driver is only > > working > > +as a transport layer for the TPDUs. > > + > > + > > +CCID Commands > > +-- > > + > > +All CCID commands begins with a 10 bytes header followed by an optional > > with a 10-byte header > (or maybe that's a locale difference) > > > +data field depending on message type. > > + > > +++--+---+--+ > > +| Offset | Field| Size | Description | > > +++==+===+==+ > > +| 0 | bMessageType | 1 | Type of message | > > +++--+---+--+ > > +| 1 | dwLength | 4 | Message specific data length | > > +|| | | | > > +++--+---+--+ > > +| 5 | bSlot| 1 | Identifies the slot number | > > +|| | | for this command | > > +++--+---+--+ > > +| 6 | bSeq | 1 | Sequence number for command | > > +++--+---+--+ > > +| 7 | ... | 3 | Fields depends on message type | > > +++--+---+--+ > > +| 10 | abData | array | Message specific data (OPTIONAL) | > > +++--+---+--+ > > + > > + > > +Multiple CCID gadgets > > +-- > > + > > +It is possible to create multiple instances of the CCID gadget, however, > > +a much more flexible way is to create one gadget and set the `nslots` > > attribute > > +to the number of desired CCID devices. > > + > > +All CCID commands specifies which slot that is the receiver in the `bSlot` > > field > > specify which slot is the receiver > > > +of the CCID header. > > + > > +Usage > > += > > + > > +Access from userspace > > +-- > > +All communication is by read(2) and write(2) to the corresponding > > /dev/ccidg* device. > > +Only one filedescriptor is allowed to be open to the device at a time. > > file descriptor > > > + > > +The buffer size provided to read(2) **must be at least** 522 (10 bytes > > header + 512 bytes payload) > > +bytes as we are working with whole commands. > > + > > +The buffer size provided to write(2) **may not exceed** 522 (10 bytes > > header + 512 bytes payload) > > +bytes as we are working with whole commands. > > + > > + > > +Configuration with configfs > > + > > + > > +ConfigFS is used to create and configure the CCID gadget. > > +In order to get a device to work as intended, a few attributes must > > +be considered. > > + > > +The attributes is described below followed by an example. > > are > > > + > > +features > > +~ > > + > > +The `feature` attribute writes to the dwFeatures field in the class > > descriptor. > > +See Table 5.1-1 Smart Card Device Descriptors in the CCID Specification > > [1]_. > > + > > +The value indicates what intelligent
Re: [PATCH v2 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device
Mi Marcus, W dniu 26.05.2018 o 23:19, Marcus Folkesson pisze: > Chip Card Interface Device (CCID) protocol is a USB protocol that > allows a smartcard device to be connected to a computer via a card > reader using a standard USB interface, without the need for each manufacturer > of smartcards to provide its own reader or protocol. > > This gadget driver makes Linux show up as a CCID device to the host and let a > userspace daemon act as the smartcard. > > This is useful when the Linux gadget itself should act as a cryptographic > device or forward APDUs to an embedded smartcard device. > > Signed-off-by: Marcus Folkesson > --- > > +config USB_CONFIGFS_CCID > + bool "Chip Card Interface Device (CCID)" > + depends on USB_CONFIGFS > + select USB_F_CCID > + help > + The CCID function driver provides generic emulation of a > + Chip Card Interface Device (CCID). > + > + You will need a user space server talking to /dev/ccidg*, > + since the kernel itself does not implement CCID/TPDU/APDU > + protocol. Your function needs a userspace daemon to work. It seems you want to use FunctionFS for such a purpose instead of creating a new function. Andrzej -- 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
