lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5e7d8200-d357-4105-b00a-3ca36d375aac@infradead.org>
Date:   Sat, 6 Oct 2018 09:38:22 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL 11/16] stm class: Document the MIPI SyS-T protocol
 usage

Hi,
one small typo/spello below...

On 10/5/18 5:43 AM, Alexander Shishkin wrote:
> Add a document describing MIPI SyS-T protocol driver usage.
> 
> Signed-off-by: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
> Tested-by: Mathieu Poirier <mathieu.poirier@...aro.org>
> ---
>  Documentation/trace/sys-t.rst | 62 +++++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
>  create mode 100644 Documentation/trace/sys-t.rst
> 
> diff --git a/Documentation/trace/sys-t.rst b/Documentation/trace/sys-t.rst
> new file mode 100644
> index 000000000000..3d8eb92735e9
> --- /dev/null
> +++ b/Documentation/trace/sys-t.rst
> @@ -0,0 +1,62 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===================
> +MIPI SyS-T over STP
> +===================
> +
> +The MIPI SyS-T protocol driver can be used with STM class devices to
> +generate standardized trace stream. Aside from being a standard, it
> +provides better trace source identification and timestamp correlation.
> +
> +In order to use the MIPI SyS-T protocol driver with your STM device,
> +first, you'll need CONFIG_STM_PROTO_SYS_T.
> +
> +Now, you can select which protocol driver you want to use when you create
> +a policy for your STM device, by specifying it in the policy name:
> +
> +# mkdir /config/stp-policy/dummy_stm.0:p_sys-t.my-policy/
> +
> +In other words, the policy name format is extended like this:
> +
> +  <device_name>:<protocol_name>.<policy_name>
> +
> +With Intel TH, therefore it can look like "0-sth:p_sys-t.my-policy".
> +
> +If the protocol name is omitted, the STM class will chose whichever

s/chose/choose/

> +protocol driver was loaded first.
> +
> +You can also double check that everything is working as expected by
> +
> +# cat /config/stp-policy/dummy_stm.0:p_sys-t.my-policy/protocol
> +p_sys-t
> +
> +Now, with the MIPI SyS-T protocol driver, each policy node in the
> +configfs gets a few additional attributes, which determine per-source
> +parameters specific to the protocol:
> +
> +# mkdir /config/stp-policy/dummy_stm.0:p_sys-t.my-policy/default
> +# ls /config/stp-policy/dummy_stm.0:p_sys-t.my-policy/default
> +channels
> +clocksync_interval
> +do_len
> +masters
> +ts_interval
> +uuid
> +
> +The most important one here is the "uuid", which determines the UUID
> +that will be used to tag all data coming from this source. It is
> +automatically generated when a new node is created, but it is likely
> +that you would want to change it.
> +
> +do_len switches on/off the additional "payload length" field in the
> +MIPI SyS-T message header. It is off by default as the STP already
> +marks message boundaries.
> +
> +ts_interval and clocksync_interval determine how much time in milliseconds
> +can pass before we need to include a protocol (not transport, aka STP)
> +timestamp in a message header or send a CLOCKSYNC packet, respectively.
> +
> +See Documentation/ABI/testing/configfs-stp-policy-p_sys-t for more
> +details.
> +
> +* [1] https://www.mipi.org/specifications/sys-t
> 


-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ