[PATCH v3] doc: coresight: correct usage for disabling idle states

[Leo Yan]

In the coresight CPU debug document it suggests to use 'echo' command
to set latency request to /dev/cpu_dma_latency so can disable all CPU
idle states, but in fact this doesn't work.

This is because when the command 'echo' exits, it releases the device
node's file descriptor and the kernel release function removes the QoS
constraint; finally when the command 'echo' finished there have no
constraint imposed on cpu_dma_latency.

This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
command 'exec' can avoid the file descriptor to be closed so we can
keep the constraint on cpu_dma_latency.

This patch also adds the info for reference docs for PM QoS and cpuidle
sysfs.

Cc: Jonathan Corbet 
Cc: Sudeep Holla 
Reported-by: Kim Phillips 
Suggested-by: Mathieu Poirier 
Signed-off-by: Leo Yan 
---
 Documentation/trace/coresight-cpu-debug.txt | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index b3da1f9..2b9b51c 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -149,11 +149,23 @@ If you want to limit idle states at boot time, you can 
use "nohlt" or
 
 At the runtime you can disable idle states with below methods:
 
-Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
-states (if latency = 0uS then disable all idle states):
-# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
-
-Disable specific CPU's specific idle state:
+It is possible to disable CPU idle states by way of the PM QoS
+subsystem, more specifically by using the "/dev/cpu_dma_latency"
+interface (see Documentation/power/pm_qos_interface.txt for more
+details).  As specified in the PM QoS documentation the requested
+parameter will stay in effect until the file descriptor is released.
+For example:
+
+# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
+...
+Do some work...
+...
+# exec 3<>-
+
+The same can also be done from an application program.
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
 # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
 
 
-- 
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

Re: [PATCH net] ipv6: fix net.ipv6.conf.all interface DAD handlers

[David Miller]

From: Matteo Croce 
Date: Tue, 12 Sep 2017 17:46:37 +0200

> Currently, writing into
> net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
> Fix handling of these flags by:
> 
> - using the maximum of global and per-interface values for the
>   accept_dad flag. That is, if at least one of the two values is
>   non-zero, enable DAD on the interface. If at least one value is
>   set to 2, enable DAD and disable IPv6 operation on the interface if
>   MAC-based link-local address was found
> 
> - using the logical OR of global and per-interface values for the
>   optimistic_dad flag. If at least one of them is set to one, optimistic
>   duplicate address detection (RFC 4429) is enabled on the interface
> 
> - using the logical OR of global and per-interface values for the
>   use_optimistic flag. If at least one of them is set to one,
>   optimistic addresses won't be marked as deprecated during source address
>   selection on the interface.
> 
> While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
> drop inline, and let the compiler decide.
> 
> Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses 
> useful candidates")
> Signed-off-by: Matteo Croce 

Applied, thank you.
--
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] doc: coresight: correct usage for disabling idle states

[Leo Yan]

On Tue, Sep 19, 2017 at 03:32:54PM -0600, Mathieu Poirier wrote:
> On 15 September 2017 at 04:16, Leo Yan  wrote:
> > In the coresight CPU debug document it suggests to use 'echo' command
> > to set latency request to /dev/cpu_dma_latency so can disable all CPU
> > idle states, but in fact this doesn't work.
> >
> > This is because when the command 'echo' exits, it releases the device
> > node's file descriptor and the kernel release function removes the QoS
> > constraint; finally when the command 'echo' finished there have no
> > constraint imposed on cpu_dma_latency.
> >
> > This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> > command 'exec' can avoid the file descriptor to be closed so we can
> > keep the constraint on cpu_dma_latency.
> >
> > This patch also adds the info for reference docs for PM QoS and cpuidle
> > sysfs.
> >
> > Cc: Jonathan Corbet 
> > Cc: Mathieu Poirier 
> > Cc: Sudeep Holla 
> > Reported-by: Kim Phillips 
> > Signed-off-by: Leo Yan 
> > ---
> >  Documentation/trace/coresight-cpu-debug.txt | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> > b/Documentation/trace/coresight-cpu-debug.txt
> > index b3da1f9..205ff95 100644
> > --- a/Documentation/trace/coresight-cpu-debug.txt
> > +++ b/Documentation/trace/coresight-cpu-debug.txt
> > @@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you 
> > can use "nohlt" or
> >
> >  At the runtime you can disable idle states with below methods:
> >
> > -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific 
> > idle
> > -states (if latency = 0uS then disable all idle states):
> > -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> > -
> > -Disable specific CPU's specific idle state:
> > +By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
> > +constraint to disable all CPUs specific idle states (see
> > +Documentation/power/pm_qos_interface.txt, section 'From user mode');
> > +below is one example to set latency constraint to '', it is
> > +hexadecimal format with microsecond unit:
> > +# exec 3<> /dev/cpu_dma_latency; echo '' >&3
> 
> Since doing echo '' >&3 or simply echo 0 >&3 yields the same
> result I would go for the latter.  I also think it is important to
> specify that using an "echo" command without holding the file open
> won't give the desired result.  I would reformat your paragraph as
> follow:
> 
> >>> Begin >>>
> 
> It is possible to disable CPU idle states by way of the PM QoS
> subsystem, more specifically by using the "/dev/cpu_dma_latency"
> interface (see Documentation/power/pm_qos_interface.txt for more
> details).  As specified in the PM QoS documentation the requested
> parameter will stay in effect until the file descriptor is released.
> For example:
> 
> # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> ...
> Do some work...
> ...
> # exec 3<>-
> 
> The same can also be done from an application program.
> 
> <<< End <<<

Very appreciate your rephasing and reviewing. Will spin a new patch
with it.

Thanks,
Leo Yan

> > +
> > +Disable specific CPU's specific idle state from cpuidle sysfs (see
> > +Documentation/cpuidle/sysfs.txt):
> >  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> >
> >
> > --
> > 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

Re: [PATCH v2] doc: coresight: correct usage for disabling idle states

[Mathieu Poirier]

On 15 September 2017 at 04:16, Leo Yan  wrote:
> In the coresight CPU debug document it suggests to use 'echo' command
> to set latency request to /dev/cpu_dma_latency so can disable all CPU
> idle states, but in fact this doesn't work.
>
> This is because when the command 'echo' exits, it releases the device
> node's file descriptor and the kernel release function removes the QoS
> constraint; finally when the command 'echo' finished there have no
> constraint imposed on cpu_dma_latency.
>
> This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> command 'exec' can avoid the file descriptor to be closed so we can
> keep the constraint on cpu_dma_latency.
>
> This patch also adds the info for reference docs for PM QoS and cpuidle
> sysfs.
>
> Cc: Jonathan Corbet 
> Cc: Mathieu Poirier 
> Cc: Sudeep Holla 
> Reported-by: Kim Phillips 
> Signed-off-by: Leo Yan 
> ---
>  Documentation/trace/coresight-cpu-debug.txt | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> index b3da1f9..205ff95 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you can 
> use "nohlt" or
>
>  At the runtime you can disable idle states with below methods:
>
> -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
> -states (if latency = 0uS then disable all idle states):
> -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> -
> -Disable specific CPU's specific idle state:
> +By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
> +constraint to disable all CPUs specific idle states (see
> +Documentation/power/pm_qos_interface.txt, section 'From user mode');
> +below is one example to set latency constraint to '', it is
> +hexadecimal format with microsecond unit:
> +# exec 3<> /dev/cpu_dma_latency; echo '' >&3

Since doing echo '' >&3 or simply echo 0 >&3 yields the same
result I would go for the latter.  I also think it is important to
specify that using an "echo" command without holding the file open
won't give the desired result.  I would reformat your paragraph as
follow:

>>> Begin >>>

It is possible to disable CPU idle states by way of the PM QoS
subsystem, more specifically by using the "/dev/cpu_dma_latency"
interface (see Documentation/power/pm_qos_interface.txt for more
details).  As specified in the PM QoS documentation the requested
parameter will stay in effect until the file descriptor is released.
For example:

# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
...
Do some work...
...
# exec 3<>-

The same can also be done from an application program.

<<< End <<<


> +
> +Disable specific CPU's specific idle state from cpuidle sysfs (see
> +Documentation/cpuidle/sysfs.txt):
>  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>
>
> --
> 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

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Dmitry Torokhov]

On Tue, Sep 19, 2017 at 1:45 PM, Jacek Anaszewski
 wrote:
> On 09/19/2017 12:29 AM, Dmitry Torokhov wrote:
>> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
>>  wrote:
>>> Hi,
>>>
>>> On 09/17/2017 08:22 PM, Pavel Machek wrote:
 Hi!

>> If your objection is that FF is not easily engaged from the shell -
>> yes, but I do not think that actual users who want to do vibration do
>> that via shell either. On the other hand, can you drop privileges and
>> still allow a certain process control your vibrator via LED interface?
>> With FF you can pass an FD to whoever you deem worthy and later revoke
>> access.
>>
>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>> use them in real frameworks, where you need to think about proper
>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>> better.
>
> I'd leave the decision to the user. We could add a note to the
> Documentation/leds/ledtrig-transient.txt that force feedback interface
> should be preferable choice for driving vibrate devices.

 We don't want to leave decision to the user; because then we'll end up
 with userland applications having to support _both_ interfaces.
>>>
>>> This state has lasted for five years now. I don't recall any
>>> complaints. Do you?
>>
>> I was telling Shuah 5 years ago that using LED for what she wanted was
>> not the right idea. I even made a patch for her implementing the
>> functionality they were after: https://lkml.org/lkml/2012/4/10/41
>>
>> Unfortunately this still somehow made it into the kernel. I guess the
>> angle of having LEDs auto-shutoff makes sense still; using it for
>> haptics does not.
>
> Thanks for the pointer.
>
>>>
 Plus, it is not really your decision. Dmitry is maintainer of input
 subsystem, input was doing force feedback for 10+ years, and he
 already made a decision.
>>>
>>> It seems that you applied a fait accompli method here.
>>>
>>> Actually could you share what the decision is? AFAIK we're not
>>> discussing here any patch for the input subsystem?
>>
>> No, we are discussing if it makes sense encouraging 2nd interface for
>> haptic. We are also discussing whether it makes sense to implement new
>> features in LED subsystem that seem to be only beneficial for this
>> interface (I assume the "normal" LEDs do not need that kind of
>> precision?).
>
> As you noticed in one of the previous messages, thanks to the leds-gpio
> driver we can drive a wide range of devices from the level of
> LED subsystem.

Yes, you can create whatever. It goes normally as this: crap, we need
to ship something really soon, factory build is a week from now and we
have absolutely no time to think about proper interface. Hey, let's
quickly bolt on some quirk on an unrelated interface, it almost does
what we want. We do not care that out use case does not really fit
here, our custom one-off userspace will know how to deal with it.

> LED trigger mechanism makes it even more versatile,
> and, in this area, even somehow akin to the GPIO subsystem. In the
> future we could think of making this trigger mechanism accessible by
> the two and thus any initiative aiming at enhancing it shouldn't be
> discouraged.

If there is a use case that would benefit from this functionality:
certainly. Do you have one in mind?

Thanks.

-- 
Dmitry
--
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: [v8 0/4] cgroup-aware OOM killer

[David Rientjes]

On Fri, 15 Sep 2017, Roman Gushchin wrote:

> > > > But then you just enforce a structural restriction on your configuration
> > > > because
> > > > root
> > > > /  \
> > > >AD
> > > >   /\   
> > > >  B  C
> > > > 
> > > > is a different thing than
> > > > root
> > > > / | \
> > > >B  C  D
> > > >
> > > 
> > > I actually don't have a strong argument against an approach to select
> > > largest leaf or kill-all-set memcg. I think, in practice there will be
> > > no much difference.
> > > 
> > > The only real concern I have is that then we have to do the same with
> > > oom_priorities (select largest priority tree-wide), and this will limit
> > > an ability to enforce the priority by parent cgroup.
> > > 
> > 
> > Yes, oom_priority cannot select the largest priority tree-wide for exactly 
> > that reason.  We need the ability to control from which subtree the kill 
> > occurs in ancestor cgroups.  If multiple jobs are allocated their own 
> > cgroups and they can own memory.oom_priority for their own subcontainers, 
> > this becomes quite powerful so they can define their own oom priorities.   
> > Otherwise, they can easily override the oom priorities of other cgroups.
> 
> I believe, it's a solvable problem: we can require CAP_SYS_RESOURCE to set
> the oom_priority below parent's value, or something like this.
> 
> But it looks more complex, and I'm not sure there are real examples,
> when we have to compare memcgs, which are on different levels
> (or in different subtrees).
> 

It's actually much more complex because in our environment we'd need an 
"activity manager" with CAP_SYS_RESOURCE to control oom priorities of user 
subcontainers when today it need only be concerned with top-level memory 
cgroups.  Users can create their own hierarchies with their own oom 
priorities at will, it doesn't alter the selection heuristic for another 
other user running on the same system and gives them full control over the 
selection in their own subtree.  We shouldn't need to have a system-wide 
daemon with CAP_SYS_RESOURCE be required to manage subcontainers when 
nothing else requires it.  I believe it's also much easier to document: 
oom_priority is considered for all sibling cgroups at each level of the 
hierarchy and the cgroup with the lowest priority value gets iterated.
--
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: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Jacek Anaszewski]

On 09/19/2017 12:29 AM, Dmitry Torokhov wrote:
> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
>  wrote:
>> Hi,
>>
>> On 09/17/2017 08:22 PM, Pavel Machek wrote:
>>> Hi!
>>>
> If your objection is that FF is not easily engaged from the shell -
> yes, but I do not think that actual users who want to do vibration do
> that via shell either. On the other hand, can you drop privileges and
> still allow a certain process control your vibrator via LED interface?
> With FF you can pass an FD to whoever you deem worthy and later revoke
> access.
>
> IOW sysfs interfaces are nice for quick hacks, but when you want to
> use them in real frameworks, where you need to think about proper
> namespaces, isolation, etc, etc, other kinds of interfaces might suit
> better.

 I'd leave the decision to the user. We could add a note to the
 Documentation/leds/ledtrig-transient.txt that force feedback interface
 should be preferable choice for driving vibrate devices.
>>>
>>> We don't want to leave decision to the user; because then we'll end up
>>> with userland applications having to support _both_ interfaces.
>>
>> This state has lasted for five years now. I don't recall any
>> complaints. Do you?
> 
> I was telling Shuah 5 years ago that using LED for what she wanted was
> not the right idea. I even made a patch for her implementing the
> functionality they were after: https://lkml.org/lkml/2012/4/10/41
> 
> Unfortunately this still somehow made it into the kernel. I guess the
> angle of having LEDs auto-shutoff makes sense still; using it for
> haptics does not.

Thanks for the pointer.

>>
>>> Plus, it is not really your decision. Dmitry is maintainer of input
>>> subsystem, input was doing force feedback for 10+ years, and he
>>> already made a decision.
>>
>> It seems that you applied a fait accompli method here.
>>
>> Actually could you share what the decision is? AFAIK we're not
>> discussing here any patch for the input subsystem?
> 
> No, we are discussing if it makes sense encouraging 2nd interface for
> haptic. We are also discussing whether it makes sense to implement new
> features in LED subsystem that seem to be only beneficial for this
> interface (I assume the "normal" LEDs do not need that kind of
> precision?).

As you noticed in one of the previous messages, thanks to the leds-gpio
driver we can drive a wide range of devices from the level of
LED subsystem. LED trigger mechanism makes it even more versatile,
and, in this area, even somehow akin to the GPIO subsystem. In the
future we could think of making this trigger mechanism accessible by
the two and thus any initiative aiming at enhancing it shouldn't be
discouraged.

 However only if following conditions are met:
 - force feedback driver supports gpio driven devices
 - there is sample application in tools/input showing how to
   setup gpio driven vibrate device with use of ff interface
 - it will be possible to setup vibrate interval with 1ms accuracy,
   similarly to what the discussed patch allows to do
>>>
>>> I agree these would be nice. Interested parties are welcome to help
>>> there. But I don't think this should have any impact on LED
>>> susbystem. Force feedback just does not belong to LED subsystem.
>>
>> You cut off important piece of my text from the beginning of this
>> paragraph. It was:
>>
>>> I'd leave the decision to the user. We could add a note to the
>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>> should be preferable choice for driving vibrate devices.
>>> However only if following conditions are met:
>>
>> What I meant is that it is my decision, as a LED subsystem maintainer,
>> to accept the addition of a note about some other subsystem offering
>> an equivalent or even better substitute of the feature being available
>> in the subsystem I am responsible for. And I will accept such a patch
>> only if mentioned conditions are met.
> 
> Having the wording in documentation does not in any way stops Android
> folks from continuing [ab]using the transient trigger. But this is
> their choice. The purpose of documentation is to document the best
> practices, not all possible crazy solutions one can come up with.

Yes. but if the information has been in place for years, we can't
just remove it without giving an instruction on how to use the
substitute.

-- 
Best regards,
Jacek Anaszewski
--
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 3/3 v11] printk: Add monotonic, boottime, and realtime timestamps

[Prarit Bhargava]

On 09/17/2017 06:46 AM, Sergey Senozhatsky wrote:

> I'm a bit uncomfortable with the "breaks user space" part. since this
> is a strictly debugging option, would it be sufficient to store those
> extended timestamps as prefixes of every message?
> see (sorry for "self-quoting"):
>   lkml.kernel.org/r/20170917062608.GA512@tigerII.localdomain
>

Sergey, I haven't forgotten about the above.  It's something
I'm going to look at after this initial patchset is done.

P.

> each message, thus, will be in the following format
> 
> [current header: loglevel, timestamp, etc] [extended printk data] message text
> 
> extended printk data can contain your monotonic/etc timestamps, and
> anything else.
> 
> and then it's up to you how do you grep the messages and process the
> extended data. but the point is - user space tools (journald, dmesg,
> etc.) stays intact. which is kinda nice.
> 
> so we can avoid that chicken and egg problem: we break user space
> by merging the patchset but user space people don't want to talk
> about any fixes until we break those tools.
> 
>   -ss
> 
--
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

[PATCH] scripts/kernel-doc: warn on excess enum value descriptions

[Johannes Berg]

From: Johannes Berg 

The existing message
"Excess struct/union/enum/typedef member [...]"
made it sound like this would already be done, but the
code is never invoked for enums or typedefs (and really
can't be).

Add some code to the enum dumper to handle this there
instead.

While at it, also make the above message more accurate
by simply dumping the type that was passed in, and pass
the struct/union differentiation in.

Signed-off-by: Johannes Berg 
---
 scripts/kernel-doc | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9d3eafea58f0..67d051edd615 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2168,7 +2168,7 @@ sub dump_struct($$) {
 my $nested;
 
 if ($x =~ /(struct|union)\s+(\w+)\s*{(.*)}/) {
-   #my $decl_type = $1;
+   my $decl_type = $1;
$declaration_name = $2;
my $members = $3;
 
@@ -2194,7 +2194,7 @@ sub dump_struct($$) {
$members =~ s/DECLARE_HASHTABLE\s*\(([^,)]+), ([^,)]+)\)/unsigned long 
$1\[1 << (($2) - 1)\]/gos;
 
create_parameterlist($members, ';', $file);
-   check_sections($file, $declaration_name, "struct", $sectcheck, 
$struct_actual, $nested);
+   check_sections($file, $declaration_name, $decl_type, $sectcheck, 
$struct_actual, $nested);
 
output_declaration($declaration_name,
   'struct',
@@ -2226,6 +2226,8 @@ sub dump_enum($$) {
 if ($x =~ /enum\s+(\w+)\s*{(.*)}/) {
$declaration_name = $1;
my $members = $2;
+   my %_members;
+
$members =~ s/\s+$//;
 
foreach my $arg (split ',', $members) {
@@ -2236,9 +2238,16 @@ sub dump_enum($$) {
print STDERR "${file}:$.: warning: Enum value '$arg' ".
"not described in enum '$declaration_name'\n";
}
-
+   $_members{$arg} = 1;
}
 
+   while (my ($k, $v) = each %parameterdescs) {
+   if (!exists($_members{$k})) {
+print STDERR "${file}:$.: warning: Excess enum value " .
+ "'$k' description in '$declaration_name'\n";
+   }
+}
+
output_declaration($declaration_name,
   'enum',
   {'enum' => $declaration_name,
@@ -2506,7 +2515,7 @@ sub check_sections($$) {
} else {
if ($nested !~ m/\Q$sects[$sx]\E/) {
print STDERR "${file}:$.: warning: " .
-   "Excess struct/union/enum/typedef 
member " .
+   "Excess $decl_type member " .
"'$sects[$sx]' " .
"description in '$decl_name'\n";
++$warnings;
-- 
2.14.1

--
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