* Re: [PATCH 1/1] Remap Acer WMI touchpad toggle key to F21 used by X
From: Martin Pitt @ 2011-03-01 11:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298978205-31767-1-git-send-email-jlee@novell.com>
Hello Lee,
Lee, Chun-Yi [2011-03-01 19:16 +0800]:
> Currently, Acer WMI driver generates KEY_F22 but this
> will soon change to KEY_TOUCHPAD_TOOGLE.
>
> X has defined F21 for the purpose of touchpad toggle and other
> udev keymaps align with this meaning. Patch aligns Acer WMI
> hotkey drivers with F21.
Right, that's what we've agreed on between X.org and udev.
Applied, thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH 1/1] Remap Acer WMI touchpad toggle key to F21 used
From: Joey Lee @ 2011-03-01 13:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298978205-31767-1-git-send-email-jlee@novell.com>
Hi Martin,
於 二，2011-03-01 於 12:54 +0100，Martin Pitt 提到：
> Hello Lee,
>
> Lee, Chun-Yi [2011-03-01 19:16 +0800]:
> > Currently, Acer WMI driver generates KEY_F22 but this
> > will soon change to KEY_TOUCHPAD_TOOGLE.
> >
> > X has defined F21 for the purpose of touchpad toggle and other
> > udev keymaps align with this meaning. Patch aligns Acer WMI
> > hotkey drivers with F21.
>
> Right, that's what we've agreed on between X.org and udev.
>
> Applied, thanks!
>
> Martin
Thank's and I will send patch to modify the touchpad toggle key in
acer-wmi driver.
Thank's
Joey Lee
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set of
From: Vilius Benetis @ 2011-03-01 14:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
[Vilius]
> tomorrow I will play with the code.
the resulting UDEV rules (with reference to works of Adrian Crenshaw),
for those who are interested:
#By default, disable it.
ACTION="add", SUBSYSTEMS="usb", RUN+="/bin/sh -c 'for host in
/sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default;
done'"
#Enable hub devices.
ACTION="add", ATTR{bDeviceClass}="09", RUN+="/bin/sh -c 'echo 1
>/sys$DEVPATH/authorized'"
#Other things to enable, do nto forget to add mouse, and other devices.
ACTION="add", ATTRS{product}="VendorX", ATTRS{serial}="0xxxxxx",
RUN+="/bin/sh -c 'echo 1 >/sys$DEVPATH/authorized'"
--
/Vilius
^ permalink raw reply
* external udev rules which list devices
From: Johannes Meixner @ 2011-03-01 14:55 UTC (permalink / raw)
To: linux-hotplug
Hello,
in short:
I ask for an udev enhancement to make support for external
rules easier - in particular as a first step - support
for external listings of device IDs so that generic udev rules
could be applied to those devices.
Reasoning:
Currently udev rules which basically list devices which are
supported by external packages (usually peripheral devices)
so that a generic udev rule is applied to those devices
are in the external software packages which support the devices.
E.g. listings of USB vendor and product IDs for USB scanners
so that an ACL via udev's 70-acl.rules is applied.
Currently the scanner driver package sane-backends provides
its devices list as /etc/udev/rules.d/55-libsane.rules
and the package hplip for HP all-in-one devices provides
its devices list as /etc/udev/rules.d/55-hpmud.rules
In those device list rules the "libsane_matched" variable
is set to "yes" via entries like (long lines wrapped here):
-------------------------------------------------------------------
ACTION!="add", GOTO="libsane_rules_end"
SUBSYSTEMS="scsi", GOTO="libsane_scsi_rules_begin"
SUBSYSTEM="usb", GOTO="libsane_usb_rules_begin"
SUBSYSTEM!="usb", GOTO="libsane_usb_rules_end"
LABEL="libsane_usb_rules_begin"
...
# Epson GT-7700U | Epson Perfection 1240U | Epson Perfection 1240
ATTR{idVendor}="04b8", ATTR{idProduct}="010b", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
# Epson GT-6700U | Epson Perfection 640U | Epson Perfection 640
ATTR{idVendor}="04b8", ATTR{idProduct}="010c", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
...
LABEL="libsane_usb_rules_end"
SUBSYSTEMS!="scsi", GOTO="libsane_scsi_rules_end"
LABEL="libsane_scsi_rules_begin"
...
# Generic: SCSI device type 6 indicates a scanner
KERNEL="sg[0-9]*", ATTR{type}="6", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
# Some scanners advertise themselves as SCSI device type 3
# Epson Perfection 2450 | Epson Perfection 2450 PHOTO
KERNEL="sg[0-9]*", ATTR{type}="3", ATTR{vendor}="EPSON",
ATTR{model}="GT-9700", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
...
LABEL="libsane_scsi_rules_end"
LABEL="libsane_rules_end"
-------------------------------------------------------------------
Unfortunately the syntax of udev rules files and in particular the
values like event value, subsystem value, sysfs attribute values,
and device property values are not meant to be some kind
of "stable interface" so that external software could add
its own rules and rely on that this works "forever".
Regardless that the curent state seems to be pretty stable,
there is no guarantee and it might change in any udev release.
This results a dilemma:
On the one hand:
Because udev rules files are not meant as a "stable interface",
all udev rules files should be part of the udev package.
On the other hand:
If even the udev rules files which basically only list devices
would be part of the udev package, an upgrade of an external
software package to provides support for more external devices
would require an upgrade of udev to get an up-to-date list
of the new supported devices.
Therefore I ask for an udev enhancement to have a stable interface
so that external software packages could provide at least plain
list of devices to udev so that generic udev rules can be applied
to those devices.
There would have to be also a stable interface to specify
which particular generic udev rules should be applied.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
^ permalink raw reply
* [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Vincent Guittot @ 2011-03-01 16:05 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty, tglx
This patchset adds some tracepoints for tracing cpu state and for
profiling the plug and unplug sequence.
Some SMP arm platform uses cpu hotplug feature for improving their
power saving because they can go into their deepest idle state only in
mono core mode. In addition, running into mono core mode makes the
cpuidle job easier and more efficient which also results in the
improvement of power saving of some use cases. As the plug state of a
cpu can impact the cpuidle behavior, it's interesting to trace this
state and to correlate it with cpuidle traces.
Then, cpu hotplug is known to be an expensive operation which also
takes a variable time depending of other processes' activity (from
hundreds ms up to few seconds). These traces have shown that the arch
part stays almost constant on arm platform whatever the cpu load is,
whereas the plug duration increases.
---
include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
kernel/cpu.c | 18 ++++++
2 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/cpu_hotplug.h
^ permalink raw reply
* [PATCH V6 1/2] tracing, perf: cpu hotplug trace events
From: Vincent Guittot @ 2011-03-01 16:06 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty, tglx
Define new events for tracing cpu hotplug
* trace time spent in core and arch dependant code
* trace the state of cpu
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/cpu_hotplug.h
diff --git a/include/trace/events/cpu_hotplug.h
b/include/trace/events/cpu_hotplug.h
new file mode 100644
index 0000000..54a7f97
--- /dev/null
+++ b/include/trace/events/cpu_hotplug.h
@@ -0,0 +1,103 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpu_hotplug
+
+#if !defined(_TRACE_CPU_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPU_HOTPLUG_H
+
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(cpu_hotplug,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid),
+
+ TP_STRUCT__entry(
+ __field( unsigned int, cpuid )
+ ),
+
+ TP_fast_assign(
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("cpuid=%u", __entry->cpuid)
+);
+
+/* Core function of cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+/* Architecture function for cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+#endif /* _TRACE_CPU_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.1
^ permalink raw reply related
* [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Vincent Guittot @ 2011-03-01 16:06 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty, tglx
Trace the cpu state and the time spent in core and arch code
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
kernel/cpu.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 156cc55..8abb84b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,6 +16,9 @@
#include <linux/mutex.h>
#include <linux/gfp.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/cpu_hotplug.h>
+
#ifdef CONFIG_SMP
/* Serializes the updates to cpu_online_mask, cpu_present_mask */
static DEFINE_MUTEX(cpu_add_remove_lock);
@@ -197,10 +200,13 @@ struct take_cpu_down_param {
static int __ref take_cpu_down(void *_param)
{
struct take_cpu_down_param *param = _param;
+ unsigned int cpu = (unsigned int)(param->hcpu);
int err;
/* Ensure this CPU doesn't handle any more interrupts. */
+ trace_cpu_hotplug_disable_start(cpu);
err = __cpu_disable();
+ trace_cpu_hotplug_disable_end(cpu);
if (err < 0)
return err;
@@ -256,7 +262,9 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
cpu_relax();
/* This actually kills the CPU. */
+ trace_cpu_hotplug_die_start(cpu);
__cpu_die(cpu);
+ trace_cpu_hotplug_die_end(cpu);
/* CPU is completely dead: tell everyone. Too late to complain. */
cpu_notify_nofail(CPU_DEAD | mod, hcpu);
@@ -276,6 +284,8 @@ int __ref cpu_down(unsigned int cpu)
cpu_maps_update_begin();
+ trace_cpu_hotplug_down_start(cpu);
+
if (cpu_hotplug_disabled) {
err = -EBUSY;
goto out;
@@ -284,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
err = _cpu_down(cpu, 0);
out:
+ trace_cpu_hotplug_down_end(cpu);
+
cpu_maps_update_done();
return err;
}
@@ -310,7 +322,9 @@ static int __cpuinit _cpu_up(unsigned int cpu, int
tasks_frozen)
}
/* Arch-specific enabling code. */
+ trace_cpu_hotplug_arch_up_start(cpu);
ret = __cpu_up(cpu);
+ trace_cpu_hotplug_arch_up_end(cpu);
if (ret != 0)
goto out_notify;
BUG_ON(!cpu_online(cpu));
@@ -369,6 +383,8 @@ int __cpuinit cpu_up(unsigned int cpu)
cpu_maps_update_begin();
+ trace_cpu_hotplug_up_start(cpu);
+
if (cpu_hotplug_disabled) {
err = -EBUSY;
goto out;
@@ -377,6 +393,8 @@ int __cpuinit cpu_up(unsigned int cpu)
err = _cpu_up(cpu, 0);
out:
+ trace_cpu_hotplug_up_end(cpu);
+
cpu_maps_update_done();
return err;
}
--
1.7.1
^ permalink raw reply related
* Re: How to use Udev to restrict USB access only to particular set
From: Bryan Kadzban @ 2011-03-02 7:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
Vilius Benetis wrote:
> [Vilius]
>> tomorrow I will play with the code.
> the resulting UDEV rules (with reference to works of Adrian Crenshaw),
> for those who are interested:
>
> #By default, disable it.
> ACTION="add", SUBSYSTEMS="usb", RUN+="/bin/sh -c 'for host in
> /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default;
> done'"
It may not be possible to do what I'm about to suggest with this rule
(unless there's a way to match on all devices that have an
authorized_default file -- I'm not sure where in the USB stack those
devices are), but for this rule:
> #Enable hub devices.
> ACTION="add", ATTR{bDeviceClass}="09", RUN+="/bin/sh -c 'echo 1
>> /sys$DEVPATH/authorized'"
(and the one below it), can't you just do this instead of the RUN?:
ATTR{authorized}="1"
Or does that not work for some reason? (It'll prevent spawning a whole
lot of shells to do work that udev already has code to handle...)
^ permalink raw reply
* Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Ingo Molnar @ 2011-03-02 7:56 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
rusty, tglx, Arjan van de Ven, Thomas Renninger, Alan Cox,
Peter Zijlstra, H. Peter Anvin, Andrew Morton
In-Reply-To: <AANLkTinbYWQxde2jTcAtyYQGvGgt2Lmtnph=voj=haXF@mail.gmail.com>
* Vincent Guittot <vincent.guittot@linaro.org> wrote:
> This patchset adds some tracepoints for tracing cpu state and for
> profiling the plug and unplug sequence.
>
> Some SMP arm platform uses cpu hotplug feature for improving their
> power saving because they can go into their deepest idle state only in
> mono core mode. In addition, running into mono core mode makes the
> cpuidle job easier and more efficient which also results in the
> improvement of power saving of some use cases. As the plug state of a
> cpu can impact the cpuidle behavior, it's interesting to trace this
> state and to correlate it with cpuidle traces.
> Then, cpu hotplug is known to be an expensive operation which also
> takes a variable time depending of other processes' activity (from
> hundreds ms up to few seconds). These traces have shown that the arch
> part stays almost constant on arm platform whatever the cpu load is,
> whereas the plug duration increases.
>
> ---
> include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
> kernel/cpu.c | 18 ++++++
> 2 files changed, 121 insertions(+), 0 deletions(-)
> create mode 100644 include/trace/events/cpu_hotplug.h
Why not do something much simpler and fit these into the existing power:* events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend
power:cpu_idle
power:cpu_frequency
power:machine_suspend
in an intelligent way?
CPU hotplug is really a 'soft' form of suspend and tools using power events could
thus immediately use CPU hotplug events as well.
A suitable new 'state' value could be used to signal CPU hotplug events:
enum {
POWER_NONE = 0,
POWER_CSTATE = 1,
POWER_PSTATE = 2,
};
POWER_HSTATE for hotplug-state, or so.
This would also express the design arguments that others have pointed out in the
prior discussion: that CPU hotplug is really a power management variant, and that in
the long run it could be done via regular idle as well. When that happens, the above
unified event structure makes it all even simpler - analysis tools will just
continue to work fine.
Thanks,
Ingo
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set of
From: Vilius Benetis @ 2011-03-02 8:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
On Wed, Mar 2, 2011 at 9:06 AM, Bryan Kadzban
<bryan@kadzban.is-a-geek.net> wrote:
> Vilius Benetis wrote:
>> [Vilius]
>>> tomorrow I will play with the code.
>> the resulting UDEV rules (with reference to works of Adrian Crenshaw),
>> for those who are interested:
>>
>> #By default, disable it.
>> ACTION="add", SUBSYSTEMS="usb", RUN+="/bin/sh -c 'for host in
>> /sys/bus/usb/devices/usb*; do echo 0 > $host/authorized_default;
>> done'"
>
> It may not be possible to do what I'm about to suggest with this rule
> (unless there's a way to match on all devices that have an
> authorized_default file -- I'm not sure where in the USB stack those
> devices are), but for this rule:
>
>> #Enable hub devices.
>> ACTION="add", ATTR{bDeviceClass}="09", RUN+="/bin/sh -c 'echo 1
>>> /sys$DEVPATH/authorized'"
>
> (and the one below it), can't you just do this instead of the RUN?:
>
> ATTR{authorized}="1"
>
> Or does that not work for some reason? Â (It'll prevent spawning a whole
> lot of shells to do work that udev already has code to handle...)
we tested, ATTR{authorized}="1" works well, for
ATTR{authorized_default}="0" we get an error during the boot, but it
still works (probably the error is due to the yet non-existing
device?):
error opening ATTR{/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input11/event9/authorized}
for writing: No such file or directory
If you have an idea how to get rid of this error, please share.
the rules have been used:
#By default, disable it.
ACTION="add", SUBSYSTEMS="usb", ATTR{authorized_default}="0"
#Enable hub devices.
ACTION="add", ATTR{bDeviceClass}="09", ATTR{authorized}="1"
#Other things to enable
ACTION="add", ATTRS{idProduct}="c052", ATTR{authorized}="1"
--
/Vilius
^ permalink raw reply
* Re: [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Thomas Gleixner @ 2011-03-02 9:38 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty
In-Reply-To: <AANLkTi=WRo41JprvcEH0Lgc_-j_bTX1MULgJFShV6W9g@mail.gmail.com>
On Tue, 1 Mar 2011, Vincent Guittot wrote:
> Trace the cpu state and the time spent in core and arch code
So you completely ignored my review comments, except for fixing up the
changelog.
https://lkml.org/lkml/2011/2/24/297
All of the comments in the code still apply and either you fix it or
at least have the courtesy to explain why you think that those
comments do not need to be addressed.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Vincent Guittot @ 2011-03-02 9:50 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty
In-Reply-To: <alpine.LFD.2.00.1103021033260.2701@localhost6.localdomain6>
On 2 March 2011 10:38, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 1 Mar 2011, Vincent Guittot wrote:
>
>> Trace the cpu state and the time spent in core and arch code
>
> So you completely ignored my review comments, except for fixing up the
> changelog.
>
> https://lkml.org/lkml/2011/2/24/297
>
> All of the comments in the code still apply and either you fix it or
> at least have the courtesy to explain why you think that those
> comments do not need to be addressed.
>
I thought that I have answered to your comments :
https://lkml.org/lkml/2011/2/28/203
Do I miss something ?
Thanks,
Vincent
> Thanks,
>
> tglx
>
^ permalink raw reply
* RE: fixed id for mouse and keyboard
From: MONDON Daniel @ 2011-03-02 9:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <D604D5FB4D200642AA2FAAE94E392586011146E8@CARAMBAR.lpg.priv>
Somebody have an idea ?
Thanks,
Daniel.
-----Message d'origine-----
Hi,
It looks like there is no solution ! :(
Daniel.
-----Message d'origine-----
De : linux-hotplug-owner@vger.kernel.org [mailto:linux-hotplug-owner@vger.kernel.org] De la part de MONDON Daniel
Envoyé : lundi 14 février 2011 09:54
À : linux-hotplug@vger.kernel.org
Objet : fixed id for mouse and keyboard
Hi,
For users, i have computers with TouchScreen, and application without
any mouse and keyboard.
(no access to system).
1 - There is a driver conflict between mouse and TouchScreen : multi
press and release.
I (or technicians) have to go on the machines to control them (plugging
keyboard).
2 - I want to help them to access to parts of systems by programming
shortchuts.
BUT
Hot plugged, Mouse or Keyboard are not identicaly identified (because
rarely the sames).
Both problems could be solved if i know how i can affect an unique ID
(and event) to all usb mouses and all keyboards.
How can i do that, or if i have to use an other solution ?
(For mouse, i've got the solution by eeti (eGalax driver).)
(For keyboard, i know how catching keyboard event.)
Thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Thomas Gleixner @ 2011-03-02 9:55 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria,
mingo, rusty
In-Reply-To: <AANLkTikzfNsB=9jQSYrWDEYd3Kd1-d8cVMO79ZqDNt4n@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 833 bytes --]
On Wed, 2 Mar 2011, Vincent Guittot wrote:
> On 2 March 2011 10:38, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Tue, 1 Mar 2011, Vincent Guittot wrote:
> >
> >> Trace the cpu state and the time spent in core and arch code
> >
> > So you completely ignored my review comments, except for fixing up the
> > changelog.
> >
> > https://lkml.org/lkml/2011/2/24/297
> >
> > All of the comments in the code still apply and either you fix it or
> > at least have the courtesy to explain why you think that those
> > comments do not need to be addressed.
> >
>
> I thought that I have answered to your comments :
> https://lkml.org/lkml/2011/2/28/203
>
> Do I miss something ?
Oops, my bad. I missed that reply somehow. It's not in my inbox. Will
dig into my lkml archive then.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Ingo Molnar @ 2011-03-02 9:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Vincent Guittot, linux-kernel, linux-hotplug, fweisbec, rostedt,
amit.kucheria, rusty
In-Reply-To: <alpine.LFD.2.00.1103021053480.2701@localhost6.localdomain6>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 2 Mar 2011, Vincent Guittot wrote:
>
> > On 2 March 2011 10:38, Thomas Gleixner <tglx@linutronix.de> wrote:
> > > On Tue, 1 Mar 2011, Vincent Guittot wrote:
> > >
> > >> Trace the cpu state and the time spent in core and arch code
> > >
> > > So you completely ignored my review comments, except for fixing up the
> > > changelog.
> > >
> > > https://lkml.org/lkml/2011/2/24/297
> > >
> > > All of the comments in the code still apply and either you fix it or
> > > at least have the courtesy to explain why you think that those
> > > comments do not need to be addressed.
> > >
> >
> > I thought that I have answered to your comments :
> > https://lkml.org/lkml/2011/2/28/203
> >
> > Do I miss something ?
>
> Oops, my bad. I missed that reply somehow. It's not in my inbox. Will
> dig into my lkml archive then.
Hm, same here, i only got that reply from lkml, never via direct mail delivery. So
something ate the straight path of that mail.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-03-02 10:08 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, Frederic Weisbecker, Steven Rostedt,
amit.kucheria, Rusty Russell, Ingo Molnar
In-Reply-To: <AANLkTik1Aqt8qJ62h4k0PbLOU7qu3TtA=fWn=LJ6tQjc@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2796 bytes --]
Vincent,
On Mon, 28 Feb 2011, Vincent Guittot wrote:
> On 24 February 2011 19:40, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, 24 Feb 2011, Vincent Guittot wrote:
Sorry, this mail got eaten somehow, but I got it from my archive.
> >> #ifdef CONFIG_SMP
> >> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
> >> static DEFINE_MUTEX(cpu_add_remove_lock);
> >> @@ -197,10 +200,13 @@ struct take_cpu_down_param {
> >> static int __ref take_cpu_down(void *_param)
> >> {
> >> struct take_cpu_down_param *param = _param;
> >> + unsigned int cpu = (unsigned int)(param->hcpu);
> >> int err;
> >>
> >> /* Ensure this CPU doesn't handle any more interrupts. */
> >> + trace_cpu_hotplug_disable_start(cpu);
> >> err = __cpu_disable();
> >> + trace_cpu_hotplug_disable_end(cpu);
> >
> > How useful. What about recording the return code of __cpu_disable()?
> >
>
> The goal is to monitor the cpu hotplug activity and duration. I want
> to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
> unplug/plug a core and ones which don't. But I'm not sure that we need
> to sort the failed calls into to the trace. We trace them because too
> much fails could point out a bug or a wrong use of cpu hotplug.
This does not make sense at all. You want to see the failures, then
recording the error code makes even more sense. Your way of decoding
the error case by checking whether the next trace entry is there or
missing is just sloppy.
> >> if (err < 0)
> >> return err;
> >
> >> + trace_cpu_hotplug_down_start(cpu);
> >> +
> >
> > What's the point of this tracepoint _BEFORE_ the cpu_hotplug_disabled
> > check without recording cpu_hotplug_disabled ?
> >
>
> I want to trace all cpu_down call even those which returns immediately
> which will be part of the failed calls.
Decoding failure from missing entries is simply wrong.
> >> if (cpu_hotplug_disabled) {
> >> err = -EBUSY;
> >> goto out;
> >> @@ -284,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
> >> err = _cpu_down(cpu, 0);
> >>
> >> out:
> >> + trace_cpu_hotplug_down_end(cpu);
> >
> > And this one is misplaced as well. It wants to be only called when we
> > actually called _cpu_down() and it wants to record the return code as
> > well.
> >
>
> It has been placed here to be called each time
> trace_cpu_hotplug_down_start is called.
That does not make sense at all. You cannot distinguish between
cpu_hotplug_disabled set and the _cpu_down() being called case. Or do
you want to tell me that you decode that from the time stamps? Hell
no. We want traces which are readable w/o crystal balls.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Thomas Renninger @ 2011-03-02 10:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Vincent Guittot, linux-kernel, linux-hotplug, fweisbec, rostedt,
amit.kucheria, rusty, tglx, Arjan van de Ven, Alan Cox,
Peter Zijlstra, H. Peter Anvin, Andrew Morton, linux-perf-users
In-Reply-To: <20110302075625.GC15665@elte.hu>
On Wednesday, March 02, 2011 08:56:25 AM Ingo Molnar wrote:
>
> * Vincent Guittot <vincent.guittot@linaro.org> wrote:
>
> > This patchset adds some tracepoints for tracing cpu state and for
> > profiling the plug and unplug sequence.
> >
> > Some SMP arm platform uses cpu hotplug feature for improving their
> > power saving because they can go into their deepest idle state only in
> > mono core mode. In addition, running into mono core mode makes the
> > cpuidle job easier and more efficient which also results in the
> > improvement of power saving of some use cases. As the plug state of a
> > cpu can impact the cpuidle behavior, it's interesting to trace this
> > state and to correlate it with cpuidle traces.
> > Then, cpu hotplug is known to be an expensive operation which also
> > takes a variable time depending of other processes' activity (from
> > hundreds ms up to few seconds). These traces have shown that the arch
> > part stays almost constant on arm platform whatever the cpu load is,
> > whereas the plug duration increases.
> >
> > ---
> > include/trace/events/cpu_hotplug.h | 103
> > ++++++++++++++++++++++++++++++++++++
> > kernel/cpu.c | 18 ++++++
> > 2 files changed, 121 insertions(+), 0 deletions(-)
> > create mode 100644 include/trace/events/cpu_hotplug.h
>
> Why not do something much simpler and fit these into the existing
> power:* events:
>
> power:cpu_idle
> power:cpu_frequency
> power:machine_suspend
> power:cpu_idle
> power:cpu_frequency
> power:machine_suspend
>
> in an intelligent way?
>
> CPU hotplug is really a 'soft' form of suspend and tools using power
> events could
> thus immediately use CPU hotplug events as well.
>
> A suitable new 'state' value could be used to signal CPU hotplug events:
>
> enum {
> POWER_NONE = 0,
> POWER_CSTATE = 1,
> POWER_PSTATE = 2,
> };
>
> POWER_HSTATE for hotplug-state, or so.
Be careful, these are obsolete!
This information is in the name of the event itself:
PSTATE -> CPU frequency -> power:cpu_frequency
CSTATE -> sleep/idle states -> power:cpu_idle
> This would also express the design arguments that others have pointed
> out in the prior discussion: that CPU hotplug is really a power
> management variant, and that in the long run it could be done via
> regular idle as well. When that happens, the above unified event
> structure makes it all even simpler - analysis tools will just
> continue to work fine.
About the patch:
You create:
cpu_hotplug:cpu_hotplug_down_start
cpu_hotplug:cpu_hotplug_down_end
cpu_hotplug:cpu_hotplug_up_start
cpu_hotplug:cpu_hotplug_up_end
cpu_hotplug:cpu_hotplug_disable_start
cpu_hotplug:cpu_hotplug_disable_end
cpu_hotplug:cpu_hotplug_die_start
cpu_hotplug:cpu_hotplug_die_end
cpu_hotplug:cpu_hotplug_arch_up_start
cpu_hotplug:cpu_hotplug_arch_up_end
quite some events for cpu hotplugging...
You mix up two things you want to trace:
1) The cpu hotplugging itself which you might want to compare
with system activity, other idle states, etc. and check whether
removing/adding CPUs works in respect of your power saving
algorithms
2) You want to trace the time __cpu_down and friends take to
optimize them
For 1. I agree that it would be worth (mostly for arm now as long as
it's the only arch using this as a power saving feature, but it may show
up on other archs as well) to create an event which looks like:
power:cpu_hotplug(unsigned int state, unsigned int cpu_id)
Define a state:
CPU_HOT_PLUG 1
CPU_HOT_UNPLUG 2
This would be consistent with other power:* events. One idea of having
one event passing the state is, that it does not make sense to track an:
power:cpu_hotunplug or power:cpu_hotplug
standalone.
Theoretically this could get enhanced with further states:
CPU_HOT_PLUG_DISABLE_IRQS 3
CPU_HOT_PLUG_ENABLE_IRQS 4
CPU_HOT_PLUG_ACTIVATE 5
CPU_HOT_PLUG_DISABLE 6
...
if it should be possible at some point to only disable IRQs or to
only disable code processing or to only disable whatever to achieve
better power savings.
But as long as there only is the general cpu_hotplug interface
bringing the cpu totally up or down, above should be enough in
respect of power saving tracings.
For 2. you should use more appropriate tools to optimize the code
processed in __cpu_{,up,down,enable,disable,die} functions and friends.
If you simply need the time, system tab or kprobes might work out for you.
There is preloadtrace.ko based on a system tab script which instruments
functions called at boot up and measures their time.
Or probably better are perf profiling facilities. It should be possible
to profile __cpu_down and subsequent calls in detail. Like that you
should get a good picture which functions you have to look at and
optimize. People in CC should better be able to tell you the exact perf
commands and parameters you are looking for.
Hm, have you tried/thought about registering an extra cpuidle state with
long latency doing the cpu_down? For CPU 0 it could call the deepest
"normal" sleep state, but could decide to shut other cpus down. Like that
you might be able to get rid of some extra code (interfering with cpuidle
driver?) and you get all the statistics, etc. for free.
Thomas
^ permalink raw reply
* Re: [PATCH V6 2/2] tracing, perf: add cpu hotplug trace events
From: Steven Rostedt @ 2011-03-02 16:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Vincent Guittot, linux-kernel, linux-hotplug,
fweisbec, amit.kucheria, rusty
In-Reply-To: <20110302095847.GA24111@elte.hu>
On Wed, 2011-03-02 at 10:58 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> > >
> > > I thought that I have answered to your comments :
> > > https://lkml.org/lkml/2011/2/28/203
> > >
> > > Do I miss something ?
> >
> > Oops, my bad. I missed that reply somehow. It's not in my inbox. Will
> > dig into my lkml archive then.
>
> Hm, same here, i only got that reply from lkml, never via direct mail delivery. So
> something ate the straight path of that mail.
Strange, I got his reply. Perhaps you and Thomas have the same setup
that caused it to be dropped?
-- Steve
^ permalink raw reply
* [PATCH V4] Export ACPI _DSM provided firmware instance number and
From: Narendra_K @ 2011-03-02 17:16 UTC (permalink / raw)
To: linux-pci, linux-hotplug
Cc: netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave,
Shyam_Iyer, sfr
In-Reply-To: <20110223125741.GA16473@fedora14-r610.blr.amer.dell.com>
On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> Hello,
>
> This patch exports ACPI _DSM provided firmware instance number and
> string name to sysfs.
>
> V1 -> V2:
> The attribute 'index' is changed to 'acpi_index' as the semantics of
> SMBIOS provided device type instance and ACPI _DSM provided firmware
> instance number are different.
>
> V2 -> V3:
> Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> error when there are no ACPI _DSM attributes available and because of
> that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> attributes are not created. This version of the patch addresses the issue.
>
V3 -> V4:
Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
breakage from an 'allmodconfig'
Matthew,
Thanks for the suggestion.
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export ACPI _DSM provided firmware instance number and string to sysfs
This patch exports ACPI _DSM (Device Specific Method) provided firmware
instance number and string name of PCI devices as defined by
'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
a PCI or PCI Express Device Under Operating Systems) to sysfs.
New files created are:
/sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
/sys/bus/pci/devices/.../acpi_index which contains the firmware device type
instance for the given device.
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index
1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
Embedded Broadcom 5709C NIC 1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index
2
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
Embedded Broadcom 5709C NIC 2
The ACPI _DSM provided firmware 'instance number' and 'string name' will
be given priority if the firmware also provides 'SMBIOS type 41 device
type instance and string'.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 31 +++-
drivers/pci/Kconfig | 2 +
drivers/pci/Makefile | 3 +-
drivers/pci/pci-label.c | 247 ++++++++++++++++++++++++++++++-
drivers/pci/pci.h | 2 +-
5 files changed, 270 insertions(+), 15 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index f979d82..36bf454 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -145,9 +145,11 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given name(SMBIOS type 41 string) of the PCI device.
- The attribute will be created only if the firmware
- has given a name to the PCI device.
+ given name (SMBIOS type 41 string or ACPI _DSM string) of
+ the PCI device. The attribute will be created only
+ if the firmware has given a name to the PCI device.
+ ACPI _DSM string name will be given priority if the
+ system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
@@ -157,12 +159,27 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given instance(SMBIOS type 41 device type instance)
- of the PCI device. The attribute will be created
- only if the firmware has given a device type instance
- to the PCI device.
+ given instance (SMBIOS type 41 device type instance) of the
+ PCI device. The attribute will be created only if the firmware
+ has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
+
+What: /sys/bus/pci/devices/.../acpi_index
+Date: July 2010
+Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
+Description:
+ Reading this attribute will provide the firmware
+ given instance (ACPI _DSM instance number) of the PCI device.
+ The attribute will be created only if the firmware has given
+ an instance number to the PCI device. ACPI _DSM instance number
+ will be given priority if the system firmware provides SMBIOS
+ type 41 device type instance also.
+Users:
+ Userspace applications interested in knowing the
+ firmware assigned instance number of the PCI
+ device that can help in understanding the firmware
+ intended order of the PCI device.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index a9523fd..c8ff646 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -87,3 +87,5 @@ config PCI_IOAPIC
depends on ACPI
depends on HOTPLUG
default y
+
+select NLS if (DMI || ACPI)
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 98e6fdf..bb1d3b2 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -53,8 +53,9 @@ obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
#
# ACPI Related PCI FW Functions
+# ACPI _DSM provided firmware instance and string name
#
-obj-$(CONFIG_ACPI) += pci-acpi.o
+obj-$(CONFIG_ACPI) += pci-acpi.o pci-label.o
# SMBIOS provided firmware instance and labels
obj-$(CONFIG_DMI) += pci-label.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..824e247 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -5,6 +5,13 @@
* by Narendra K <Narendra_K@dell.com>,
* Jordan Hargrave <Jordan_Hargrave@dell.com>
*
+ * PCI Firmware Specification Revision 3.1 section 4.6.7 (DSM for Naming a
+ * PCI or PCI Express Device Under Operating Systems) defines an instance
+ * number and string name. This code retrieves them and exports them to sysfs.
+ * If the system firmware does not provide the ACPI _DSM (Device Specific
+ * Method), then the SMBIOS type 41 instance number and string is exported to
+ * sysfs.
+ *
* SMBIOS defines type 41 for onboard pci devices. This code retrieves
* the instance number and string from the type 41 record and exports
* it to sysfs.
@@ -19,8 +26,30 @@
#include <linux/pci_ids.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/nls.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
#include "pci.h"
+#define DEVICE_LABEL_DSM 0x07
+
+#ifndef CONFIG_DMI
+
+static inline int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline void
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+}
+
+#else
+
enum smbios_attr_enum {
SMBIOS_ATTR_NONE = 0,
SMBIOS_ATTR_LABEL_SHOW,
@@ -120,9 +149,7 @@ static struct attribute_group smbios_attr_group = {
static int
pci_create_smbiosname_file(struct pci_dev *pdev)
{
- if (!sysfs_create_group(&pdev->dev.kobj, &smbios_attr_group))
- return 0;
- return -ENODEV;
+ return sysfs_create_group(&pdev->dev.kobj, &smbios_attr_group);
}
static void
@@ -131,13 +158,221 @@ pci_remove_smbiosname_file(struct pci_dev *pdev)
sysfs_remove_group(&pdev->dev.kobj, &smbios_attr_group);
}
+#endif
+
+#ifndef CONFIG_ACPI
+
+static inline int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+#else
+
+static const char device_label_dsm_uuid[] = {
+ 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
+ 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
+};
+
+enum acpi_attr_enum {
+ ACPI_ATTR_NONE = 0,
+ ACPI_ATTR_LABEL_SHOW,
+ ACPI_ATTR_INDEX_SHOW,
+};
+
+static void dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
+{
+ int len;
+ len = utf16s_to_utf8s((const wchar_t *)obj->
+ package.elements[1].string.pointer,
+ obj->package.elements[1].string.length,
+ UTF16_LITTLE_ENDIAN,
+ buf, PAGE_SIZE);
+ buf[len] = '\n';
+}
+
+static int
+dsm_get_label(acpi_handle handle, int func,
+ struct acpi_buffer *output,
+ char *buf, enum acpi_attr_enum attribute)
+{
+ struct acpi_object_list input;
+ union acpi_object params[4];
+ union acpi_object *obj;
+ int len = 0;
+
+ int err;
+
+ input.count = 4;
+ input.pointer = params;
+ params[0].type = ACPI_TYPE_BUFFER;
+ params[0].buffer.length = sizeof(device_label_dsm_uuid);
+ params[0].buffer.pointer = (char *)device_label_dsm_uuid;
+ params[1].type = ACPI_TYPE_INTEGER;
+ params[1].integer.value = 0x02;
+ params[2].type = ACPI_TYPE_INTEGER;
+ params[2].integer.value = func;
+ params[3].type = ACPI_TYPE_PACKAGE;
+ params[3].package.count = 0;
+ params[3].package.elements = NULL;
+
+ err = acpi_evaluate_object(handle, "_DSM", &input, output);
+ if (err)
+ return -1;
+
+ obj = (union acpi_object *)output->pointer;
+
+ switch (obj->type) {
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2)
+ break;
+ len = obj->package.elements[0].integer.value;
+ if (buf) {
+ if (attribute = ACPI_ATTR_INDEX_SHOW)
+ scnprintf(buf, PAGE_SIZE, "%llu\n",
+ obj->package.elements[0].integer.value);
+ else if (attribute = ACPI_ATTR_LABEL_SHOW)
+ dsm_label_utf16s_to_utf8s(obj, buf);
+ kfree(output->pointer);
+ return strlen(buf);
+ }
+ kfree(output->pointer);
+ return len;
+ break;
+ default:
+ kfree(output->pointer);
+ }
+ return -1;
+}
+
+static bool
+device_has_dsm(struct device *dev)
+{
+ acpi_handle handle;
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return FALSE;
+
+ if (dsm_get_label(handle, DEVICE_LABEL_DSM, &output, NULL,
+ ACPI_ATTR_NONE) > 0)
+ return TRUE;
+
+ return FALSE;
+}
+
+static mode_t
+acpi_index_string_exist(struct kobject *kobj, struct attribute *attr, int n)
+{
+ struct device *dev;
+
+ dev = container_of(kobj, struct device, kobj);
+
+ if (device_has_dsm(dev))
+ return S_IRUGO;
+
+ return 0;
+}
+
+static ssize_t
+acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_LABEL_SHOW);
+
+ if (length < 1)
+ return -1;
+
+ return length;
+}
+
+static ssize_t
+acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_INDEX_SHOW);
+
+ if (length < 0)
+ return -1;
+
+ return length;
+
+}
+
+static struct device_attribute acpi_attr_label = {
+ .attr = {.name = "label", .mode = 0444},
+ .show = acpilabel_show,
+};
+
+static struct device_attribute acpi_attr_index = {
+ .attr = {.name = "acpi_index", .mode = 0444},
+ .show = acpiindex_show,
+};
+
+static struct attribute *acpi_attributes[] = {
+ &acpi_attr_label.attr,
+ &acpi_attr_index.attr,
+ NULL,
+};
+
+static struct attribute_group acpi_attr_group = {
+ .attrs = acpi_attributes,
+ .is_visible = acpi_index_string_exist,
+};
+
+static int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return sysfs_create_group(&pdev->dev.kobj, &acpi_attr_group);
+}
+
+static int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ sysfs_remove_group(&pdev->dev.kobj, &acpi_attr_group);
+ return 0;
+}
+#endif
+
void pci_create_firmware_label_files(struct pci_dev *pdev)
{
- if (!pci_create_smbiosname_file(pdev))
- ;
+ if (device_has_dsm(&pdev->dev))
+ pci_create_acpi_index_label_files(pdev);
+ else
+ pci_create_smbiosname_file(pdev);
}
void pci_remove_firmware_label_files(struct pci_dev *pdev)
{
- pci_remove_smbiosname_file(pdev);
+ if (device_has_dsm(&pdev->dev))
+ pci_remove_acpi_index_label_files(pdev);
+ else
+ pci_remove_smbiosname_file(pdev);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f69d6e0..a6ec200 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,7 +11,7 @@
extern int pci_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int pci_create_sysfs_dev_files(struct pci_dev *pdev);
extern void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
-#ifndef CONFIG_DMI
+#if !defined(CONFIG_DMI) && !defined(CONFIG_ACPI)
static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
{ return; }
static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Vincent Guittot @ 2011-03-02 19:02 UTC (permalink / raw)
To: Thomas Renninger
Cc: Ingo Molnar, linux-kernel, linux-hotplug, fweisbec, rostedt,
amit.kucheria, rusty, tglx, Arjan van de Ven, Alan Cox,
Peter Zijlstra, H. Peter Anvin, Andrew Morton, linux-perf-users
In-Reply-To: <201103021157.08260.trenn@suse.de>
On 2 March 2011 11:57, Thomas Renninger <trenn@suse.de> wrote:
> On Wednesday, March 02, 2011 08:56:25 AM Ingo Molnar wrote:
>>
>> * Vincent Guittot <vincent.guittot@linaro.org> wrote:
>>
>> > This patchset adds some tracepoints for tracing cpu state and for
>> > profiling the plug and unplug sequence.
>> >
>> > Some SMP arm platform uses cpu hotplug feature for improving their
>> > power saving because they can go into their deepest idle state only in
>> > mono core mode. In addition, running into mono core mode makes the
>> > cpuidle job easier and more efficient which also results in the
>> > improvement of power saving of some use cases. As the plug state of a
>> > cpu can impact the cpuidle behavior, it's interesting to trace this
>> > state and to correlate it with cpuidle traces.
>> > Then, cpu hotplug is known to be an expensive operation which also
>> > takes a variable time depending of other processes' activity (from
>> > hundreds ms up to few seconds). These traces have shown that the arch
>> > part stays almost constant on arm platform whatever the cpu load is,
>> > whereas the plug duration increases.
>> >
>> > ---
>> > include/trace/events/cpu_hotplug.h | 103
>> > ++++++++++++++++++++++++++++++++++++
>> > kernel/cpu.c | 18 ++++++
>> > 2 files changed, 121 insertions(+), 0 deletions(-)
>> > create mode 100644 include/trace/events/cpu_hotplug.h
>>
>> Why not do something much simpler and fit these into the existing
>> power:* events:
>>
>> power:cpu_idle
>> power:cpu_frequency
>> power:machine_suspend
>> power:cpu_idle
>> power:cpu_frequency
>> power:machine_suspend
>>
>> in an intelligent way?
>>
>> CPU hotplug is really a 'soft' form of suspend and tools using power
>> events could
>> thus immediately use CPU hotplug events as well.
>>
>> A suitable new 'state' value could be used to signal CPU hotplug events:
>>
>> enum {
>> POWER_NONE = 0,
>> POWER_CSTATE = 1,
>> POWER_PSTATE = 2,
>> };
>>
>> POWER_HSTATE for hotplug-state, or so.
> Be careful, these are obsolete!
> This information is in the name of the event itself:
> PSTATE -> CPU frequency -> power:cpu_frequency
> CSTATE -> sleep/idle states -> power:cpu_idle
>
>> This would also express the design arguments that others have pointed
>> out in the prior discussion: that CPU hotplug is really a power
>> management variant, and that in the long run it could be done via
>> regular idle as well. When that happens, the above unified event
>> structure makes it all even simpler - analysis tools will just
>> continue to work fine.
>
> About the patch:
> You create:
> cpu_hotplug:cpu_hotplug_down_start
> cpu_hotplug:cpu_hotplug_down_end
> cpu_hotplug:cpu_hotplug_up_start
> cpu_hotplug:cpu_hotplug_up_end
> cpu_hotplug:cpu_hotplug_disable_start
> cpu_hotplug:cpu_hotplug_disable_end
> cpu_hotplug:cpu_hotplug_die_start
> cpu_hotplug:cpu_hotplug_die_end
> cpu_hotplug:cpu_hotplug_arch_up_start
> cpu_hotplug:cpu_hotplug_arch_up_end
>
> quite some events for cpu hotplugging...
> You mix up two things you want to trace:
> 1) The cpu hotplugging itself which you might want to compare
> with system activity, other idle states, etc. and check whether
> removing/adding CPUs works in respect of your power saving
> algorithms
> 2) You want to trace the time __cpu_down and friends take to
> optimize them
>
> For 1. I agree that it would be worth (mostly for arm now as long as
> it's the only arch using this as a power saving feature, but it may show
> up on other archs as well) to create an event which looks like:
>
> power:cpu_hotplug(unsigned int state, unsigned int cpu_id)
>
If it's possible to add such cpu_hotplug event in the power event
class, that's should be fine for me.
> Define a state:
> CPU_HOT_PLUG 1
> CPU_HOT_UNPLUG 2
> This would be consistent with other power:* events. One idea of having
> one event passing the state is, that it does not make sense to track an:
> power:cpu_hotunplug or power:cpu_hotplug
> standalone.
>
> Theoretically this could get enhanced with further states:
> CPU_HOT_PLUG_DISABLE_IRQS 3
> CPU_HOT_PLUG_ENABLE_IRQS 4
> CPU_HOT_PLUG_ACTIVATE 5
> CPU_HOT_PLUG_DISABLE 6
> ...
> if it should be possible at some point to only disable IRQs or to
> only disable code processing or to only disable whatever to achieve
> better power savings.
> But as long as there only is the general cpu_hotplug interface
> bringing the cpu totally up or down, above should be enough in
> respect of power saving tracings.
>
>
> For 2. you should use more appropriate tools to optimize the code
> processed in __cpu_{,up,down,enable,disable,die} functions and friends.
> If you simply need the time, system tab or kprobes might work out for you.
> There is preloadtrace.ko based on a system tab script which instruments
> functions called at boot up and measures their time.
>
> Or probably better are perf profiling facilities. It should be possible
> to profile __cpu_down and subsequent calls in detail. Like that you
> should get a good picture which functions you have to look at and
> optimize. People in CC should better be able to tell you the exact perf
> commands and parameters you are looking for.
>
I had tried to get such kind of information with function or
function_graph tracer but some functions like _cpu_down, are not
available in "available_filter_functions". Then, we don't have the
cpuid information with function trace what is not so bad on a dual
core but becomes more important on a quad cores. That's why I have
added some cpu_hotplug traces but I'm not a trace expert and I could
have missed the solution.
>
> Hm, have you tried/thought about registering an extra cpuidle state with
> long latency doing the cpu_down? For CPU 0 it could call the deepest
> "normal" sleep state, but could decide to shut other cpus down. Like that
> you might be able to get rid of some extra code (interfering with cpuidle
> driver?) and you get all the statistics, etc. for free.
>
No I haven't tried such mechanism but are you sure that we could call
cpu_down in cpuidle function ?
I'm still looking for relevant triggers for pluging/unpluging the cpu
: current cpu load and loadavg are some interesting ones.
Thanks
Vincent
>
> Thomas
>
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-03-02 19:02 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, linux-hotplug, Frederic Weisbecker, Steven Rostedt,
amit.kucheria, Rusty Russell, Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1103021056460.2701@localhost6.localdomain6>
On 2 March 2011 11:08, Thomas Gleixner <tglx@linutronix.de> wrote:
> Vincent,
>
> On Mon, 28 Feb 2011, Vincent Guittot wrote:
>> On 24 February 2011 19:40, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Thu, 24 Feb 2011, Vincent Guittot wrote:
>
> Sorry, this mail got eaten somehow, but I got it from my archive.
>
>> >> #ifdef CONFIG_SMP
>> >> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
>> >> static DEFINE_MUTEX(cpu_add_remove_lock);
>> >> @@ -197,10 +200,13 @@ struct take_cpu_down_param {
>> >> static int __ref take_cpu_down(void *_param)
>> >> {
>> >> struct take_cpu_down_param *param = _param;
>> >> + unsigned int cpu = (unsigned int)(param->hcpu);
>> >> int err;
>> >>
>> >> /* Ensure this CPU doesn't handle any more interrupts. */
>> >> + trace_cpu_hotplug_disable_start(cpu);
>> >> err = __cpu_disable();
>> >> + trace_cpu_hotplug_disable_end(cpu);
>> >
>> > How useful. What about recording the return code of __cpu_disable()?
>> >
>>
>> The goal is to monitor the cpu hotplug activity and duration. I want
>> to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
>> unplug/plug a core and ones which don't. But I'm not sure that we need
>> to sort the failed calls into to the trace. We trace them because too
>> much fails could point out a bug or a wrong use of cpu hotplug.
>
> This does not make sense at all. You want to see the failures, then
> recording the error code makes even more sense. Your way of decoding
> the error case by checking whether the next trace entry is there or
> missing is just sloppy.
>
The 1st goal was to focus on profiling and to make trace events as
simple as possible but I agree that having all information is a better
option. We can add a parameter in the trace which gets the return code
or some test result like the value of cpu_hotplug_disabled.
>> >> if (err < 0)
>> >> return err;
>> >
>> >> + trace_cpu_hotplug_down_start(cpu);
>> >> +
>> >
>> > What's the point of this tracepoint _BEFORE_ the cpu_hotplug_disabled
>> > check without recording cpu_hotplug_disabled ?
>> >
>>
>> I want to trace all cpu_down call even those which returns immediately
>> which will be part of the failed calls.
>
> Decoding failure from missing entries is simply wrong.
>
>> >> if (cpu_hotplug_disabled) {
>> >> err = -EBUSY;
>> >> goto out;
>> >> @@ -284,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
>> >> err = _cpu_down(cpu, 0);
>> >>
>> >> out:
>> >> + trace_cpu_hotplug_down_end(cpu);
>> >
>> > And this one is misplaced as well. It wants to be only called when we
>> > actually called _cpu_down() and it wants to record the return code as
>> > well.
>> >
>>
>> It has been placed here to be called each time
>> trace_cpu_hotplug_down_start is called.
>
> That does not make sense at all. You cannot distinguish between
> cpu_hotplug_disabled set and the _cpu_down() being called case. Or do
> you want to tell me that you decode that from the time stamps? Hell
> no. We want traces which are readable w/o crystal balls.
>
> Thanks,
>
> tglx
Thanks,
Vincent
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-03-02 21:12 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, Frederic Weisbecker, Steven Rostedt,
amit.kucheria, Rusty Russell, Ingo Molnar
In-Reply-To: <AANLkTikqp9=w+2r+Swe_4O9v=MiD=1tjCGrOQc9grHxk@mail.gmail.com>
Vincent,
On Wed, 2 Mar 2011, Vincent Guittot wrote:
> On 2 March 2011 11:08, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 28 Feb 2011, Vincent Guittot wrote:
> >> The goal is to monitor the cpu hotplug activity and duration. I want
> >> to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
> >> unplug/plug a core and ones which don't. But I'm not sure that we need
> >> to sort the failed calls into to the trace. We trace them because too
> >> much fails could point out a bug or a wrong use of cpu hotplug.
> >
> > This does not make sense at all. You want to see the failures, then
> > recording the error code makes even more sense. Your way of decoding
> > the error case by checking whether the next trace entry is there or
> > missing is just sloppy.
> >
>
> The 1st goal was to focus on profiling and to make trace events as
> simple as possible but I agree that having all information is a better
> option. We can add a parameter in the trace which gets the return code
> or some test result like the value of cpu_hotplug_disabled.
That's neither a question of focus nor of better options.
The main point is correctness and usefulness. When we add new
facilities or infrastructure we want to make sure that they are
general useful and correct for all possible use cases we can imagine
at that point in time.
So yes, I understand your reasoning and your focus on your primary
interest, but I also want you to understand that this kind of review
has a very practical background (i.e. maintainability) and is not just
the annoying bullying people around conducted by grumpy old men.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Thomas Renninger @ 2011-03-02 22:07 UTC (permalink / raw)
To: Vincent Guittot
Cc: Ingo Molnar, linux-kernel, linux-hotplug, fweisbec, rostedt,
amit.kucheria, rusty, tglx, Arjan van de Ven, Alan Cox,
Peter Zijlstra, H. Peter Anvin, Andrew Morton, linux-perf-users
In-Reply-To: <AANLkTi=dht7+bPrBqmt6shHefBxSB3yOUu4OcSvcd0am@mail.gmail.com>
On Wednesday 02 March 2011 20:02:00 Vincent Guittot wrote:
> On 2 March 2011 11:57, Thomas Renninger <trenn@suse.de> wrote:
> > On Wednesday, March 02, 2011 08:56:25 AM Ingo Molnar wrote:
> >>
> >> * Vincent Guittot <vincent.guittot@linaro.org> wrote:
> >>
> >> > This patchset adds some tracepoints for tracing cpu state and for
> >> > profiling the plug and unplug sequence.
> >> >
> >> > Some SMP arm platform uses cpu hotplug feature for improving their
> >> > power saving because they can go into their deepest idle state only in
> >> > mono core mode. In addition, running into mono core mode makes the
> >> > cpuidle job easier and more efficient which also results in the
> >> > improvement of power saving of some use cases. As the plug state of a
> >> > cpu can impact the cpuidle behavior, it's interesting to trace this
> >> > state and to correlate it with cpuidle traces.
> >> > Then, cpu hotplug is known to be an expensive operation which also
> >> > takes a variable time depending of other processes' activity (from
> >> > hundreds ms up to few seconds). These traces have shown that the arch
> >> > part stays almost constant on arm platform whatever the cpu load is,
> >> > whereas the plug duration increases.
> >> >
> >> > ---
> >> > include/trace/events/cpu_hotplug.h | 103
> >> > ++++++++++++++++++++++++++++++++++++
> >> > kernel/cpu.c | 18 ++++++
> >> > 2 files changed, 121 insertions(+), 0 deletions(-)
> >> > create mode 100644 include/trace/events/cpu_hotplug.h
> >>
> >> Why not do something much simpler and fit these into the existing
> >> power:* events:
> >>
> >> power:cpu_idle
> >> power:cpu_frequency
> >> power:machine_suspend
> >> power:cpu_idle
> >> power:cpu_frequency
> >> power:machine_suspend
> >>
> >> in an intelligent way?
> >>
> >> CPU hotplug is really a 'soft' form of suspend and tools using power
> >> events could
> >> thus immediately use CPU hotplug events as well.
> >>
> >> A suitable new 'state' value could be used to signal CPU hotplug events:
> >>
> >> enum {
> >> POWER_NONE = 0,
> >> POWER_CSTATE = 1,
> >> POWER_PSTATE = 2,
> >> };
> >>
> >> POWER_HSTATE for hotplug-state, or so.
> > Be careful, these are obsolete!
> > This information is in the name of the event itself:
> > PSTATE -> CPU frequency -> power:cpu_frequency
> > CSTATE -> sleep/idle states -> power:cpu_idle
> >
> >> This would also express the design arguments that others have pointed
> >> out in the prior discussion: that CPU hotplug is really a power
> >> management variant, and that in the long run it could be done via
> >> regular idle as well. When that happens, the above unified event
> >> structure makes it all even simpler - analysis tools will just
> >> continue to work fine.
> >
> > About the patch:
> > You create:
> > cpu_hotplug:cpu_hotplug_down_start
> > cpu_hotplug:cpu_hotplug_down_end
> > cpu_hotplug:cpu_hotplug_up_start
> > cpu_hotplug:cpu_hotplug_up_end
> > cpu_hotplug:cpu_hotplug_disable_start
> > cpu_hotplug:cpu_hotplug_disable_end
> > cpu_hotplug:cpu_hotplug_die_start
> > cpu_hotplug:cpu_hotplug_die_end
> > cpu_hotplug:cpu_hotplug_arch_up_start
> > cpu_hotplug:cpu_hotplug_arch_up_end
> >
> > quite some events for cpu hotplugging...
> > You mix up two things you want to trace:
> > 1) The cpu hotplugging itself which you might want to compare
> > with system activity, other idle states, etc. and check whether
> > removing/adding CPUs works in respect of your power saving
> > algorithms
> > 2) You want to trace the time __cpu_down and friends take to
> > optimize them
> >
> > For 1. I agree that it would be worth (mostly for arm now as long as
> > it's the only arch using this as a power saving feature, but it may show
> > up on other archs as well) to create an event which looks like:
> >
> > power:cpu_hotplug(unsigned int state, unsigned int cpu_id)
> >
>
> If it's possible to add such cpu_hotplug event in the power event
> class, that's should be fine for me.
>
> > Define a state:
> > CPU_HOT_PLUG 1
> > CPU_HOT_UNPLUG 2
> > This would be consistent with other power:* events. One idea of having
> > one event passing the state is, that it does not make sense to track an:
> > power:cpu_hotunplug or power:cpu_hotplug
> > standalone.
> >
> > Theoretically this could get enhanced with further states:
> > CPU_HOT_PLUG_DISABLE_IRQS 3
> > CPU_HOT_PLUG_ENABLE_IRQS 4
> > CPU_HOT_PLUG_ACTIVATE 5
> > CPU_HOT_PLUG_DISABLE 6
> > ...
> > if it should be possible at some point to only disable IRQs or to
> > only disable code processing or to only disable whatever to achieve
> > better power savings.
> > But as long as there only is the general cpu_hotplug interface
> > bringing the cpu totally up or down, above should be enough in
> > respect of power saving tracings.
> >
> >
> > For 2. you should use more appropriate tools to optimize the code
> > processed in __cpu_{,up,down,enable,disable,die} functions and friends.
> > If you simply need the time, system tab or kprobes might work out for you.
> > There is preloadtrace.ko based on a system tab script which instruments
> > functions called at boot up and measures their time.
> >
> > Or probably better are perf profiling facilities. It should be possible
> > to profile __cpu_down and subsequent calls in detail. Like that you
> > should get a good picture which functions you have to look at and
> > optimize. People in CC should better be able to tell you the exact perf
> > commands and parameters you are looking for.
> >
>
> I had tried to get such kind of information with function or
> function_graph tracer but some functions like _cpu_down, are not
> available in "available_filter_functions". Then, we don't have the
> cpuid information with function trace what is not so bad on a dual
> core but becomes more important on a quad cores. That's why I have
> added some cpu_hotplug traces but I'm not a trace expert and I could
> have missed the solution.
Best you ask here:
linux-perf-users@vger.kernel.org
Make sure CONFIG_DEBUG_INFO is set.
We (suse) do strip debuginfo from our kernels and provide them via a kernel-xy-debuginfo.rpm
> > Hm, have you tried/thought about registering an extra cpuidle state with
> > long latency doing the cpu_down? For CPU 0 it could call the deepest
> > "normal" sleep state, but could decide to shut other cpus down. Like that
> > you might be able to get rid of some extra code (interfering with cpuidle
> > driver?) and you get all the statistics, etc. for free.
> >
>
> No I haven't tried such mechanism but are you sure that we could call
> cpu_down in cpuidle function ?
> I'm still looking for relevant triggers for pluging/unpluging the cpu
> : current cpu load and loadavg are some interesting ones.
Entering shouldn't be a problem, but waking them up again...
I doubt cpu offlining is the proper instrument to save power.
You want to prevent the CPU of being used by ripping it out from scheduler decisions and
make sure it doesn't get interrupts by offlining. But the (latency) price is high.
On the one hand there may be quite some unnecessary hardware accesses to re-set it up again.
On the other hand drivers are notified to not use CPUx anymore, e.g. cpufreq will unload
for this cpu, this might need locks and waiting for sysfs access to finish, etc.
-> also not necessary overhead.
Maybe what you search for is something like sched_mc (kernel/sched.c) for single socket systems.
Something like:
Tell the scheduler to first utilize core0 and/or only use other cores for high prio tasks, or ...
On x86 irqs can be bound to CPUs from userspace via /proc/irq/*/smp_affinity
No idea how this looks like on arm, but this is another knob you could play with to achieve longer
residencies in deepest sleep states.
Thomas
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set
From: Bryan Kadzban @ 2011-03-03 4:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
Vilius Benetis wrote:
> we tested, ATTR{authorized}="1" works well, for
> ATTR{authorized_default}="0" we get an error during the boot, but it
> still works (probably the error is due to the yet non-existing
> device?):
>
> error opening ATTR{/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input11/event9/authorized}
> for writing: No such file or directory
That's matching the wrong thing when it tries to apply the rule to set
ATTR{authorized}, I think. This shouldn't have anything to do with the
authorized_default rule, based on the name logged.
> the rules have been used:
>
> #By default, disable it.
> ACTION="add", SUBSYSTEMS="usb", ATTR{authorized_default}="0"
I'd use SUBSYSTEM="usb", TEST="authorized_default" for this matching,
or something like that. Any USB kobject with an authorized_default
attribute should have a zero written into it.
> #Enable hub devices.
> ACTION="add", ATTR{bDeviceClass}="09", ATTR{authorized}="1"
>
> #Other things to enable
> ACTION="add", ATTRS{idProduct}="c052", ATTR{authorized}="1"
I'd use ATTR{idProduct} here, assuming that attribute is set that way on
the proper kobject in your sysfs tree. (Try finding all the authorized
files in /sys/devices/pci<whatever>/, then see which of them would match
this idProduct.)
ATTRS will search up the tree for a matching idProduct attribute, and
will therefore also match any interfaces that this USB device will
create. But those interfaces won't have an authorized file (since
authorization only works on devices). I suspect this is the cause of
the error message you copied above.
^ permalink raw reply
* How to trigger a udev rule
From: Thomas Bechtold @ 2011-03-03 6:21 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Hi,
i have a udev rule and want to trigger this rule with "udevadm trigger".
The rule is:
### only check /dev/ttyS1 (atmel_usart.1) for modem ###
ACTION!="add|change", GOTO="mm_platform_device_whitelist_end"
SUBSYSTEM!="platform", GOTO="mm_platform_device_whitelist_end"
DRIVERS=="atmel_usart",KERNELS=="atmel_usart.1",ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
LABEL="mm_platform_device_whitelist_end"
Any idea how to trigger this?
Cheers,
Tom
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox