Re: [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags

2016-02-12 Thread Markus Mayer 
For some odd reason, the first version of this e-mail had an HTML part
and got rejected from the lists. My apologies for the extra e-mail.

On 11 February 2016 at 18:12, Florian Fainelli  wrote:
> As is now common in a lot of organization having an internal code review
> process (be it through Gerritt or other tools), patches extracted from
> this review process and submitted to public mailing-lists will have
> pre-existing Reviewed-by tags. Add a note about why these tags exists,
> and what a maintainer could be doing with those. Some maintainers did
> complain before that these tags had to be added when the patches get
> submitted to the public, while some just ignored and took the patches
> as-is.
>
> Signed-off-by: Florian Fainelli 
> ---
>  Documentation/SubmittingPatches | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index d603fa078235..b1b8e39bc5ee 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -582,6 +582,14 @@ reviewers and to inform maintainers of the degree of 
> review which has been
>  done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
>  understand the subject area and to perform thorough reviews, will normally
>  increase the likelihood of your patch getting into the kernel.
> +The presence of Reviewed-by tags for an initial patch submission are 
> indicative
> +of an existing internal review process that may occur at various 
> organizations,
> +prior to a mainline kernel submission.  The presence of these tags can give 
> the
> +maintainer a good appreciation that somebody has done an internal review
> +following the same guidelines as those done on a public mailing-list.
> +Maintainers are encouraged to maintain these tags while accepting and merging
> +patches, appreciation of these pre-existing Revivewed-by tags is left are 
> their
> +own discretion.

Some nit-picking on the last sentence. How about:

While maintainers are encouraged to maintain these tags when accepting
and merging patches, appreciation of these pre-existing Reviewed-by
tags is left at their own discretion.

There's also a typo in "Reviewed-by" in the original sentence.

>  A Suggested-by: tag indicates that the patch idea is suggested by the person
>  named and ensures credit to the person for the idea. Please note that this
> --
> 2.1.0
>
--
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 V3 1/6] stm class: Add ioctl get_options interface

2016-02-12 Thread Mathieu Poirier 
On 12 February 2016 at 08:18, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> There is already an interface of set_options, but no get_options yet.
>> Before setting any options, one would may want to see the current
>> status of that option by means of get_options interface. This
>> interface has been used in CoreSight STM driver.
>
> I'm not sure I understand the reasoning behind this. If a userspace
> program opens a communication channel and wants to configure certain
> features on it, why does its choice depend on what has been configured
> for this channel previously? It can be anything at all. Most likely,
> it's either unconfigured or configured to its default values, but why
> does this matter for a new writer?

A client may wish to change the settings (invariant/guaranteed) it has
on a specific channel - it may even want to so do multiple times.  The
idea behind introducing a get_options() was to probe the specific
settings of a channel before going a head with a new configuration.
In hindsight it may not be needed as a client should simply go ahead
and push down the configuration it wants.

>
> Regards,
> --
> Alex
--
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 V3 6/6] coresight-stm: adding driver for CoreSight STM component

2016-02-12 Thread Mathieu Poirier 
On 12 February 2016 at 08:28, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> +static long stm_generic_set_options(struct stm_data *stm_data,
>> + unsigned int master,
>> + unsigned int channel,
>> + unsigned int nr_chans,
>> + unsigned long options)
>> +{
>> + struct stm_drvdata *drvdata = container_of(stm_data,
>> +struct stm_drvdata, stm);
>> + if (!(drvdata && drvdata->enable))
>> + return -EINVAL;
>> +
>> + if (channel >= drvdata->numsp)
>> + return -EINVAL;
>> +
>> + switch (options) {
>> + case STM_OPTION_GUARANTEED:
>> + set_bit(channel, drvdata->chs.guaranteed);
>> + break;
>> +
>> + case STM_OPTION_INVARIANT:
>> + clear_bit(channel, drvdata->chs.guaranteed);
>> + break;
>
> This is a bad interface. Firstly, neither option is described
> anywhere. Secondly, I'm pretty sure "invariant" does not mean "not
> guaranteed" in english, although this function seems to imply this.

Regardless of the semantic associated to the word "invariant" in the
English language, the documentation characterises a channel configured
in best effort delivery mode as "invariant".  This is also the
opposite of the "guaranteed" mode where packets are guaranteed to be
delivered.  Adding a few comments here is probably a good idea.

>
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static long stm_generic_get_options(struct stm_data *stm_data,
>> + unsigned int master,
>> + unsigned int channel,
>> + unsigned int nr_chans,
>> + u64 *options)
>> +{
>> + struct stm_drvdata *drvdata = container_of(stm_data,
>> +struct stm_drvdata, stm);
>> + if (!(drvdata && drvdata->enable))
>> + return -EINVAL;
>> +
>> + if (channel >= drvdata->numsp)
>> + return -EINVAL;
>> +
>> + switch (*options) {
>> + case STM_OPTION_GUARANTEED:
>> + *options = test_bit(channel, drvdata->chs.guaranteed);
>> + break;
>
> This just doesn't work. @options here is an on-stack variable in
> stm_char_ioctl(), hitherto uninitialized. The get_options ioctl command
> as you implemented it doesn't fetch @options from userspace either, it
> just passes a pointer to it to this callback, expecting that the
> callback will set it so that it can be copy_to_user()ed back to the
> user.

Yes, that was the intended behaviour - to allow user space to see in
what mode channels are configured (guaranteed/invariant).

>
> Then, when we figure this out, there is again the question of what
> should one make of STM_OPTION_{GUARANTEED,INVARIANT} and how do they fit
> into *options.

The interface asks if the channel is configured in "guaranteed" mode.
If not and because there isn't another mode available, it is
automatically in "invariant" mode.

But as I pointed out in my earlier email this may no longer needed.
One has to issue a system call anyway, might as well just go ahead
with the configuration request.

Thanks,
Mathieu

>
> The idea behind set_options ioctl is that the user specifies a bit mask
> of options that he/she wants to set.
>
> [snip]
>
>> +#ifndef __UAPI_CORESIGHT_STM_H_
>> +#define __UAPI_CORESIGHT_STM_H_
>> +
>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>> +#define STM_FLAG_GUARANTEEDBIT(7)
>> +
>> +enum {
>> + STM_OPTION_GUARANTEED = 0,
>> + STM_OPTION_INVARIANT,
>> +};
>
> Each of these guys could also use an explanation.
>
> Regards,
> --
> Alex
--
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] Doc: i2c: Fix typo in Documentation/i2c

2016-02-12 Thread Wolfram Sang 
On Tue, Feb 02, 2016 at 08:41:25PM +0900, Masanari Iida wrote:
> This path fix spelling typos found in Documentation/i2c.
> 
> Signed-off-by: Masanari Iida 

Probably too late already, but still:

Acked-by: Wolfram Sang 

Thanks!



signature.asc
Description: Digital signature

[PATCH] kernel: fs: drop_caches: add dds drop_caches_count

2016-02-12 Thread Daniel Walker 
From: Khalid Mughal 

Currently there is no way to figure out the droppable pagecache size
from the meminfo output. The MemFree size can shrink during normal
system operation, when some of the memory pages get cached and is
reflected in "Cached" field. Similarly for file operations some of
the buffer memory gets cached and it is reflected in "Buffers" field.
The kernel automatically reclaims all this cached & buffered memory,
when it is needed elsewhere on the system. The only way to manually
reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. But
this can have performance impact. Since it discards cached objects,
it may cause high CPU & I/O utilization to recreate the dropped
objects during heavy system load.
This patch computes the droppable pagecache count, using same
algorithm as "vm/drop_caches". It is non-destructive and does not
drop any pages. Therefore it does not have any impact on system
performance. The computation does not include the size of
reclaimable slab.

Cc: xe-ker...@external.cisco.com
Cc: dave.han...@intel.com
Cc: han...@cmpxchg.org
Cc: r...@redhat.com
Signed-off-by: Khalid Mughal 
Signed-off-by: Daniel Walker 
---
 Documentation/sysctl/vm.txt | 12 +++
 fs/drop_caches.c| 80 +++--
 include/linux/mm.h  |  3 ++
 kernel/sysctl.c |  7 
 4 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 89a887c..13a501c 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -29,6 +29,7 @@ Currently, these files are in /proc/sys/vm:
 - dirty_ratio
 - dirty_writeback_centisecs
 - drop_caches
+- drop_caches_count
 - extfrag_threshold
 - hugepages_treat_as_movable
 - hugetlb_shm_group
@@ -224,6 +225,17 @@ with your system.  To disable them, echo 4 (bit 3) into 
drop_caches.
 
 ==
 
+drop_caches_count
+
+The amount of droppable pagecache (in kilobytes). Reading this file
+performs same calculation as writing 1 to /proc/sys/vm/drop_caches.
+The actual pages are not dropped during computation of this value.
+
+To read the value:
+   cat /proc/sys/vm/drop_caches_count
+
+==
+
 extfrag_threshold
 
 This parameter affects whether the kernel will compact memory or direct
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index d72d52b..0cb2186 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -8,12 +8,73 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "internal.h"
 
 /* A global variable is a bit ugly, but it keeps the code simple */
+
 int sysctl_drop_caches;
+unsigned int sysctl_drop_caches_count;
+
+static int is_page_droppable(struct page *page)
+{
+   struct address_space *mapping = page_mapping(page);
+
+   if (!mapping)
+   return 0;
+   if (PageDirty(page))
+   return 0;
+   if (PageWriteback(page))
+   return 0;
+   if (page_mapped(page))
+   return 0;
+   if (page->mapping != mapping)
+   return 0;
+   if (page_has_private(page))
+   return 0;
+   return 1;
+}
+
+static unsigned long count_unlocked_pages(struct address_space *mapping)
+{
+   struct pagevec pvec;
+   pgoff_t start = 0;
+   pgoff_t end = -1;
+   unsigned long count = 0;
+   int i;
+   int rc;
+
+   pagevec_init(&pvec, 0);
+   while (start <= end && pagevec_lookup(&pvec, mapping, start,
+   min(end - start, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
+   for (i = 0; i < pagevec_count(&pvec); i++) {
+   struct page *page = pvec.pages[i];
+   start = page->index;
+   if (start > end)
+   break;
+   if (!trylock_page(page))
+   continue;
+   WARN_ON(page->index != start);
+   rc = is_page_droppable(page);
+   unlock_page(page);
+   count += rc;
+   }
+   pagevec_release(&pvec);
+   cond_resched();
+   start++;
+   }
+   return count;
+}
 
-static void drop_pagecache_sb(struct super_block *sb, void *unused)
+static void drop_pagecache_sb(struct super_block *sb, void *count)
 {
struct inode *inode, *toput_inode = NULL;
 
@@ -29,7 +90,11 @@ static void drop_pagecache_sb(struct super_block *sb, void 
*unused)
spin_unlock(&inode->i_lock);
spin_unlock(&sb->s_inode_list_lock);
 
-   invalidate_mapping_pages(inode->i_mapping, 0, -1);
+   if (count)
+   sysctl_drop_caches_count += 
count_unlocked_pages(inode->i_mapping);
+   else
+

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

2016-02-12 Thread Mathieu Poirier 
On 12 February 2016 at 09:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>>  wrote:
>>> This $end==$start situation itself may be ambiguous and can be
>>> interpreted either as having just one *static* master ID fixed for all
>>> SW writers (what I assumed from your commit message) or as having a
>>> floating master ID, which changes of its own accord and is not
>>> controllable by software.
>>
>> Some clarification here.
>>
>> On ARM from a SW point of view $end == $start and that doesn't change
>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>> on other platforms where masterID configuration does change and is
>> important, the condition $end == $start could also be valid.
>
> Yes, that's what I was saying. The thing is, on the system-under-tracing
> side these two situations are not very different from one
> another. Master IDs are really just numbers without any semantics
> attached to them in the sense that they are not covered by the mipi spec
> or any other standard (to my knowledge).

We are definitely on the same page here, just using slightly different terms.

>
> The difference is in the way we map channels to masters. One way is to
> allocate a distinct set of channels for each master (the way Intel Trace
> Hub does it); another way is to share the same set of channels between
> multiple masters.

We are in total agreement.

> So we can describe this as "hardware implements the
> same set of channels across multiple masters" or something along those
> lines.

I suggest "Shared channels"?  In the end, that's really what it is...

The outstanding issue is still how to represent these to different way
of mapping things in the STM core.  I suggested a flag, called
"mstatic" (but that can be changed), and a representation of '-1' in
for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
I'd be fine with another mechanism.  What I am keen on is that from
sysFS users can quickly tell which heuristic is enacted on that
specific architecture.

>
> Actually, in the latter scheme of things you can also have multiple
> masters, at least theoretically. Say, you have masters [0..15], each
> with distinct set of channels, but depending on hardware state these
> masters actually end up as $state*16+$masterID in the STP stream.
>
> So we might also think about differentiating between the hardware
> masters (0 though 15 in the above example) and STP masters.

I'm not sure I get what you mean here.  On ARM the masterIDs assigned
in HW, which will depend on the state, will show up in the STP stream.
But again, I might be missing your point.

Thanks,
Mathieu

>
> Regards,
> --
> Alex
--
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: [RFC] A first shot at asciidoc-based formatted docs

2016-02-12 Thread Keith Packard 
Keith Packard  writes:

> The goal would be to create an html document which could be used without
> javascript, and that would work without css as well.

I've managed to hack up asciidoc to generate the TOC within the
document, rather than requiring javascript. The changes are fairly
minor, and seem to add a nice generalization to the asciidoc environment
which should be useful in other contexts.

The changes consist of two bits -- the first is to allow the diversion
of some text from .conf file sections, the second is to postpone some
attribute processing to a second pass over the document so that the TOC
can be inserted in the desired location, instead of requiring that it be
placed at the bottom.

I've sent these changes upstream, and also pushed them to a personal
asciidoc git repository at :

git clone git://keithp.com/git/asciidoc

-- 
-keith


signature.asc
Description: PGP signature

RE: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM component

2016-02-12 Thread Michael Williams 
Mathieu Poirier [mailto:mathieu.poir...@linaro.org] wrote:
> On 6 February 2016 at 04:04, Chunyan Zhang  wrote:
>> From: Pratik Patel 
>>
>> This driver adds support for the STM CoreSight IP block, allowing any
>> system compoment (HW or SW) to log and aggregate messages via a
>> single entity.
>>
>> The CoreSight STM exposes an application defined number of channels
>> called stimulus port.  Configuration is done using entries in sysfs
>> and channels made available to userspace via configfs.
>>
>> Signed-off-by: Pratik Patel 
>> Signed-off-by: Mathieu Poirier 
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>>  Documentation/trace/coresight.txt  |  37 +-
>>  drivers/hwtracing/coresight/Kconfig|  11 +
>>  drivers/hwtracing/coresight/Makefile   |   1 +
>>  drivers/hwtracing/coresight/coresight-stm.c| 928 
>> +
>>  include/linux/coresight-stm.h  |   6 +
>>  include/uapi/linux/coresight-stm.h |  12 +
>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>  create mode 100644 include/linux/coresight-stm.h
>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> new file mode 100644
>> index 000..a1d7022
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> @@ -0,0 +1,53 @@
>> +What:  /sys/bus/coresight/devices/.stm/enable_source
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
>> +   Enabling the trace macrocell implies it has been configured
>> +   properly and a sink has been identidifed for it.  The path
>> +   of coresight components linking the source to the sink is
>> +   configured and managed automatically by the coresight 
>> framework.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/hwevent_enable
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Provides access to the HW event enable register, used in
>> +   conjunction with HW event bank select register.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/hwevent_select
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Gives access to the HW event block select register
>> +   (STMHEBSR) in order to configure up to 256 channels.  Used in
>> +   conjunction with "hwevent_enable" register as described 
>> above.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/port_enable
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Provides access to the stimlus port enable register
>> +   (STMSPER).  Used in conjunction with "port_select" described
>> +   below.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/port_select
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Used to determine which bank of stimulus port bit in
>> +   register STMSPER (see above) apply to.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/status
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (R) List various control and status registers.  The specific
>> +   layout and content is driver specific.
>> +
>> +What:  /sys/bus/coresight/devices/.stm/traceid
>> +Date:  February 2016
>> +KernelVersion: 4.5
>> +Contact:   Mathieu Poirier 
>> +Description:   (RW) Holds the trace ID that will appear in the trace stream
>> +   coming from this trace entity.
>> diff --git a/Documentation/trace/coresight.txt 
>> b/Documentation/trace/coresight.txt
>> index 0a5c329..a33c88c 100644
>> --- a/Documentation/trace/coresight.txt
>> +++ b/Documentation/trace/coresight.txt
>> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those 
>> entries.
>>  Last but not least, "struct module *owner" is expected to be set to reflect
>>  the information carried in "THIS_MODULE".
>>
>> -How to use
>> ---
>> +How to use the tracer modules
>> +-
>>
>>  Before trace collection can start, a coresight sink needs to be identify.
>>  There is no limit on the amount of sinks (nor sources) that can be enabled 
>> at
>> @@ -297,3 +297,36 @@ InfoTracing enabled
>>  Instruction 135708310x8026B584

A link on your site is broken

2016-02-12 Thread Tom Wilcox 

Hi,

I've been compiling resources to include in our C Developer resource 
guide and I came across a link that isn't working on your site.


It's on this page: 
http://blog.gmane.org/gmane.linux.documentation/page=13


I'm getting an error message when I visit this link: 
http://cm.bell-labs.com/cm/cs/cbook/


If you are planning on updating this page on your site, perhaps our 
guide to C developer resources - http://wiht.link/c-developer would make 
a suitable replacement.


I hope this helps!
Tom

--
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 V3 1/6] stm class: Add ioctl get_options interface

2016-02-12 Thread Alexander Shishkin 
Chunyan Zhang  writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.

I'm not sure I understand the reasoning behind this. If a userspace
program opens a communication channel and wants to configure certain
features on it, why does its choice depend on what has been configured
for this channel previously? It can be anything at all. Most likely,
it's either unconfigured or configured to its default values, but why
does this matter for a new writer?

Regards,
--
Alex
--
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 V3 6/6] coresight-stm: adding driver for CoreSight STM component

2016-02-12 Thread Alexander Shishkin 
Chunyan Zhang  writes:

> +static long stm_generic_set_options(struct stm_data *stm_data,
> + unsigned int master,
> + unsigned int channel,
> + unsigned int nr_chans,
> + unsigned long options)
> +{
> + struct stm_drvdata *drvdata = container_of(stm_data,
> +struct stm_drvdata, stm);
> + if (!(drvdata && drvdata->enable))
> + return -EINVAL;
> +
> + if (channel >= drvdata->numsp)
> + return -EINVAL;
> +
> + switch (options) {
> + case STM_OPTION_GUARANTEED:
> + set_bit(channel, drvdata->chs.guaranteed);
> + break;
> +
> + case STM_OPTION_INVARIANT:
> + clear_bit(channel, drvdata->chs.guaranteed);
> + break;

This is a bad interface. Firstly, neither option is described
anywhere. Secondly, I'm pretty sure "invariant" does not mean "not
guaranteed" in english, although this function seems to imply this.

> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static long stm_generic_get_options(struct stm_data *stm_data,
> + unsigned int master,
> + unsigned int channel,
> + unsigned int nr_chans,
> + u64 *options)
> +{
> + struct stm_drvdata *drvdata = container_of(stm_data,
> +struct stm_drvdata, stm);
> + if (!(drvdata && drvdata->enable))
> + return -EINVAL;
> +
> + if (channel >= drvdata->numsp)
> + return -EINVAL;
> +
> + switch (*options) {
> + case STM_OPTION_GUARANTEED:
> + *options = test_bit(channel, drvdata->chs.guaranteed);
> + break;

This just doesn't work. @options here is an on-stack variable in
stm_char_ioctl(), hitherto uninitialized. The get_options ioctl command
as you implemented it doesn't fetch @options from userspace either, it
just passes a pointer to it to this callback, expecting that the
callback will set it so that it can be copy_to_user()ed back to the
user.

Then, when we figure this out, there is again the question of what
should one make of STM_OPTION_{GUARANTEED,INVARIANT} and how do they fit
into *options.

The idea behind set_options ioctl is that the user specifies a bit mask
of options that he/she wants to set.

[snip]

> +#ifndef __UAPI_CORESIGHT_STM_H_
> +#define __UAPI_CORESIGHT_STM_H_
> +
> +#define STM_FLAG_TIMESTAMPED   BIT(3)
> +#define STM_FLAG_GUARANTEEDBIT(7)
> +
> +enum {
> + STM_OPTION_GUARANTEED = 0,
> + STM_OPTION_INVARIANT,
> +};

Each of these guys could also use an explanation.

Regards,
--
Alex
--
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 3/6] stm class: provision for statically assigned masterIDs

2016-02-12 Thread Alexander Shishkin 
Al Grant  writes:

>> Mike did write "master IDs are hardwired to individual cores and core 
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)
>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

What I understood from Mike's explanation is that basically nothing is
fixed from the software perspective (talking about Coresight STM). One
doesn't know the master id with which one's data will be tagged,
regardless of whether one is cpu-affine or not, because:

 * even per-core master IDs will be highly implementation dependent and
   therefore not knowable by the kernel and subsequently userspace,
 * master IDs may change based on other conditions (besides security
   states), so even if we knew per-core master IDs for sure, it wouldn't
   give us the complete picture.

So even though from the HW perspective master IDs may be "hardwired" to
hardware states, the hardware states themselves are dynamic, so from the
SW perspective these master IDs are not static or hardwired at all.

If the same mmio write done by software would always result in the exact
same master ID tagged to it, that would be more like "static" to me.

Regards,
--
Alex
--
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 3/6] stm class: provision for statically assigned masterIDs

2016-02-12 Thread Alexander Shishkin 
Mathieu Poirier  writes:

> On 8 February 2016 at 06:26, Alexander Shishkin
>  wrote:
>> This $end==$start situation itself may be ambiguous and can be
>> interpreted either as having just one *static* master ID fixed for all
>> SW writers (what I assumed from your commit message) or as having a
>> floating master ID, which changes of its own accord and is not
>> controllable by software.
>
> Some clarification here.
>
> On ARM from a SW point of view $end == $start and that doesn't change
> (with regards to masterIDs) .  The ambiguity comes from the fact that
> on other platforms where masterID configuration does change and is
> important, the condition $end == $start could also be valid.

Yes, that's what I was saying. The thing is, on the system-under-tracing
side these two situations are not very different from one
another. Master IDs are really just numbers without any semantics
attached to them in the sense that they are not covered by the mipi spec
or any other standard (to my knowledge).

The difference is in the way we map channels to masters. One way is to
allocate a distinct set of channels for each master (the way Intel Trace
Hub does it); another way is to share the same set of channels between
multiple masters. So we can describe this as "hardware implements the
same set of channels across multiple masters" or something along those
lines.

Actually, in the latter scheme of things you can also have multiple
masters, at least theoretically. Say, you have masters [0..15], each
with distinct set of channels, but depending on hardware state these
masters actually end up as $state*16+$masterID in the STP stream.

So we might also think about differentiating between the hardware
masters (0 though 15 in the above example) and STP masters.

Regards,
--
Alex
--
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: [PATCHv3 1/3] rdmacg: Added rdma cgroup controller.

2016-02-12 Thread Tejun Heo 
Hello, Parav.

On Fri, Feb 12, 2016 at 02:49:38AM +0530, Parav Pandit wrote:
> 1. Removed two type of resource pool, made is single type (as you
> described in past comment)
> 2. Removed match tokens and have array definition like "qp", "mr", "cq" etc.
> 3. Wrote small parser and avoided match_token API as that won't work
> due to different array definition
> 4. Removed one-off remove API to unconfigure cgroup, instead all
> resource should be set to max.
> 5. Removed resource pool type (user/default), instead having max_num_cnt,
> when ref_cnt drops to zero and max_num_cnt = total_rescource_cnt, pool is 
> freed.
> 6. Resource definition ownership is now only with IB stack at single
> header file, no longer in each low level driver.
> This goes through IB maintainer and other reviewers eyes.
> This continue to give flexibility to not force kernel upgrade for few
> enums additions for new resource type.
> 7. Wherever possible pool lock is pushed out, except for hierarchical
> charging/unchanging points, as it not possible to do so, due to
> iterative process involves blocking allocations of rpool. Coming up
> more levels up to release locks doesn't make any sense either.
> This is anyway slow path where rpool is not allocated. Except for
> typical first resource allocation, this is less traveled path.
> 8.Other minor cleanups.
> 9. Avoided %d manipulation due to removal of match_token and replaced
> with seq_putc etc friend functions.

Sounds great.  Can't tell too much without looking at the code tho.

Thanks.

-- 
tejun
--
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 V3 6/6] coresight-stm: adding driver for CoreSight STM component

2016-02-12 Thread Mathieu Poirier 
On 12 February 2016 at 07:55, Michael Williams  wrote:
> Mathieu Poirier [mailto:mathieu.poir...@linaro.org] wrote:
>> On 6 February 2016 at 04:04, Chunyan Zhang  wrote:
>>> From: Pratik Patel 
>>>
>>> This driver adds support for the STM CoreSight IP block, allowing any
>>> system compoment (HW or SW) to log and aggregate messages via a
>>> single entity.
>>>
>>> The CoreSight STM exposes an application defined number of channels
>>> called stimulus port.  Configuration is done using entries in sysfs
>>> and channels made available to userspace via configfs.
>>>
>>> Signed-off-by: Pratik Patel 
>>> Signed-off-by: Mathieu Poirier 
>>> Signed-off-by: Chunyan Zhang 
>>> ---
>>>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>>>  Documentation/trace/coresight.txt  |  37 +-
>>>  drivers/hwtracing/coresight/Kconfig|  11 +
>>>  drivers/hwtracing/coresight/Makefile   |   1 +
>>>  drivers/hwtracing/coresight/coresight-stm.c| 928 
>>> +
>>>  include/linux/coresight-stm.h  |   6 +
>>>  include/uapi/linux/coresight-stm.h |  12 +
>>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>>  create mode 100644 
>>> Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>>  create mode 100644 include/linux/coresight-stm.h
>>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> new file mode 100644
>>> index 000..a1d7022
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> @@ -0,0 +1,53 @@
>>> +What:  /sys/bus/coresight/devices/.stm/enable_source
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Enable/disable tracing on this specific trace 
>>> macrocell.
>>> +   Enabling the trace macrocell implies it has been configured
>>> +   properly and a sink has been identidifed for it.  The path
>>> +   of coresight components linking the source to the sink is
>>> +   configured and managed automatically by the coresight 
>>> framework.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/hwevent_enable
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Provides access to the HW event enable register, used 
>>> in
>>> +   conjunction with HW event bank select register.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/hwevent_select
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Gives access to the HW event block select register
>>> +   (STMHEBSR) in order to configure up to 256 channels.  Used 
>>> in
>>> +   conjunction with "hwevent_enable" register as described 
>>> above.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/port_enable
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Provides access to the stimlus port enable register
>>> +   (STMSPER).  Used in conjunction with "port_select" described
>>> +   below.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/port_select
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Used to determine which bank of stimulus port bit in
>>> +   register STMSPER (see above) apply to.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/status
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (R) List various control and status registers.  The specific
>>> +   layout and content is driver specific.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/traceid
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Holds the trace ID that will appear in the trace stream
>>> +   coming from this trace entity.
>>> diff --git a/Documentation/trace/coresight.txt 
>>> b/Documentation/trace/coresight.txt
>>> index 0a5c329..a33c88c 100644
>>> --- a/Documentation/trace/coresight.txt
>>> +++ b/Documentation/trace/coresight.txt
>>> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those 
>>> entries.
>>>  Last but not least, "struct module *owner" is expected to be set to reflect
>>>  the information carried in "THIS_MODULE".
>>>
>>> -How to use
>>> ---
>>> +How to use the tracer modules
>>> +-
>>>
>>>  Before trace collection can start, a coresight sink needs to be identify.
>>>  There is no limit on the amo