<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/hwtracing/stm, branch dev-4.6</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.6</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2016-02-20T22:09:14+00:00</updated>
<entry>
<title>stm class: dummy_stm: Add link callback for fault injection</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=adcde635f5d6b77e9f11087af09c6f62da2bf108'/>
<id>urn:sha1:adcde635f5d6b77e9f11087af09c6f62da2bf108</id>
<content type='text'>
STM device's link callback has the power to abort master/channel
assignment by returning a negative error code. Use this in dummy
stm device to optionally abort assigning certain channel IDs.
This is useful as fault injection into the stm class core, for
testing purposes.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Plug stm device's unlink callback</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=cc8424074e51355e0c6ba717d8edc50d408f2802'/>
<id>urn:sha1:cc8424074e51355e0c6ba717d8edc50d408f2802</id>
<content type='text'>
STM device's unlink callback is never actually called from anywhere in
the stm class code.

This patch adds calls to stm driver's unlink method after the unlinking
has succeeded.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Fix a race in unlinking</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b4ca34aaf78ed0cdfc15956d377064104257a437'/>
<id>urn:sha1:b4ca34aaf78ed0cdfc15956d377064104257a437</id>
<content type='text'>
There is a window in stm_source_link_drop(), during which the source's
link may change before locks are acquired. When this happens, it throws
a warning, since this is not an expected scenario.

This patch handles the race in such a way that if the link appears to
have changed by the time we took the locks, it will release them and
repeat the whole unlinking procedure from the beginning, unless the
other contender beat us to it.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Fix unbalanced module/device refcounting</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f7c81c7176c72c7899390754b4b038a64b296e4d'/>
<id>urn:sha1:f7c81c7176c72c7899390754b4b038a64b296e4d</id>
<content type='text'>
STM code takes references to the stm device and its module for the
duration of the character device's existence or the stm_source link.
Dropping these references is not well balanced everywhere, which may
lead to leaks.

This patch balances the acquisition and releasing of these two
references and annotates each site so that it's easier to verify
correctness by reading the code.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Guard output assignment against concurrency</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=cde4ad8368840e414ecf67db258fe1dabaa5fd2e'/>
<id>urn:sha1:cde4ad8368840e414ecf67db258fe1dabaa5fd2e</id>
<content type='text'>
It is possible to concurrently assign the same output (a character
device writer or an stm_source device) to different stm devices,
which sets off a strategically placed warning in stm_output_assign().

To avoid this, use a spinlock to serialize (un)assignments between
outputs and stm devices.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Fix unlocking braino in the error path</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1810f2c44817c74ca3d05d1e3981e3a2e2ceb6f5'/>
<id>urn:sha1:1810f2c44817c74ca3d05d1e3981e3a2e2ceb6f5</id>
<content type='text'>
If an illegal attempt is made to unlink stm source device from an
stm device, the stm device's link spinlock mistakenly remains locked.
While this really shouldn't happen (there's a warning in place), the
locking should remain in order so that we can still recover from this
situation if it indeed does happen.

This patch unifies the unlocking in the exit path of
__stm_source_link_drop() to fix this.

Reported-by: Laurent Fert &lt;laurent.fert@intel.com&gt;
Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Add heartbeat stm source device</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1192918530381b5cfc0e5da51233fa94f783b221'/>
<id>urn:sha1:1192918530381b5cfc0e5da51233fa94f783b221</id>
<content type='text'>
Heartbeat stm source may have multiple instances (for connecting to
different stm devices). Each instance will send a periodic test message
over its stm device when it is linked. This can be used for testing stm
class framework, stm device drivers or as a heartbeat over the stm link.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: dummy_stm: Create multiple devices</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bcfdf8afdebe63a2217fa632ae94f8aeecf9126f'/>
<id>urn:sha1:bcfdf8afdebe63a2217fa632ae94f8aeecf9126f</id>
<content type='text'>
STM framework should be able to handle multiple STM devices at a time,
each one with its own master allocation policy.

This patch changes dummy_stm driver to create multiple STM sinks to
help testing the framework.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Support devices with multiple instances</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=59be422e4ce10e3d49d4c9407a80fab8a9b7bc84'/>
<id>urn:sha1:59be422e4ce10e3d49d4c9407a80fab8a9b7bc84</id>
<content type='text'>
By convention, the name of the stm policy directory in configfs consists of
the device name to which it applies and the actual policy name, separated
by a dot. Now, some devices already have dots in their names that separate
name of the actual device from its instance identifier. Such devices will
result in two (or more, who can tell) dots in the policy directory name.

Existing policy code, however, will treat the first dot as the one that
separates device name from policy name, therefore failing the above case.

This patch makes the last dot in the directory name be the separator, thus
prohibiting dots from being used in policy names.

Suggested-by: Chunyan Zhang &lt;zhang.chunyan@linaro.org&gt;
Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>stm class: Use driver's packet callback return value</title>
<updated>2016-02-20T22:09:14+00:00</updated>
<author>
<name>Alexander Shishkin</name>
<email>alexander.shishkin@linux.intel.com</email>
</author>
<published>2016-02-15T17:12:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f8560a9bc76b2cd5c06fa412cb7b5481d70fcf34'/>
<id>urn:sha1:f8560a9bc76b2cd5c06fa412cb7b5481d70fcf34</id>
<content type='text'>
STM drivers provide a callback to generate/send individual STP packets;
it also tells the stm core how many bytes of payload it has consumed.
However, we would also need to use the negative space of this return
value to communicate errors that occur during the packet generation,
in which case the stm core will have to take appropriate action.

For now, we need to account for the possibility that the stm driver may
not support certain combinations of packet type/flags, in which case
it is expected to signal an error.

Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
